RE: [sv-bc] e-mail ballot: respond by Dec 3, 8am PST

Hi,

Regarding Mantis 1571: 

> >SVDB 1571 ___Yes   _X_No  
> >http://www.eda.org/svdb/view.php?id=1571
> 
> I am not sure we have resolved all the existing issues with 
> macros.  I am hesitant to add any extensions until we have 
> resolved all of those.
> I don't see this functionality as critical, since it can be 
> gotten by defining another wrapper macro with fewer 
> arguments, which invokes the original macro with the desired 
> defaults for the extra arguments.

That means
1. you need a different wrapper for everything different combination of
use of defaults
2. the macro name loses its identity as the original macro
3. you need to know what the default values are
4. probably you wind up with everyone defining his own wrappers

That argument could be used for tasks, functions, properties, and
sequences as well.
Before there were defaults for tasks and functions, people did as you
suggested because there was no other choice, not because they liked it.
Defaults were added because there was and is a demand and need for them.
The same is true for macros.
I know from experience.


> I also do not see the situation with macros as being quite 
> the same as functions.  With functions, it is clear when you 
> are leaving out an argument, and it is clear that something 
> needs to be provided instead.
> With a macro, the argument is text, and empty text is valid 
> text.  One symptom of this is the issue that white space is 
> being considered to be an empty argument.  That makes it 
> dependent on the proposal to strip white space from the front 
> and back of arguments.  Otherwise white space is a perfectly 
> valid non-empty argument that you may want substituted.

Except that everyone has already agreed that an argument consisting only
of white space is treated as empty.


> I see an issue with the description of the expansion 
> ordering, with respect to the definition of what constitutes 
> a recursive macro.  As Greg pointed out, the original example 
> where a `TOP invocation was used as an actual argument of a 
> `TOP invocation, is not recursive.  It is composition of the 
> macro with itself, not recursion.  The new use of the macro 
> is coming from the argument, not from the macro body.  It 
> does not create any issues with infinite recursion.  But with 
> the description of substituting the actuals into the macro 
> text before expanding them (though I think that is the right 
> thing to do), the macro is expanding into text containing a 
> usage of itself.  The LRM says that this is erroneous, and a 
> recursive macro.  In a sense, this issue was already there, 
> but it has been made more severe because of the explicit 
> description of the expansion order.

I would have omitted this entirely, except that it gave a way to pass an
empty actual argument to a formal argument with a non-empty default. I
agree that what you say is a problem. How do YOU reconcile substituting
actuals into the macro before expanding them with the existing LRM
statement, "It shall be an error for a macro to expand directly or
indirectly to text containing another usage of itself" ?


> I also have a problem with the statement that the argument 
> expansion shall not introduce new uses of the formal.  That 
> wording implies that it is possible but illegal to do this.  
> What is intended is that it is not possible to do this, 
> because text that expands into an identifier that matches a 
> formal is not considered to be a use of the formal after the 
> actuals have been substituted.  Just because the word "shall" 
> is supposed to be used in some situations does not mean that 
> it should be used in all situations.  It has a very specific 
> meaning in the LRM.

Well, 'shall' could be understood here as an instruction to the tool
developer, but I agree it is ambiguous. How about, 

"When a macro usage is passed as an actual argument to another macro,
the argument expansion does not introduce new uses of the formal
arguments to the top-level macro."
(or 'will not') ?

Thanks,
Shalom
---------------------------------------------------------------------
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.