On Tue, Jan 14, 2014 at 11:15 AM, Jeffrey Kegler < [email protected]> wrote:
> My confusion stems from not realizing that you were getting into the > code as deeply as you are. -- jeffrey > No problem, I've been somewhat mystified and hardly able to explain myself clearly. So, it's all good I think. > On 01/14/2014 01:07 AM, Ruslan Shvedov wrote: > > Now I see that I took the wrong path with R2.xs, sorry. > > I now see push_values is created via create_ops.pl; need to take a > closer look, thanks and sorry for the mess. > > > > > On Tue, Jan 14, 2014 at 10:31 AM, Jeffrey Kegler < > [email protected]> wrote: > >> I'm not sure I have the context here. MARPA_OP_PUSH_VALUES is from the >> undocumented (and unsupported) SLIF interface to my XS code. >> MARPA_STEP_RULE and marpa_v_rule() are from the documented (and supported) >> Libmarpa interface. >> >> That undocumented SLIF XS interface has the advantage of speeding up the >> SLIF. It has the disadvantage of making my Perl code very hard to use as a >> template or starting point for your own. This was a major step backward >> from the NAIF, whose Perl-to-XS interface was the THIF, 100% documented and >> supported. The SLIF still relies on the 100% documented Libmarpa >> interface, but that interface has been pushed down inside the XS code, and >> the SLIF's Perl-to-XS interface is not documented or supported. >> >> Since MARPA_OP_PUSH_VALUES and MARPA_STEP_RULE are from two different >> interfaces, one of which is not supported, I don't think you'll be able to >> mix the two. I am not at all sure that I am addressing your question, or >> that I understood it, but I hope this clarifies things a bit. >> >> -- jeffrey >> >> On 01/13/2014 11:28 PM, Ruslan Shvedov wrote: >> >> I think I need some good advice to make sure that I'm on the right >> track. >> >> I started from cpan\lib\Marpa\R2\Value.pm and Value-overview.html and >> thought of adding *op_push_lhs* by analogy to *op_push_values* >> (MARPA_OP_PUSH_VALUES) >> command and getting lhs via marpa_rule_lhs after marpa_v_rule at >> MARPA_STEP_RULE. >> >> Schematic as it is, is this the right way of adding an array descriptor? >> >> >> >> >> On Mon, Jan 13, 2014 at 6:58 PM, Jeffrey Kegler < >> [email protected]> wrote: >> >>> This is in response to the comment in the IRC group, right? >>> >>> The bless adverb is confusing, but so is the action adverb, which is >>> also not used for ASF's. 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. >>> >>> Yes, your approach looks promising and I look forward to the patch. >>> >>> -- 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]. >>> 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. >> > > -- > 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.
