RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals

By the way, it was already done in this production:

array_method_name ::=
	method_identifier | unique | and | or | xor 

It IS ugly.

But there is a precedent.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Steven Sharp
> Sent: Tuesday, March 18, 2008 11:01 PM
> To: sv-bc@server.eda.org; sv-ec@server.eda.org; 
> sv-cc@server.eda.org; sv-ac@server.eda.org; Brad.Pierce@synopsys.com
> Subject: RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals
> 
> 
> >From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> 
> >Just a short note about your last point --
> >
> >The existing built-in enum method 'next()' needn't be a backward 
> >compatibility problem for a new keyword 'enum'.  See 
> friendly amendment 
> >in bullet 11 here 
> ><http://www.eda-stds.org/sv/sv-champions/hm/att-0340/pierce_e
> mail_vote_
> >F
> >eb2308.txt> .
> 
> Can it be done?  Well, yes.  But that does not make it a good idea.
> It is clearly an ugly kludge, and such things tend to lead to 
> problems.
> Some specific problems:
> 
> 1. It requires special rules in the BNF and in parsers.  That 
> makes the
>    BNF harder to read and understand, and more prone to 
> errors.  It makes
>    parsers more prone to bugs.
>    
> 2. It requires care to ensure that there is no ambiguity between the
>    two meanings of the keywords.  And every time you add another such
>    special case, the complexity of the interactions with the previous
>    special cases becomes greater.
>    
> 3. Some of the built-in data types, such as mailboxes and 
> semaphores, are
>    considered to be classes and can be extended to create 
> derived classes.
>    What if we wanted to go back and do the same for enums?  
> You would be
>    unable to replace the next() method with your own version, 
> since it is
>    a reserved word.  Unless you also wanted to add next() to 
> the BNF for
>    declaring a method.  The ugliness in the BNF grows...
>    
> 4. I'm not sure you can do operator binding to the next() 
> function, since
>    most operators are already defined for enums via 
> autocasting to their
>    base integral type.  But if you can, or if you could 
> derive a new type
>    from enums as in 3 above, and wanted to be able to bind an 
> operator to
>    next(), you would then need to add next() to the BNF for operator
>    binding.  The ugliness just keeps growing...
> 
> That was just off the top of my head.
> 
> Clean design avoids problems; bad design invites them.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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