On Sun, Feb 16, 2014 at 12:42 AM, Jeffrey Kegler < [email protected]> wrote:
> Re (1) lhs name would be mildly difficult -- right now the arrays are > assembled in C/XS code (the process is blazingly fast), but that layer does > *not* know about symbol names. That could be changed, but it's perhaps > more like something for "interface 3". > For quick initial checking of the grammar, a method, e.g. $slr->show_ast() can be added to pretty print (each lhs on the newline indented in 2-space increments, lexeme values on the same line) the parse tree with LHS id's converted to LHS names. Re (2), I am not 100% sure I understand the point, I made promises in the > documentation about what the semantics would be is there were no default > statements, and I can't change the behaviors, even in SLIF DSL's which have > no explcitly set defaults, without breaking those promises. > Yes, implicit actions. The doc promise abous lexeme implicit action can be kept by setting it to *[value]* (i.e. *::array*) as you initially said that's currently the same as omitting it. As for the rule implicit action (return *undef*), if somebody relies upon that behaviour strongly enough, then case closed. However, in implementing semantics by writing actions for rules one by one it can be useful to look to *Dumper*'ed [lhs,values] of rules which have not action yet rather than just catching *undef*'s, so if implicit rule action can be changed to *[lhs,values] *and (with *$slr->show_ast() *added *)*, I'd vote for it. As for *interface *statement, I'm tempted to say that the developer version with globally forgiving metagrammar and the new behaviour :default ::= action => [lhs,values] lexeme default = forgiving => 1 invoked when the use omits *:default* and *lexeme default* and user-changeable by specifying both or one of them will help find incompatibilities, gather feedback and then decide if it's needed or the new defaults are sensible enough to let them, well, just remain the defaults. > -- jeffrey > > On 02/15/2014 11:17 AM, Ruslan Shvedov wrote: > > (1) while *::array* is ok for both lexemes and G1 rules, to let the user > see both the parse result and and how it is parsed, I'd suggest the > following defaults I've caught myself using frequently: > > :default ::= action => [lhs,values] > lexeme default = action => [lhs,value] forgiving => 1 > > > where *lhs *should be the LHS's name which is not currently the case: > lhs command returns LHS's id, so some change would be needed, like making > *lhs* return LHS name and, perhaps, adding *lhs_id* command. > > > (2) defaults, *per se*, are invoked when a user omits something; with > that in mind I'd suggest checking if *:default* and *lexeme default* are > in the user grammar and add the defaults if they aren't. This also allows > the old code run unchanged. > > Finally, something I'm not sure about: a developer version with meta > grammar converted to forgiving to let people test against it and see if and > how exactly it is (in)compatible. > > Hope this helps, -- rns. > > > > On Sat, Feb 15, 2014 at 7:29 PM, Jeffrey Kegler < > [email protected]> wrote: > >> I'd like opinions on adding a "interface" statement to the SLIF. >> Currently, for backward compatibility reasons, some of the defaults are >> not the best. I'd like to add a >> >> interface 2 >> >> statement which, if present, will makes these the new defaults: >> >> lexeme default = forgiving => 1 >> :default ::= action => ::array >> >> The first line would make LATM the default, and the second would make >> the make the default semantics for rules return the child values in >> an array. >> >> A specific reason for changing the default for rule semantics is that >> in the first stages of development, array output is useful in checking >> your grammar. So it's a great way to start. >> >> The current behavior, returning 'undef' by default, is especially >> perplexing to newcomers to Marpa. It means that, by default, value() >> returns \undef on success, and undef on failure. This behavior is >> unintuitive, unhelpful and confusing. >> >> A specific question I have: Should one of the bless options also be the >> default for rules? If so, what about lexemes? A reason not to bless >> is clutter. A reason to bless is that it provides even more information >> for grammar checking. >> >> As usual, these defaults will be able to be overriden, but they do make >> a real difference in convenience, and to those just finding their way >> in Marpa. Whichever is the choice, I'll change all the synopses in the >> docs to include a >> >> revision 2 >> >> statement at the beginning, so that it becomes more or less like the >> "use strict", etc. incantation at the beginning of Perl scripts. >> >> Please comment or ask questions -- jeffrey >> >> -- >> 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/groups/opt_out. >> > > -- > 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/groups/opt_out. > > > -- > 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/groups/opt_out. > -- 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/groups/opt_out.
