Re: nyacc 0.65.0 released

[Matt Wette]

> On Dec 30, 2015, at 8:11 PM, Nala Ginrut <address@hidden> wrote:
> 
> That's very nice! Thanks for all the work!
> This may provide new weapon for our multi-lang plan.
> And I saw C99 parser in your code, I think it's helpful for building a
> better FFI code generator, and parse C code directly.
> 
> How's the javascript part? Is it completed one to cover ES6? And maybe
> it's good enough to replace our current ecmascript frontend?

I generated my lalr-spec from the ecmascript specification (ECMA-262).   
However, the spec is not LALR.   My desire is to extend nyacc  
to be able to handle this specification.  The idea is to be able to prune 
certain productions.  Also, in my opinion, implementing ecmascript to 
specification would be tough in guile for two reasons:
1) in ecmascript code points are 16 bits, in guile 32 bits
2) in ecmascript a number is a 64 bit number where certain bit patterns are to 
be interpreted as ints an others as floats

> Writing parser for an industry language is painful, it's better to take
> advantage of *.y files which has been written by other people already.

I’m not sure I get what you mean here.  I started with some C99 .y files on the 
net but I really wanted to be able to go back to a documented specification.  I 
then went to grammar spec in Harrison and Steele, “C: A Reference Manual,” 5th 
ed., but then found that that book had many gross errors in the grammar 
specification.  So I went to some draft spec’s I found on the net.    For the 
javascript I went to the ECMA-262 specification.


> And save our time to cope with the IR and optimizing part.

I’m not sure what you are getting at here.   Are you suggesting to adopt some 
other intermediate form.  I wanted something simple to work with.   The feature 
I really like about using SXML for the parse trees is that I can then use ice-9 
pretty-print to see the structure.  It has been really helpful in my projects 
derived from nyacc.

> I still don't understand what's the meaning of gram.y in your project.
> Does nyacc use it?

The gram.y file is generated from the nyacc/export module.  It has no direct 
use in the parsers.  I have run this file through “bison -r all” to generate 
the machine description in order to validate my parsers (by hand).  A feature 
that would be nice is to use the xml-format of bison to generate an automated 
validator.  One possible issue here is that bison token precedence is totally 
ordered whereas nyacc is partially ordered.

Matt