Gentle Haskellers, A few weeks ago (following POPL) there was an informal meeting of some people involved in implementing Haskell. In this message I summarise some of the things we discussed, because I think many of them will be of general interest. People with actions are in CAPITALS. Key: MANUEL Manuel Chakravarty SIGBJORN Sigbjorn Finne JOHN John Launchbury ANDREW Andrew Tolmach MALCOLM Malcolm Wallace HENRIK Henrik Nilsson OLAF Olaf Chitil SIMON M Simon Marlow SIMON PJ Simon Peyton Jones Simon ================================================================= Haskell Report ~~~~~~~~~~~~~~ SIMON PJ still hasn't put out the revised H98 report. Jump to it! Foreign Function Interface ~~~~~~~~~~~~~~~~~~~~~~~~~~ Going splendidly, but needs writing up as a proper "Blessed Addendum" to the H98 report, so that compilers can say "I implement H98 plus FFI". MANUEL agreed to be Editor for the Addendum, and drive the process. H/Direct and Green Card: SIGBJORN is going to work at Galois, and will continue to look after and develop these tools. Indeed, he's already started hacking on them again. Hooray! Haskell implementation ~~~~~~~~~~~~~~~~~~~~~~ Hugs: OGI in maintenance mode. There's a danger that Hugs will gradually die, which none of us want. One idea: advertise openly for a home for Hugs. JOHN will take this suggestion to OGI. nhc: Being actively maintained and developed at York GHC: 4.08.2 release imminent Simon M and Julian gave a demo of the upcoming interactive GHCi demo; release expected in a month or two. We agreed that it would be a Jolly Good Thing if GHC could be persuaded to produce GHC-independent Core output, ready to feed into some other compiler. For example, Karl-Filip might be able to use it. ANDREW will write a specification, and implement it. MANUEL is writing an inside-the-monster roadmap. He'll put it in fptools/ghc somewhere, so others can add to it. Haskell Libraries ~~~~~~~~~~~~~~~~~ MALCOLM produced a proposal for a (tiny) language extension that would give us a hierarchical name space for modules (a la Java). We loved it. He will refine it into a concrete document to circulate more widely. We agreed (again) about the importance of libraries. The "hslibs" libraries are a good start. They are *not* part of GHC, even though they happen to live in the same CVS repository. We agreed they should stay there, but should have a less GHC-specific build/test system. We appointed a troika of Library Supremos, namely MALCOLM, SIMON M, ANDY Specific tasks: - get closure on Malcolm's module-naming proposal - agree hslibs hierarchy - define documentation standards - act as gatekeepers for contributions SIMON M will create a mailing list for library discussions. Graphical user interfaces ~~~~~~~~~~~~~~~~~~~~~~~~~ We got a useful taxomomy: -------------------------------------------------------- High-level Fran/Tk Fudgets (Haggis) -------------------------------------------------------- Medium-level Clean Object I/O School of abstractions [GUI] Expression (SOE) [Graphics] -------------------------------------------------------- Low-level veneers HOpenGL Gtk Haskell/Tk Win32 X on existing [Graphics] libraries -------------------------------------------------------- Low-level veneers are going well -- but they are low level. High-level abstractions are pretty experimental. We need a medium-level GUI library. Peter Achten's port of the Clean Object I/O system looks like a great candidate. Well documented, lots of experience in use, about the right level. SIMON PJ to seek agreement from Nijmegen, and then advertise for someone to complete the port. OLAF will articulate the above taxonomy on haskell.org HaskellDoc ~~~~~~~~~~ We all loved Armin Groesslinger's HDoc tool. HENRIK will get in touch with him to invite him to collaborate on a standard tool we can all use. (Of course, it's up to him.) Two specific ideas: Take a Haskell source file into some XML-stuff, which can then be rendered in various ways. (Rather than going straight to HTML.) Use standard pragma syntax: {-# DOC ... #-} [Post meeting note: mailing list at <http://www.haskell.org/mailman/listinfo/haskelldoc> http://www.haskell.org/mailman/listinfo/haskelldoc ] Debugging ~~~~~~~~~ Hat (York): Expect a release in the Spring. In the summer they hope for a first cut at at an implementation-portable version Hood: ANDY plans to release his graphical version IDE ~~~ Galois are interested in working on Haskell-in-Visual-Studio. Haskell.org ~~~~~~~~~~~ Idea: have a "job adverts" page on haskell.org, for tasks that need doing. For example: * Integrate Haskell with "Source Navigator" * Offer libraries * Complete Clean I/O port * Contribute nofib programs * Contribute validation programs Action OLAF.
Dear Haskellers,
"Simon" == Simon Peyton-Jones <simonpj@microsoft.com> writes:
Simon> We agreed that it would be a Jolly Good Thing if GHC Simon> could be persuaded to produce GHC-independent Core output, Simon> ready to feed into some other compiler. For example, Simon> Karl-Filip might be able to use it. ANDREW will write a Simon> specification, and implement it. a good idea. Before ANDREW will put a lot of effort in the specification and implementation, it would be good to have a discussion about the core representation that is gradually evolving. There is the risk that the representation, made by insiders, will be too complicated to be used by several other people as I feel the core output currently produced by GHC is. It would be good to put all stuff related to this topic onto a WWW page, containing links to relevant papers, conventions, example pairs (Haskell source,core equivalent) which can be discussed. Before coming to the syntax, there are some interesting semantical questions that may be obvious for the implementers but not for the user, e.g., the data types that must be provided by a back-end for the core and the operational semantics of pattern matching and let-expressions etc. A toy interpreter (e.g., using happy) which interprets the core language and which is written with the goal of documentation, not under efficiency aspects, may be helpful. I'm not sure whether you like the idea, but a quick solution for a small subset of Haskell would, in my opinion, be smarter to the user, since her or she can get used to the representation and we have something concrete to discuss. Many thanks in advance! -- Christoph Herrmann E-mail: herrmann@fmi.uni-passau.de WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html
participants (2)
-
Ch. A. Herrmann -
Simon Peyton-Jones