Re: [sv-bc] Mantis 1571: Add default values for macro arguments

>If someone is making such complex use of macros that they need named
connections
>to keep the arguments straight and default values for arguments, then
they are
>probably abusing them.

Maybe weaknesses of the core SV language are abusing the users, so they
are attempting to work around those weaknesses with macros.  If so, then
we should strengthen the core SV language, not the macro language.

-- Brad


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven Sharp
Sent: Thursday, October 19, 2006 1:02 PM
To: shalom.bresticker@intel.com; sv-bc@eda.org; Greg.Jaxon@synopsys.COM
Cc: Dave_Rich@mentor.com; dmitry.korchemny@intel.com
Subject: Re: [sv-bc] Mantis 1571: Add default values for macro arguments


>From: Greg Jaxon <Greg.Jaxon@synopsys.com>

>Just noting that despite any other merits, this design is not backward 
>compatible with existing uses of macro expansion.
>
>In  the expansion of `ABC(.arg1(arg1), ...), existing products will use

>the token sequences .arg1(arg1) and this may have been the user's 
>intent.

Agreed.  Argument connection by name cannot be added with the existing
syntax while maintaining backward compatibility.


>In the expansion of `ABC #(.arg1(arg1),...), `ABC has no arguments so 
>it's expansion will be followed by #(.arg1(arg1),...).

But if ABC is a macro with arguments, then this usage would be illegal.
So we could give it a different meaning without creating any backward
compatibility issues.

I believe that what Shalom is suggesting is the following extension to
the language:

If ABC is a macro with arguments, and it is invoked with `ABC#(...)
instead of `ABC(...), then the argument list in parentheses should be
treated as a list of named connections for argument values, instead of
as a list of argument values.

The syntax `ABC#(...) would be illegal in the existing language, since
it is missing the required argument list for ABC.  So there cannot be a
backward compatibility issue.  You might need some constraints on the
way this was defined.  For example, you might want to require empty
parentheses or hash-parentheses after a macro with arguments, even if
you were using all default values.  Otherwise you would be unable to
distinguish whether `ABC#(...) was a macro with all default arguments
followed by #(...), or a macro with a named parameter list.  If you
require empty parens, then the first case would look like `ABC()#(...),
which does not have that ambiguity.

I am not sure that this kind of hack is a good idea, but it does seem
possible.

I am sympathetic to Dave's viewpoint.  If someone is making such complex
use of macros that they need named connections to keep the arguments
straight and default values for arguments, then they are probably
abusing them.  I am not strongly swayed by a consistency argument.
Macros are text processing that occurs before the text is actually
compiled, and their behavior is distinctive.  Users already have trouble
making that distinction.  Keeping the syntax distinct may help with
that.

Steven Sharp
sharp@cadence.com