[sv-bc] P1800-2008 draft 4 pg 526

Easy stuff first:

Page 526 has many nice examples of `defines but
some of the ` characters have accidentally turned to '.
This is probably already covered by proposed rewrites, just wanted to
sensitize the editor.

I also like the following:

> b) Text macro names can reuse names being used as ordinary identifiers.
>    For example, signal_name and `signal_name are different.

But I hope that I am not reading too much into it.
I take it to imply that given:

   `define f(b) b+`b
   `define b 41

...when we expand `f(1) we should get  1+41, not 1+`1.  Another way of
saying this would be that ` is not a function being applied to an expanded
identifier, it is part of the identifier token that directs you to a separate
namespace.  Note that many systems already agree on the "function" approach
where formal/actual substitution can replace the identifier part of a `
macro invocation.  Is it committee intent to be incompatible with V95 here?
Personally I like it, but incompatibility (especially at these low levels)
could be a barrier to migration and a source of product divergence as
preprocessors are patched by different teams.

On a related note, I also approve of the syntax rule
> formal_argument_identifier ::=
>        simple_identifier

which makes macro formals be simple_identifiers, not escaped_identifiers.
However, because it goes on to say:
> When formal arguments are used to define a text macro, the scope of the
> formal argument shall extend up to the end of the macro text.
> A formal argument can be used in the macro text in the same manner
> as an identifier.

One manner in which identifiers can be "used" is by spelling them with `\`.
This is the flip side of the previous issue.  Though `A and A are different,
\A  and A are the same.  I think it would be consistent and maybe even helpful
to accept both the simple and escaped form of reference to a
formal_argument_identifier.  By patching a preprocessor I've determined that
it is feasible, but have to observe that it is incompatible with the
existing preprocessors which can find formal_argument_identifiers when they
appear as delimited substrings inside a larger escaped_identifier.
The resulting substitution is a really crazy form of token gluing!

Lastly:

The fact that escaped_identifier can reduce to text_macro_name
suggests that `\simple_id  can invoke  `define simple_id XXX.

Which ties us into my second topic above.
When patching my experimental preprocessor, I found that the part
of the scanner which recognizes what is a formal_argument_identifier
could quite easily impose the "problem (b)" rule.  By collecting
identifiers when they start with `.  This zone is already undergoing
incompatible development to support `", `\", and ``.

Two more examples of these issues, if you're going to try this at home.

 `define \foo(3)  666
 `define sna(foo) `\foo(3)  + `\foo  + `foo + \foo  + foo
 `define foo 69
 `define ke 42

Does  `sna(ke)  expands to:

  a)  666 + 69 + 69 + ke + ke
  b)  `\ke(3) + `42 + `42 + 42 + 42       // with errors of course
  c)  `\ke(3) + `\ke  + `42 + \ke  + 42   // also errors

Does anyone know non-error applications of the latter approaches?
Brad sent me:

  `define a 1
  `define b 3
  `define f(a) `a+`a
  module test(out);
     output [3:0] out;
     wire [3:0] out;
     assign out = `f(b);
     initial #1 $display( out  );
  endmodule

And observes that systems implementing popular answers (b) and (c)
displayed 6 rather than 2.

`define \esc[ap]e  27
`define f(e) (e + `\esc[ap]e )

Does invoking f(x) still invoke \esc[ap]e ?

Greg Jaxon


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