Re: $asf->traverse(). Thanks for noticing. Yes, I'm pretty sure this is
new work, and publishable when I get time to write it up.
Re the bless/action adverb confusion: This is a real mistake on my part
in the presentation. Even careful readers like yourself look at the
code to form their general idea of "what is this all about". And as
things stand, the action/bless adverbs cause a serious misdirection.
They create the framework in which you'll read the documentation, and a
bad framework invites a misreading.
I think you can see why I did it. Testing is important and a test which
you can run two different ways and compare is really good for catching
problems. It was too good an opportunity to pass up. But it would be
nice to both keep the dual test and eliminate the misdirection of the
reader.
-- jeffrey
On 01/13/2014 10:31 AM, Ruslan Shvedov wrote:
On Mon, Jan 13, 2014 at 7:33 PM, Jeffrey Kegler
<[email protected]
<mailto:[email protected]>> wrote:
No, the ASF's do not see any effect from the "bless" or "action"
adverbs. They're there so I can do a dual test -- one with the
ASF's, and once using repeated calls to $slr->value(). I compare
the two results to make sure they're the same, but they use a
different mechanism.
Yes I see now, I was confused by rh_value() call and that value is
produced by applying actions, hence the confusion. Comparison with
$recce->value() with just looked like a separate test of how the
grammar works and I didn't go deeper even if I was recalling that
ASF's don't apply actions.
I think you can see why I did this, but apparently it has very
much confused issues. LLamaRider on the IRC channel was also
confused about this.
Just didn't read it carefully enough, I think. :)
Sure, comparing $asf->traverse( {}, \&full_traverser )
and $recce->value() would be more straightforward, but no problem in fact.
BTW, today I was reading the code for Marpa::R2::ASF::traverse() and
was plainly fascinated by its design. Absolutely brilliant piece of
code I've never seen before, whether in books or in the wild.
-- jeffrey
On 01/13/2014 09:21 AM, Ruslan Shvedov wrote:
On Mon, Jan 13, 2014 at 6:58 PM, Jeffrey Kegler
<[email protected]
<mailto:[email protected]>> wrote:
This is in response to the comment in the IRC group, right?
No, I'm afraid. :)
The bless adverb is confusing, but so is the action adverb,
which is also not used for ASF's.
Well, from sl_panda.t I thought that ASF's are created from
evaluated parse after all actions are applied, otherwise PennTags
package wouldn't be needed. Or am I missing something?
Of course a comment to that effect in the grammar might be
sufficient to elminate that confusion.
By the way, (as you may have already noticed) this code is
used as one of the displays in the POD, so it has to remain
suitable for that. And (of course) that makes the current
confusion in it something of an issue.
I really need some more information here, sorry.
Yes, your approach looks promising and I look forward to the
patch.
Ok, I'll give it a shot on the weekend ($work breaks in)
-- jeffrey
On 01/12/2014 11:55 PM, Ruslan Shvedov wrote:
lhs for G1 rules and name for L0 so that to enable
:default ::= action => [lhs, values]
lexeme default = action => [name, value]
instead of
:default ::= action => [values] bless => ::lhs
lexeme default = action => [start,length,value] bless =>
::name
My use case:
In
https://metacpan.org/source/JKEGL/Marpa-R2-2.078000/t/sl_timeflies.t,
I had to do this
my ($tag, $contents) = ( ref $_[0], $_[0] );
$tag =~ s/^PennTags:://;
to remove /bless_package/ that was added only to have the
lhs of G1 and L0 rules in the parse value.
With lhs and name in array item descriptors, I'd be able to
do just
my ($tag, $contents) = @_;
and achieve the same.
Perhaps removing the need to handle bless_package option in
favor of array descriptor can be more efficient.
If that's ok and possible, I'd start working on a patch.
--
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]
<mailto:[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]
<mailto:marpa-parser%[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]
<mailto:[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]
<mailto:marpa-parser%[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.
