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".
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.
-- 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
<jeffreykeg...@jeffreykegler.com
<mailto:jeffreykeg...@jeffreykegler.com>> 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 marpa-parser+unsubscr...@googlegroups.com
<mailto:marpa-parser%2bunsubscr...@googlegroups.com>.
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 marpa-parser+unsubscr...@googlegroups.com.
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 marpa-parser+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
