October 2002 - Haskell

The Implementation of Functional Programming Languages
by Jose Romildo Malaquias 17 Oct '02

17 Oct '02

Hello. Is the book "The Implementation of Functional Programming Languages", by Simon Peyton Jones, available in the internet? This book is out of print. Romildo -- Prof. José Romildo Malaquias romildo(a)uber.com.br Departamento de Computação malaquias(a)iceb.ufop.br Univ. Federal de Ouro Preto http://uber.com.br/romildo

2 2

RE: Using Bison as Haskell parser generator
by Hans Aberg 17 Oct '02

17 Oct '02

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: help-bison(a)gnu.org http://mail.gnu.org/mailman/listinfo/help-bison bug-bison(a)gnu.org http://mail.gnu.org/mailman/listinfo/bug-bison Hans Aberg

1 0

RE: Using Bison as Haskell parser generator
by Martin Norbäck 17 Oct '02

17 Oct '02

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

1 0

RE: Using Bison as Haskell parser generator
by Simon Marlow 17 Oct '02

17 Oct '02

> (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

1 0

Call for contributions - HC&A Report (November 2002)
by C.Reinke 17 Oct '02

17 Oct '02

Dear Haskeller, the leaves are falling again (this time in the northern hemisphere). That means it will soon be time for the next edition of the Haskell Communities & Activities Report http://www.haskell.org/communities/ and this is your invitation to contribute to that edition (the 3rd). The current plan is to get contributions in by the end of October, and to get the collective report out early next month (*). The general idea is to update all existing summaries (these reports are really about recent/current activities), to drop any topics that haven't had any activity for two consecutive 6-month periods, and to add any new developments or topics for which no-one contributed summaries to the previous edition, while trying to keep the whole within 25 pages. As you can see on the report's potential topics page, many of last time's contributors have already volunteered to provide updates of their reports. But where you don't yet see contacts listed for your own subject of interest, you are welcome to volunteer, or to remind your local community/project team/mailing list/research group/etc. that they really ought to get their act together and let the Haskell community as a whole know about what they've been doing!-) A typical summary report would be between 1 and 3 paragraphs (what's it about? major topics and results since the last report? current hot topics? major goals for the next six months?) plus pointers to material for further reading (typically to a home page, or to mailing list archives, specifications and drafts, implementations, meetings, minutes,..). New suggestions for current hot topics, activities, projects, .. are welcome - especially with names and addresses of potential contacts. Two particular new suggestions we tried last time worked quite well, so we'll keep them: 1 Applications: "what are you using Haskell for?" If you're one of those serious Haskell users who sends in bug reports and feature suggestions to the implementation mailing lists, but has not yet announced or released your software, why not write a sentence or two about your application? We'd be particularly interested in your experience, with the existing tools (e.g., that all-time-favourite: how difficult was it to tune the resource usage to your needs, after you got your application working? Which tools/libraries were useful to you? What is missing?) and with the general suitability of Haskell for your application/area. 2 Project pings: "anyone still working on this?" If you are the contact person for a project/software in "silent maintenance mode", and you just want to reassure Haskellers that your stuff is still actively maintained, useable and up-to-date, even though you no longer add new features every week, send me a brief "ping", and I'll try to include those pings, with contact addresses (as proofs of liveness), in the upcoming report. Thanks, Claus (*) Experience has shown that it takes an arbitrary number of weeks to write a nice summary in the last hour, so I hope that the next 2 weeks give enough flexibility to find a spare hour, or to coordinate the summary with any planned releases. -- Haskell Communities and Activities Report (November 2002 edition) All contributions are due in by the end of October! http://www.haskell.org/communities/

1 0

Using Bison as Haskell parser generator
by Hans Aberg 17 Oct '02

17 Oct '02

(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. I am aware of that there are parser generators written in Haskell (like Happy), but the advantage with this Bison approach is that one can more swiftly switch between different parsing algorithms and output languages. -- The basic elements of the parser generating algorithms is language independent, and only the implementation of the push-down automaton needs to be done in each language. Or so is the idea. Hans Aberg

1 0

RE: forall and class contexts
by Ashley Yakeley 16 Oct '02

16 Oct '02

At 2002-10-16 00:40, Simon Peyton-Jones wrote: >Not currently, but I think it makes sense, and I'll implement it if >enough people ask. That's two. FWIW, my pint offer still stands. >Presumably you mean 'instance' not 'class'? A class decl always has a >type variable after the =>; thus ...=> C a. Unless Wolfgang meant class (Eq (forall a. t a), Monad t) => C t -- Ashley Yakeley, Seattle WA

2 1

RE: forall and class contexts
by Wolfgang Jeltsch 16 Oct '02

16 Oct '02

On Wednesday, 2002-10-16, 09:40, CEST, Simon Peyton-Jones wrote: > > I want to define something like > > class (Eq (forall a. T a), Monad T) => C T > > where the context shall mean that T has to be an instance of Monad > > and > > that for every type a the type T a has to be an instance of Eq. > > Is such a thing possible with some Haskell implementation? > > Not currently, but I think it makes sense, and I'll implement it if > enough people ask. > > Presumably you mean 'instance' not 'class'? A class decl always has a > type variable after the =>; thus ...=> C a. Hello again, I mean "class" but I have made a mistake in the code above: The uppercase T should be a lowercase t. > There aren't many type constructors T for which T a is an equality > type... I only wanted to illustrate what kind of construction I'd like to have by using standard Haskell classes. In my application I don't use Eq. > Simon Wolfgang

1 0

RE: forall and class contexts
by Ashley Yakeley 16 Oct '02

16 Oct '02

At 2002-10-16 01:07, Ashley Yakeley wrote: > class (Eq (forall a. t a), Monad t) => C t more logically, class (forall a. Eq (t a), Monad t) => C t -- Ashley Yakeley, Seattle WA

2 1

RE: forall and class contexts
by Simon Peyton-Jones 16 Oct '02

16 Oct '02

| I want to define something like | class (Eq (forall a. T a), Monad T) => C T | where the context shall mean that T has to be an instance of Monad and | that for every type a the type T a has to be an instance of Eq. | Is such a thing possible with some Haskell implementation? Not currently, but I think it makes sense, and I'll implement it if enough people ask. Presumably you mean 'instance' not 'class'? A class decl always has a type variable after the =>; thus ...=> C a. There aren't many type constructors T for which T a is an equality type... Simon

2 1