Hello Nicolas,

Thanks for your comments! Some of mine below.


> > IS_NULLABLE(rule) == e in pFIRST(rule)
> > IS_LEFTREC(rule). == rule inf pFIRST(rule)
>
> That first equation looks very shaky to me. It's not enough to have the
> empty string (epsilon) as a potential first expression. The issue is
> sequences. For instance: `X ::= a? b` has epsilon in FIRST, but is not
> nullable, since it has to at least match `b`.
>

The first rule should have been:

IS_NULLABLE(exp) == e in pFIRST(exp)

When applied to rules, exp should be the right hand side, which may be a
sequence.

In your example, `X ::= a? b`, `?a` is nullable, but `a? b` shuld not be as
it can never generate the empty sequence. The FIRST set should be {a, b}.
I'll add this example as a unit test.

> Regarding left-recursion, that does indeed work nicely.
>
> The way I formalize left-recursion in my thesis is that I say there exists
> a relationship `FIRST(A, B)` between the parsing expression `A` and `B` if
> `B` can be **directly** invoked by `A` at the same input position it was
> itself invoked at. This relationship gives you a directed graph and
> left-recursion is a loop in the graph.
>
Ah! I knew this must had been thought about before. In my proposal,
pFIRST(exp) may include non-terminals (which don't interfere with
terminals, and can safely be discarded if working towards LL(1) )

> Regarding your sets, I understand `FIRST` and `FOLLOW`, but what is the
> semantics of `LOOKAHEAD`? Is it like `FIRST`, but within a lookahead
> (positive only, or negative as well)?
>
LOKAHEAD is the k-concatenation of FIRST and FOLLOW in LL(k). It is needed
precisely to deal with rules that are nullable. I can't remember an example
for the need off the top of my head.

My interest in this approach is three-fold:

   - The theoretical basis is much clearer because it's
   algebraic/graph-based (as you explain above)
   - Computation of FIRST/FOLLOW is well understood and there are simple
   algorithms for it (like the one in TatSu)
   - The above make it easier to implement PEG/leftrec in lower level
   languages (like in C, which must be the target in my work to help with
   next-generation Python compilation).

Best regards,

On Fri, 14 Jun 2019 at 02:07, Juancarlo Añez <apal...@gmail.com> wrote:
>
>> Hello,
>>
>> I tested the theory in the previous message, and it's looking good. The
>> only change required is to add a special token rules named on
>> right-hand-sides to the results returned on FIRST set computations. The
>> bold part after the '|' here:
>>
>> class RuleRef(Model):
>>     def _first(self, k, f):
>>         return f[self.name] *| {ref(self.name <http://self.name>)}*
>>
>> After that,
>>
>> def is_leftrec(rule):
>>    return ref(rule.name) in rule.LL_LOOKAHEAD()
>>
>> Nullabillity is `() in exp.LL_LOOKAHEAD()`, and so on.
>>
>> Would anyone be interested in confirming these results?
>>
>> I'm interested because of the  the LL lookahead algorithm is simple
>> enough to implement on my ongoing projects. This is FIRST:
>>
>>     def _calc_first_sets(self, k=1):
>>         f = defaultdict(set)
>>         f1 = None
>>         while f1 != f:
>>             f1 = copy(f)
>>             for rule in self.rules:
>>                 f[rule.name] |= rule._first(k, f)
>>
>>         # cache results
>>         for rule in self.rules:
>>             rule._firstset = f[rule.name]
>>
>>
>> Regards,
>>
>>
>>
>> On Mon, Jun 10, 2019 at 5:20 PM Juancarlo Añez <apal...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> When looking at the resolutions of PEG/leftre with IS_NULLABLE,
>>> IS_LEFTREC, it occured to me that the same could be solved, perhaps in a
>>> more algebraic way, by using LL FIRST/FOLLOW analysis with the modification
>>> of allowing RHS symbols in the sets.
>>>
>>> IS_NULLABLE(rule) == e in pFIRST(rule)
>>> IS_LEFTREC(rule). == rule inf pFIRST(rule)
>>>
>>> Something like that.
>>>
>>> Has anyone explored this approach.
>>>
>>> TIA, and Cheers,
>>>
>>> --
>>> Juancarlo *Añez*
>>>
>>
>>
>> --
>> Juancarlo *Añez*
>> _______________________________________________
>> PEG mailing list
>> PEG@lists.csail.mit.edu
>> https://lists.csail.mit.edu/mailman/listinfo/peg
>>
> _______________________________________________
> PEG mailing list
> PEG@lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/peg
>


-- 
Juancarlo *Añez*
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg

Reply via email to