RE: Using Bison as Haskell parser generator

2002-10-17 Thread Simon Marlow
 (I am currently not on this list, so replies, please cc me.)
 
 The later versions of the GNU parser generator Bison, like
   ftp://ftp.gnu.org/gnu/bison/bison-1.75.tar.gz   (959 KB)
   ftp://ftp.gnu.org/gnu/bison/bison-1.75.tar.bz2  (759 KB)
 use the macro processing program M4 to produce the source code output.
 
 This should make it real easy to write parser generator 
 (skeleton) files
 designed for special languages.
 
 So I wonder if somebody may want to make an attempt to produce such
 skeleton files for Haskell. Bison has now not only an LALR(1) parser
 algorithm, but also a GLR parser, and more is to come.

Note that Happy has support for some Haskellish things which you won't
get if you use bison to generate Haskell.  For example: type signatures
on productions, and support for threading a monad around the parser.

Nevertheless, doing this sounds entirely feasible.  The parser tables
generated by bison are very similar to those generated by Happy (I
peeked at bison's source when I wrote the table-generation code in
Happy), so looking at Happy's LALR(1) machine might be a good place to
start.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: Using Bison as Haskell parser generator

2002-10-17 Thread Martin Norbäck
tor 2002-10-17 klockan 17.32 skrev Simon Marlow:
 Note that Happy has support for some Haskellish things which you won't
 get if you use bison to generate Haskell.  For example: type signatures
 on productions, and support for threading a monad around the parser.

Another feature which I would love to have in Happy is support for more
EBNF stuff, like repetition and alternative.

Repetition maps to Haskell lists and alternative maps to haskell Maybe.

Since there exists a transformation from EBNF to BNF this should be
possible. Also, the transformation can take certain things into account,
like that parsing a list of things is best done like this (due to the
parser being LALR)

list_of_things ::=
  empty | list_of_things thing

instead of this more natural way

list_of_things
  empty | thing list_of_things

Regards,

Martin

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell



RE: Using Bison as Haskell parser generator

2002-10-17 Thread Hans Aberg
At 16:32 +0100 2002/10/17, Simon Marlow wrote:
 So I wonder if somebody may want to make an attempt to produce such
 skeleton files for Haskell. Bison has now not only an LALR(1) parser
 algorithm, but also a GLR parser, and more is to come.

Note that Happy has support for some Haskellish things which you won't
get if you use bison to generate Haskell.  For example: type signatures
on productions, and support for threading a monad around the parser.

I am not sure what these type signature are:

But Bison has a typing feature currently only used with the implementation
of unions. It is easy to tweak to become only a typing feature (not tied to
C union in implementation). By macros, one can then write out a suitable
form of the semantic variables to extract the correct typing.

I am not sure what exactly this threading a monad around the parser means:

But under C++, I am now wrapping C++ namespaces around my parser. I have
suggested that Bison should get a construct
  %define name definition
producing a suitable macro handed over to M4. Thus, I should be able to write
  %defined namespace name
and exploit that to create a suitable namespace around the parser.

Such a procedure is sufficiently general that it ought to be able to handle
your monad wrapping as well. -- But one can only know for sure by actually
trying, and the feedback from such a try might be interesting.

Nevertheless, doing this sounds entirely feasible.  The parser tables
generated by bison are very similar to those generated by Happy (I
peeked at bison's source when I wrote the table-generation code in
Happy), so looking at Happy's LALR(1) machine might be a good place to
start.

Then interaction between Happy and Bison might turn out to be interesting.
The Bison people may also want parser generator sources in other languages,
functional like LISP (Scheme), SML, as well as others.

I am not myself actively programming in Haskell now, so that is one reason
I posted it.

I should have mentioned that more info about Bison can be found on its
mailing lists:
  [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-bison
  [EMAIL PROTECTED]  http://mail.gnu.org/mailman/listinfo/bug-bison

  Hans Aberg


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell