Macro Parsing... 
Author Message
 Macro Parsing...

I have a question about the parsing of definition macros....

Statement and function macros are "easy" to disambiguate if you
know all of the macro definitions before hand. If you run into the
symbol that starts the statement macro or is the "function name" of the a
function macro then all you need do is "look up" the definition.

However, definition macros seem a tad more problematical.... They all
start with the word "define" and end with "end" but what comes between
seems constrained by a pretty much "magical" process.  If the "name" of a
definition macro (thereby becoming a reserved word of sorts ) happens to
used as a modifier of another definition macro.... is this error trigger
prior the macro expansion phase?  Something akin to the "semantic analysis
phase before code gen"... a "macro semantic analysis phase".

And it seems like modifiers are auto-magically exported if the definition
macro is exported from a module/library. [ Note: to export the macro I
presume you export the name of the macro. So in the case of a definition
macro it would be *-definer.  which would effectively export the prefix,
( as pseudo reserved words ) and all of the modifiers (as what? pseudo
reserved words or as "modifier words" ) .  The latter so that
they could not be used as definition macros themselves, but could be
legal variables].

Seems like you'd need two collections to do this macro semantic analysis. The
first composed of the predefined and user defined DEFINE-LIST-WORDs and
DEFINE-BODY-WORDs. The second composed of the modifiers of the definition
macros seen so far.  When validating a definition macro you would look for it's
"name" in the second and for any of it's modifiers in the first.  Or am I
missing something?

--

Lyman S. Taylor          "Any sufficiently advanced technology is

                                   -- paraphrased Arthur C. Clarke
                                        seen somewhere on the USENET



Sun, 12 Sep 1999 03:00:00 GMT  
 Macro Parsing...

Quote:
Lyman S. Taylor writes:
> [...]
>                                                   [Definition macros] all
> start with the word "define" and end with "end" but what comes between
> seems constrained by a pretty much "magical" process.  If the "name" of a
> definition macro (thereby becoming a reserved word of sorts ) happens to
> used as a modifier of another definition macro.... is this error trigger
> prior the macro expansion phase?  Something akin to the "semantic analysis
> phase before code gen"... a "macro semantic analysis phase".

> [...]

The constraint on modifier words as far as the grammar is concerned is
just that they can't be macro-words or core reserved words - that is,
grammatically legal modifiers are defined in terms of what they can't
be rather than by giving them a special classification. One
consequence of this is that the set of modifier words accepted by a
macro doesn't have to be determinable by the compiler when it
processes the macro's definition. Another is that unexpected modifiers
might well make it past the fragment grammar to be picked up during
pattern matching.

It would be possible to provoke errors or unexpected parses in the way
you suggest at the stage of doing fragment-level parsing. If you wrote
a macro called "open-definer" with the syntax "define open ... end",
then wrote "define open class <ack> (<object>) end" in the scope of
"open-definer" for example, you'd get a call to "open-definer" not
"class-definer". This is because the parser stops reading modifiers at
the first defining word it finds after the "define". The ambiguity in
an example like this is pretty clear though and is best resolved by
renaming one of the macros - for the sake of the sanity of the human
reader if nothing else! The less pleasant alternative is to escape the
defining word with \ when it's used as modifier, to strip it of its
other interpretation.

Hope this helps,
Keith



Mon, 13 Sep 1999 03:00:00 GMT  
 Macro Parsing...



Quote:
>It would be possible to provoke errors or unexpected parses in the way
>you suggest at the stage of doing fragment-level parsing.

  I thought the DRM said that this should generate an error. However, it
  seems to say "In particular a DEFINE-BODY-WORD or DEFINE-LIST-WORD cannot
  be used as a modifier in a definition".  When I first read that I equated
  "cannot" with "generate error".  I'm not sure I'm happy with the "unexpected
  parses" option....

Quote:
>"class-definer". This is because the parser stops reading modifiers at
>the first defining word it finds after the "define". The ambiguity in
>an example like this is pretty clear though and is best resolved by
>renaming one of the macros - for the sake of the sanity of the human
>reader if nothing else!

 From a large program formed from reusable library standpoint, what about
 interaction effects between two libraries [ in the following example you
 may distribute the variables and macros to various libraries/modules and
 then use them all in a final module that contains the example code
 fragment also below. ] Furthermore, what if both libraries are given to you
 in compiled formed [ granted you can still rename on importation, but the
 "hidden" interaction effect isn't so desirable. ]

 Here's another example:

 define variable foo ;
 define variable bar ;
 define variable baz ;

 define macro foo-definer
        { define foo ?x ?y end } => { baz := ?x + ?y; }
 end macro ;

 define macro bar-definer
        { define ?modifier bar ?x end } => { baz := ?x + ?modifier; }

   modifier:
        { foo } => { foo }
        {}      => {  1 }

 end macro ;

Now consider the code fragment of

  define foo bar 23 ;     \\  baz := bar + 23;  or  baz := 23 + foo;   ???

The parsing is ambiguous.  If the compiler does NOT generate some sort of
error message ( or at the very least warning message ) the code generated by
either is semantically correct so I'm not going "notification" at all from
the compiler. Just weird behavior from my program when it is run.

If the parsing is "silently" resolved to "shortest first", then I must mentally
track the modifier length and legal modifiers of all the definition macros
that are valid in the current context.....  Personally, if I wanted a language
where I had to do mental gymnastics to track the parsing of the language I'd
stick with C++. :-)

Perhaps it would do to hear the rational of why the DEFINE-LIST-WORDs and
DEFINE-BODY-WORDs do not become reserved words along with the macro name.
Why let them still be used as a variable-names?

[ In looking at the BNF again I can see that a pattern variable is allowed
  to "gather up" any and all modifiers. Somehow I thought that the matching
  of the modifiers had to match up with terminals as some point. Somewhat
  akin to how intermidate words half to show up after the body of a
  "subcomponent" of a statement. Alas the "define-*-word" itself forms the
  boundary.  By the way doesn't this engender that you need K lookahead to
  parse this construct? ]

--

Lyman S. Taylor          "Any sufficiently advanced technology is

                                   -- paraphrased Arthur C. Clarke
                                        seen somewhere on the USENET



Fri, 17 Sep 1999 03:00:00 GMT  
 Macro Parsing...

Quote:
Lyman S. Taylor writes:
> > [...] The parser stops reading modifiers at the first defining word
> > it finds after the "define". [...]

> [...
>  Emphasizes with an example the point that the introduction of a new
>  defining macro, perhaps via adding a used module, could change the
>  meaning of existing code without necessarily resulting in any
>  compile-time indication of that change.
> ...]    

> If the parsing is "silently" resolved to "shortest first", then I
> must mentally track the modifier length and legal modifiers of all
> the definition macros that are valid in the current context.....

Only time will tell whether this constitutes an issue that will crop
up with any frequency to obstruct progress. A switch in parse of this
kind that didn't result in any indication at compile-time is
particularly unlikely I suspect. But where any such potential exists,
implementors should be encouraged to handle it as helpfully as
possible. I've never seen this case in practice, but I'll think about
a configurable warning for it in our implementation.

Quote:
> Perhaps it would do to hear the rational of why the DEFINE-LIST-WORDs and
> DEFINE-BODY-WORDs do not become reserved words along with the macro name.
> Why let them still be used as a variable-names?

Because it wasn't necessary technically to restrict their use, and it
seemed a worthy goal to keep reserved words to a minimum. Remember
also that the language itself has a defining word that simultaneously
has a definition in its own right - i.e. "method" / "define method".

Quote:
> [ In looking at the BNF again I can see that a pattern variable is allowed
>   to "gather up" any and all modifiers. Somehow I thought that the matching
>   of the modifiers had to match up with terminals as some point. Somewhat
>   akin to how intermidate words half to show up after the body of a
>   "subcomponent" of a statement. Alas the "define-*-word" itself forms the
>   boundary.  By the way doesn't this engender that you need K lookahead to
>   parse this construct? ]

If by "this construct" you mean a definition macro call, then no, the
fragment grammar for that is LR(1), but if you mean a definition macro
main rule pattern, then a more generic parse together with some
postprocessing tends to be used to detect the end of the modifier
patterns.

-- Keith



Fri, 17 Sep 1999 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Macro parsing?

2. Dylan program structure and macro parsing

3. Dylan program structure and macro parsing

4. syntax, lexing and parsing, macros

5. Using instr to parse macro paramaters

6. Dragon Macros (was: RE: Help Rewriting/Refactoring/Rethinking Parsing Algorythm)

7. Pragmatic parsing macros

8. Pragmatic parsing macros (aka. META)

9. A macro involving two sub-macros - where the 2nd macro needs results from the first

10. macro -vs- macro/codeblock

11. Help with macros writing macros in Bigloo

12. syntax-rules macros with sub-macros

 

 
Powered by phpBB® Forum Software