[sv-ec] Mantis 2514, ballot item #182: Steven's and Arturo's feedback

Steven said:

> I find the syntax
> "pure constraint" to be misleading.  For a "pure virtual" function,
> the "pure" modifies the "virtual", so that it doesn't appear to suggest
> that the function is pure.  It suggests to me that it is purely virtual,
> not real yet.  But "pure constraint" seems to suggest that there is
> something pure about the constraint.  Was the possibility of the syntax
> "pure virtual constraint" considered?  Would there be any problems with
> that syntax, aside from being wordier?

I don't think so, except that the more syntax you hijack now, the 
less scope you have for possible future change.  I thought about
"pure", "pure virtual" and "virtual" as the qualifier and eventually
felt that "pure" was the best choice because constraints are at least
in some sense virtual already.  I don't feel strongly about it, and
I agree that "pure constraint" sounds odd.

Arturo said:

> the use of the term ?obligation? for the case in which neither
> pure nor extern is specified seems too strong.

I carefully chose "should", and enumerated the relaxed requirement
explicitly.  Using the word "obligation" makes it very easy to 
describe the relationship between the prototype and its constraint
block.  But, as I said to Shalom on the same matter, I'd be
delighted to see alternative suggestions for the wording.

> I?d also like to hear more discussion on the need for
> ?extern constrain? since constrains do not exhibit the
> syntactical ambiguity that forced us to introduce this
> notation for methods.

I would completely agree, were it not for the fact that
implementations already have diverged in their interpretation 
of this.  If a constraint prototype appears in an abstract 
class it has two different possible meanings that need to be 
disambiguated, and that are currently handled differently
by different tools.  It seems to me that there are several
possible ways to deal with this:

1) Use the existing unqualified constraint prototype syntax
   to denote what I called a "pure constraint", and add the
   "extern" keyword for prototypes that expect an
   external implementation scoped into the same class. 
   It would then be an error for an unqualified prototype 
   to appear in a non-abstract class.  This is the solution
   whose syntax I find most appealing, but it would be 
   rather disruptive to existing code.

2) Use the existing syntax to denote what I called an
   "extern constraint" prototype, and add "pure" or
   "pure virtual" to qualify constraint prototypes in
   an abstract class that expect to be overridden not
   in that class but in some descendant class.  If this
   were done, existing code that uses a constraint 
   prototype to create a pure constraint would need
   to be modified, but existing use of the prototype
   syntax in a non-abstract class would be unaffected.

3) The way I proposed.  Use of the existing syntax could
   be flagged with a warning or note suggesting that 
   an appropriate qualifier be added.

> Is it needed strictly for orthogonality with methods?

I think the consistency is potentially helpful to users,
yes, but obviously it's not vital.
-- 
Jonathan Bromley
Consultant

Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel:  + 44 (0)1425 471223                       Email: 
jonathan.bromley@doulos.com 
Fax:  +44 (0)1425 471573                        http://www.doulos.com

--------------------------------------------------------------------------------
Doulos Ltd is registered in England and Wales with company no. 3723454
Its registered office is 4 Brackley Close, Bournemouth International 
Airport,
        Christchurch, BH23 6SE, UK. 

This message may contain personal views which are not the views of
Doulos, unless specifically stated.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.