action parameter list

[jeffreykegler]

The LUIF's function should (at least for now) all reside in a namespace (Lua table) associated with the grammar set. If functions in other namespaces or methods are wanted, for now this can be done indirectly -- I'm not at all sure about the implications of the LUIF defining them.

Also, bare functions don't need a parameter list. The parameter list is the RHS of the rule, in effect.

Related to this, we need to define the syntax for referring to the RHS symbols. Starting with the simple case, an alternative like X ::= A B C, we have parameters A, B, C. For X ::= A B A, they can be A:1, B, A:2. When you get into grouped subrules, sequences, nestring, etc., stuff gets hard, which is why I dragged my feet on those extensions.

Finally, I would also like to support the "angle-bracketed" form of the parameters in actions. This may create some parsing issues, since Lua also uses those for greater- and less-than, but we can hope those are not insuperable. By angle-bracketed, I mean for example, for the rule X ::= A B A, <A:1>, <B>, <A:2>.

[rns]

Bare functions only -- d7ee189.

As for parameter list/RHS -- perhaps we can get away with the parlist altogether and just use Lua tables and context accessors, e.g.

for X :: A B C:

-- all values
v = luif.context.values() -- { A = 'vA', B = 'vB', C = 'vC' }
vA = v.A, vB = v.B, vC = v.C
-- individual values
vA = luif.context.value('A')
vB = luif.context.value('B')

for X :: A B A:

-- all values
v = luif.context.values() -- { A = { [1] = 'vA1', [2] = 'vA2' }, B = 'vB' }
vA1 = v.A[1]; vB = v.B; vA2 = v.A[2]
-- individual values
vA1 = luif.context.value('A', 1) -- <A:1>
vB = luif.context.value('B')
vA2 = luif.context.value('A', 2) -- <A:2>

[jeffreykegler]

This continues the discussion of #11

[jeffreykegler]

Your prototyping may be revealing here. My guess is that you'll quickly
get tired of tables accesses and context functions and yearn for some
syntax extensions to Lua that recognize the RHS symbol names and translate
them into the table accesses or method calls.

But I might also be wrong. Perhaps syntax extension for the Lua code in
actions is over-engineering.

One tactic is to delay the syntax extensions until after the first phase of
prototyping, which will force you to use the underlying table accesses or
method calls. If that proves tiring, we can then add the syntax extensions.

On Mon, May 4, 2015 at 4:26 AM, rns notifications@github.com wrote:

Bare functions only -- d7ee189
d7ee189.

As for parameter list/RHS -- perhaps we can get away with the parlist
altogether and just use Lua tables and context accessors, e.g.

for X :: A B C:

-- all values
v = luif.context.values() -- { A = 'vA', B = 'vB', C = 'vC' }
vA = v.A, vB = v.B, vC = v.C-- individual values
vA = luif.context.value('A')
vB = luif.context.value('B')

for X :: A B A:

-- all values
v = luif.context.values() -- { A = { [1] = 'vA1', [2] = 'vA2' }, B = 'vB' }
vA1 = v.A[1]; vB = v.B; vA2 = v.A[2]-- individual values
vA1 = luif.context.value('A', 1) -- <A:1>
vB = luif.context.value('B')
vA2 = luif.context.value('A', 2) -- <A:2>

—
Reply to this email directly or view it on GitHub
#26 (comment).

[rns]

Well, shortcuts like local v = luif.context.value(); vA1 = v'A:2' can help.

I'm thinking along the same lines -- try luif.context.values() in prototyping and see how it goes.

Building an ast and providing a sort of DOM akin to https://github.com/rns/MarpaX-Regex/blob/master/lib/MarpaX/Regex/AST/Base.pm remains an alternative.