Pugs

HsSyck Cabalized.

One-sentence summary: Pugs's Syck binding recently ported to use Data.ByteString, is now available for all

Like the venerable MakeMaker, the Haskell Cabal build system greatly simplifies the task of writing distributable Haskell library.  However, just like early version for MakeMaker, it is a pain to write a portable Pugs.cabal across 1.0 (shipped with GHC 6.4 and 6.4.1), 1.1.3 (shipped with some distros), and 1.1.4 (shipped with GHC 6.4.2).

One particularly annoying misfeature of Cabal 1.0 is that it does not support multiple location of source files; this was responsible for the accumulated third-party code under the src/ tree. However, that also created numerous build problems, such as the dreadful "Syck_stub.o not found".

In Israel, we worked around these issues by forcing a rebuild of our Syck binding (Data.Yaml.Syck) on every "make", and then massage the resulting object file back to libHSPugs.a by manually invoking ar.  It's all in all very fragile.

Motivated by the licensing-cleanup effort of moving all non-Pugs modules from src/ to third-party/, and dakkar++'s report of a new crop of build failures with Cabal 1.1.3, I refactored out Syck into its own subdirectory, built automatically as part of "perl Makefile.PL". (It may move to "make" time in the future.  Not sure...)

ohis not only sped up build time (by 20 seconds here) and removed a primary fragile spot from our build system, but also let other lambdafolks write YAML bindings with much more ease. Yay! :-)

SoC, MacIntel, etc.

At xerox++'s suggestion, this year I factored Haskell-related tasks from Pugs and listed them as part of  haskell.org project ideas for Google's Summer of Code, and listed myself as a mentor on both Haskell.org and the Perl Foundation.  The perl.org project ideas list already has some Pugs-related items -- a port of DBI::PurePerl to Pugs, for example -- and I look forward to add more ideas to both lists in the days to come.

Also, thanks to xerox's effort, Pugs is now running on MacIntel, using Wolfgang Thaller's preliminary GHC 6.5 build. This of course made me wonder if I should give in and get a Pro 17" now, or wait for a probably more stable (and certainly less expensive) NonPro 15"...  I guess I'll sleep on it. :-)

Building the next Haskell.

One week ago, the Haskell' (Haskell prime) process was announced to the public. Our goal is designing a successor to the Haskell 98 standard.  The current timeline is to finish up the standard by October 2006, backed with conforming implementations shortly after that.

The process is worth writing about, as it's markedly different from the Perl 6 process, with different community dynamics and design constraints.  From now on I'll record my musings here in the newly created "Haskell" category.

Perhaps the most obvious difference is that of "only perl runs Perl" versus multiple implementations.  The HaskellExtensions page lists the beyond-Haskell-98 features supported by the four leading compilers (GHC, Hugs, NHC, JHC), and most of the proposals are simply ratifying those experimental features that worked.  Some proposals are expressed as textual diffs from the Haskell 98 standard, which allows for concise discussion on both denotational and operational grounds.

The good thing about this model is that it's sane, mostly predictable, and very efficient. The drawback is, of course, that it only makes existing Haskell users (much) happier -- the scope of Haskell stays essentially unchanged.

On the other hand, the Perl 6 process is exploratory. It has a evolving spec, an evolving runtime, and an evolving compiler that targets multiple evolving backends, relying on the sheer number of library writers and users to keep the use cases real and the unit tests accurate.

This is good for expanding Perl from its (already very diverse) niches to even more places, by  keeping the language as multi-paradigmed as possible. The drawback is that without a solid semantic model, most arguments become effective only on ergonomic fronts, and does little to improve the language's soundness.  Many times we've found that two features that looks sane independently simply doesn't mix together (magical pairs and bindings comes to mind), and it's discovered only through trying out real programs in Pugs.

So... I think there's something to learn from each other, and that will be my primary focus in the Haskell' comittee in the months to come.  As a concrete example, Haskell' can really use Perl 6's Unicode model -- and I still owe them a proposal on this.  But sleep+release Pugs 6.2.11 comes first...