No, not s/undef/ID/. What I was attempting to convey is that, for the
purpose of determining symches, the set of rule ID's is {undef, 0 ...
n}, where n is the maximum rule ID. That is, in most contexts an undef
rule ID means that the rule ID is not well-defined. But in the
determining a symch, undef counts as if it were an ordinary rule ID.
Perhaps it would be clearer if I say it this way:
"A symch is either a rule symch or a token alternative. A rule symch is
a series of rule alternatives (factorings) which share the same rule ID,
and the same glade. A glade's token alternative is a symch all by itself."
By the way, in the current implementation of the SLIF, a glade that
contains a token alternative will never contains any rule symches, and
vice versa. But Libmarpa allows LHS terminals and when that feature
comes to the SLIF, it will be possible for glades to mix token
alternatives and rule alternatives. I am writing the docs so that
applications that adhere to them will work OK when they encounter
grammars with LHS terminals. (LHS terminals were part of Marpa from day
zero, and I expect them to come in handy some day, but for the moment
nobody but me sees any potential use for them, and they've fallen to the
bottom of my "to do" list.)
-- jeffrey
On 12/18/2013 11:21 PM, Ruslan Shvedov wrote:
Marpa-R2 2.077_011
<https://metacpan.org/release/JKEGL/Marpa-R2-2.077_011> installed
successfully for me on cygwin and windows. The new HL interface is
very appealing.
ASF.pod contains this passage:
A symch is a series of alternatives (factorings) which share the same
rule id. and the same glade. For this purpose, the |_undef_| of a
token alternative is considered a rule ID.
...
Recall that for this purpose, the token alternative's |_undef_| is
considered a rule ID.
s/undef/ID/? Or am I missing something?
On Thu, Dec 19, 2013 at 7:57 AM, Jeffrey Kegler
<[email protected]
<mailto:[email protected]>> wrote:
I have just uploaded Marpa-R2 2.077_011
<https://metacpan.org/release/JKEGL/Marpa-R2-2.077_011> to CPAN.
The high-level ASF interface is now documented
<https://metacpan.org/pod/release/JKEGL/Marpa-R2-2.077_011/pod/ASF.pod>.
At the high-level, there's no talk of symches and factoring and
memoization is done for you. (OK, actually I do mention symches
and factorings, but it's all relegated to section at the end which
you can skip.) You write a "traverser" subroutine which is very
like the action for of an AST node. It has access to the rule ID,
the literal input span, the values of the child symbols, etc. Of
course, the traverser has to deal with ambiguity, and this
motivates two differences:
First, it's unified -- there is only one traverser subroutine.
Instead of multiple actions attached to rules, there's only one
traverser and you'll need to write your own if-else or similar
logic to perform whatever per-rule logic there is. This is
because, due to ambiguity, each ASF glade (the ASF equivalent of
an AST's tree node) might involve several rules.
Second, there's an iterator, $glade->next(). This lets you step
through the alternatives at a glade.
It is still tree traversal, so it's not trivial, but I hope it's a
less daunting place to start than the low-level interface.
-- 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]
<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.
