I've just uploaded a new release candidate, Marpa-R2 2.077_014
<https://metacpan.org/release/JKEGL/Marpa-R2-2.077_014>, to CPAN. In it
the SLIF recognizer's named argument processing is changed to leave the
original hash untouched.
I've left myself some flexibility by not changing the documentation, but
realistically, given my attitude toward regressions, this pretty much
paints me into a corner on the issue.
I opened myself to this kind of argument hash manipulation by allowing
multiple argument hashes. That is, for most Marpa methods that take
named arguments, you can do
$obj->method( { arg1 => value }, { arg2 => value, arg3 => value }, ...)
Allowing this is unusual in Perl modules -- it may even be one of my
inventions. I originally did it to overcome one of the limits of Perl's
hashes-as-named-arguments processing -- lack of control over the order.
Allowing more than one hash allows you to both use hashes and to specify
the order in which the arugments will be processed. Order of argument
processing is not an issue in the SLIF, but in some previous Marpa
interfaces it was. As one example, in the Pure Perl versions, it was
often useful to specify at what point in the argument processing certain
kinds of tracing were turned on or off.
Anyway, once you start to put together the named arguments in pieces,
that very naturally carries over into a desire to reuse the pieces.
-- 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.
