On Sun, Jul 20, 2014 at 9:56 PM, Paul Bennett <[email protected]> wrote:
> On Sun, Jul 20, 2014 at 10:06 AM, Ruslan Shvedov > <[email protected]> wrote: > > Hi Paul, here are my 2cents on this, in no particular order > > > > C style #include's — aren't they supposed to be processed before parsing > the > > program? The grammar has actions for include's, but I honestly can't see > how > > you are going to inject the included file's contents at the recongition > time > > except probably with event completed statements which will read() the > > included file contents. > > An #include is "just another macro". I was thinking of doing almost > exactly as you say: spawning a second recce and using that to inject > into the main symbol table (accomplished by the "our $self = bless { } > => __PACKAGE__ ; sub new { return $self } ; ..." trick, where $self > holds (among other things) the symbol table). > > I've updated the gist https://gist.github.com/PWBENNETT/8435996 to > rename "Definition" to "Macro", and to allow an #include anywhere a > Macro is allowed, to hopefully better explain my intentions (that is, > until I actually have some "real" code to show). > > > To make a long story short, if you think the language needs a > preprocessor, > > write a preprocessor (or just use cpp). > > Maybe. It's certainly a good idea. I don't know whether I want to have > the full capability for users to shoot themselves in the foot that cpp > might provide, but there's definitely a good case to be made for it. > > > I can't see a rule for free (unbound) variables (FV (·)) and (·,·) in the > > grammar. > > Syntactically I see no difference between bound and free variables > that can't be made by context. > Yes, all the more that examples seem to contain no free variables. Isn't (·,·) just the notation for what I've called a Tuple in my grammar? > Sure, missed that one, sorry. > > LE/le seem to include both < and <=, while the paper has only <. > > The paper has, as you quote below, both < and ≤, which is incorporated > into the (revised) gist as syntactic sugar for (or sugared by?) <= (or > ⩽) > Yes (only < among the primeops though), but you're certainly right about sugaring. > > > In the paper's if X then Y else Z, X seems to be a (bound) variable (not > > sure if/how they convert it to boolean, perhaps by whether it has PDF or > > not), while it is a comparison in the grammar. > > The name "comparison" is just a notational thing for my convenience. > Oh, but yes. Yes, indeed. Variables are not allowed in the "X" slot in > my version. I'll have a think about that, and update the gist again > later. > > Thanks for the input, > > > -- > P/PW/PWBENNETT > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
