Subject: Language grammar opinions

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 8 Jan 2007 16:10:09 +0000

Unlike my previous message, this is my opinions on the proposed language
grammar. It's mostly based on the comments in the grammar.

I prefer to list the possible declaration types in the grammar, so would
prefer the commented-out version of "declaration".

There's a parsability problem. Consider the sequence:

    alpha, bravo, charlie, delta, echo, foxtrot, golf, hotel, india,
    juliet, kilo, lima, mike, november, oscar, papa, quebec, romeo,
    sierra, tango, uniform, victor, whisky, x-ray, yankee: zulu

Only after you see the next token (semicolon or comma or arrow) do you know
if this is a declaration with an unknown type, or a transition. This
produces a shift/reduce conflict in yacc or other such parser generators.
To resolve it, I would suggest reversing the order of declarations to
*begin* with the type:

    STATE : alpha, bravo, charlie ;

I'd also make the various types be reserved words, so you can't have a
state called "message" or an action called "state".

In fact, looking further, I suggest that assignments are actually a form of
declaration and can both be written the same way:

    Title = "My example (version 2)";
    STATE = alpha, bravo, charlie;
    Initial = alpha;

and be the same concept in the grammar. Using = will eliminate some parsing
problems.

Identifiers like foo----bar: I know this looks strange, and it's possible
to write a syntax that forbids it:

    identifier = ALPHA *(["-"] 1*ALNUM)

but I'm not convinced that it's worth it. Note that ABNF itself allows both
double dashes and trailing dashes. However, I think we could usefully avoid
allowing "x----->x---" to be valid.

[Oops, omission in my last message: I defined ALNUM.]

I see no benefit in restricting the characters in double-quoted names. At
the very least, why allow comma and semicolon but not full stop and colon?
Why not allow parentheses? I would simply define it as:

    dquote-chars = SP / %x21 / %x23-7E
        ; Space and all printable characters except double quote

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |

_______________________________________________
Cosmogol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cosmogol

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 9 Jan 2007 23:05:32 +0100

On Mon, Jan 08, 2007 at 04:10:09PM +0000,
 Clive D.W. Feather <[email-masked]> wrote 
 a message of 61 lines which said:

> I prefer to list the possible declaration types in the grammar, so
> would prefer the commented-out version of "declaration".

One of the traps here is that ABNF strinsg are case-INsensitive so
this would be a problem if we switch to Unicode and it would be
inconsistent with the (current) rule that in Cosmogol, everything is
case-sensitive.

Do note how JSON solved it (RFC 4627):

         false = %x66.61.6c.73.65   ; false

         true  = %x74.72.75.65      ; true

Yes, instead of:

         false = "false" ; :-(
 
> Only after you see the next token (semicolon or comma or arrow) do
> you know if this is a declaration with an unknown type, or a
> transition. This produces a shift/reduce conflict in yacc or other
> such parser generators.

More precisely, with LR parsers like the ones generated by Yacc. LL
parsers do not have the problem.

>     STATE : alpha, bravo, charlie ;

Why not. It looks like C :-)

> I see no benefit in restricting the characters in double-quoted
> names. At the very least, why allow comma and semicolon but not full
> stop and colon?

This is completely arbitrary. We should allow at least, square
brackets (RFC 2960), slashes and < and > (draft on shim6), dots, etc.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Wed, 10 Jan 2007 16:44:20 +0000

> inconsistent with the (current) rule that in Cosmogol, everything is

I'm aware of this. Yes, it makes the ABNF look slightly nauseating, but
that's a relatively small burden to bear.

[One option would be to define our own extension to ABNF to specify
case-sensitive strings. Um:

    false = !"false"  ; case-sensitive

I might talk to Paul Overell about it, since he's co-author of 4234 and a
colleague.]

> parsers do not have the problem.

Only if you fudge around it (and the same can be done with LR parsers).

> Why not. It looks like C :-)

A bit, yes. Combined with my proposed syntax for transitions, it means that
you could make the keywords be case-insensitive if you wanted (I'm neither
supporting nor opposing this) because there's no conflict.

> brackets (RFC 2960), slashes and < and > (draft on shim6), dots, etc.

Right. So why forbid anything (except " itself and possibly one escape
code)?