Application letters at the Haskell workshop: suggestion

[Ashley Yakeley]

At 2001-09-13 16:00, Lennart Augustsson wrote:

>I have been writing substantial Haskell programs and I use *NO* experimental
>features.  What I'm currently working on is over 20000 lines of Haskell 98.
>No extensions whatsoever.  (It even compiles and runs with all available
>Haskell implementations.)
>Granted, I write mostly compiler like programs (files in, files out), but 
>there
>is still a lot you can do in Haskell just as it is.  Sometimes it might 
>require
>bending slightly backwards to get it done, though.

Just as an alternative voice to this orgy of macho austerity...

I'm currently working on two Haskell projects. _JVM-Bridge_ is a bridge 
from Haskell to the Java virtual machine. I use FFI (obviously), and in 
one place existential types. I admit I haven't really needed more for 
that project, but also I've tried to minimise extension use for the sake 
of possible porting etc.

http://sourceforge.net/projects/jvm-bridge/

_Truth_, by contrast, is heavily dependent on class functional 
dependencies and probably even Hugs -98 wouldn't be able to deal with it. 
_Truth_ is a largely experimental project the nominal goal of which is to 
represent access to all information. 'Experimental' here means it's not 
likely to do anything useful anytime soon and frankly more resembles a 
work of art at this point. It's based on a solution I found to a problem 
I posed to this list ten months ago ("Imperative Object Destruction") 
that involves statically typing bits of imperative code based on what 
'objects' they destroy, make use of, and create.

http://sourceforge.net/projects/truth-framework/

Even with all the clever stuff I do with fundeps, the code would be 
simpler, cleaner and more general with certain extra extensions: most 
obviously if GHC were a bit smarter about whether or not instances 
overlap, but perhaps I could also make use of extensible algebraic 
datatypes. Empty datatypes would be nice for aesthetic reasons too, but 
of course there's a trivial workaround (providing a dummy constructor).

>PS. OK, a small confession, that program contains one unsafePerformIO for
>performance reasons.  It works fine without it, but 5% slower.

On the other hand, I don't do any unsafe anything anywhere. But I'm 
nowhere near performance tuning...

-- 
Ashley Yakeley, Seattle WA