BNF rule names and groups

[jeffreykegler]

Re the new names feature. A few thoughts.

1.) LUIF should prefer Lua syntax for tis features. The BNF statements in that sense are an exception, but BNF is so convenient and well-known a way of writing rules, that the exception is merited. Pure LUA hacks should be preferred to novel BNF extensions. The reason is that Lua is already known and well-documented.

2.) A important feature of names in the SLIF is having a unique way to identify rules. Grouping rules for naming purposes of course defeats this.

3.) Perhaps what you want are rule groups, in addition to names. I'm open to that, but what's the use case?

Where I speak of Pure Lua syntax for groups, I have in mind something like:

grammar.set_rule_groups{ "group1", "group2" }
a ::= b c
d :: = e f g h | x y z
do :: re mi

Less elegant perhaps, but more orthogonal.

[rns]

I think I have to elaborate — If we have a group of rules

a ::= b c
d ::= e f g h | x y z
do :: re mi

we can translate it to pure lua as, e.g.

a = { 'b', 'c' }
d = { { 'e', 'f', 'g', 'h' }, { 'x', 'y', 'z' } }
do = { 're', 'mi' }

but that leaves us with just 3 lua tables -- we don't know (1) how to group these 3 rules to grammar(s) and (2) good name(s) for such grammar(s). Ways to handle (1) and (2) I considered:

1. demand that the user insert grammar.set_rules(a, b, do) or some other grouping and naming statement somewhere after the rules -- check for that at the translation phase and warn 'don't know how to build the grammar' if it can't be found -- that's what you suggested for rule groups.
2. consider any contiguous group of rules to be a grammar of its own and set the name of the first symbol in the group as the grammar name.
3. add an optional header to a contiguous group of rules to map them (and all others until the next such statement) to a named grammar -- that's what I tentatively selected, sans the optionality, so far.

Now, 1. -- would allow mixing BNF stats with other Lua stats -- this intuitively looks like a good thing, e.g. for programmatic grammar construction.

2. -- Doesn't require any more extension of Lua syntax, which is good, but looks rather error-prone.
3. sort of violates Lua syntax, adds a foreign keyword

Now that I'be written all the above, I'm tempted to add BNF (from stat :: BNF per your very first design) as en exp rather then stat

    exp ::= BNF

that will solve the above problem by allowing (what seems to me a natural Lua)

a_b_do =
  a ::= b c
  d ::= e f g h | x y z
  do :: re mi

and would open the way to all sorts of other interactions between BNF and Lua constructs we can define.

Otherwise, we can do 1. or 2. or 3.

[rns]

Thinking aloud, adding ::= as a Lua binop with 'make a lua table representing BNF rule of what follows' semantics can produce a fully-programmable BNF, where

• symbols can be defined, e.g. by function calls returning strings,
• BNFs can serve as functioncall parameters, e.g. parse(BNFexp, input) construct is possible
• actions can be defined/dispatched based on BNFexp's as function eval(BNFexp);
• metatables' methods can be implemented on BNFexps for language composition.

[jeffreykegler]

The

    g = do grammar
      a ::= b
      c ::= d
    end

idea has grown on me. But I'd want to add something that gives the "block" nature of it more prominence -- something along the lines of the do grammar ... end syntax above.

BNF statements outside a do grammar block would go into a default grammar. Perhaps we'd want to make it a fatal error to, in the same LUIF script, mix use of the default grammar with the use of explicitly defined grammars

[rns]

The idea of default grammar looks good to me.

As for explicitly defined grammars,

g = BNF do 
  a ::= b
  c ::= d
end

is somewhat more in line with Lua pattern of <keyword> Name | exp <do> block <end> stats as, e.g. in

<for> Name ... <do> block <end>, 
<while> exp <do> block <end>

Also, such pattern as <local> <function> Name block <end> suggests

local BNF g (...)
  a ::= b
  c ::= d
end

optional (...) can be grammar-wide properties, e.g. default statements or some such.

[jeffreykegler]

Let me think about this. With respect to a new, highest-visibility keyword:

Pro: It's orthogonal, as you point out. Con: It maximizes chance of incompatibility with other syntaxes, Lua extensions, futures, etc.

So there are reasons to go either way.

[rns]

Sure, I'll be watching the Kollos/design dir and this space. While we are at it,

local g = 
  a ::= b
  c ::= d
end

would closely (sans the new grammar or BNF keyword) resemble Lua's native

local f = function f()
  a = b
  c = d
end

[jeffreykegler]

After reflection, I think we may as well "go for it", as you suggest. A new high-visibility grammar keyword, like a function:

g = grammar ()
    a ::= b c
    d ::= x y z
    ....
end

[rns]

Ok, let's go for it, I'll keep you informed.

[jeffreykegler]

Great! I'll close this.

[rns]

Ok, thanks.