Re: The Debian community should influence the next Haskell language standard
* Isaac Jones:
> I'd like to ask the Debian community to look at Haskell98 and some of
> the "research" extensions[2] and give us some input as to what would
> make Haskell more attractive to you.
Uhm, most of the things on Debian's (as opposed to individual
developer's) whishlist are quality-of-implementation issues, not
really language issues.
A sensible approach to separate compiliation, so that it's possible to
change the implementation of a module without having to recompile all
of its clients. This helps to avoid that packages in our
distributions are too closely coupled, which makes updating individual
components manageable (for example, to patch a security
vulnerability). Dynamic shared objects with stable ABIs across
compiler versions would be a nice benefit, but I understand that
implementing this is hard.
There should be compilers which are portable to Debian's release
architectures, which consume moderate amounts of memory (just a few
dozen megabytes, but pretty please not a few hundred) and are
reasonably fast. This means that Haskell programs won't bog down our
build daemons, so we can afford as many of them as we like.
We can cope with C++, so we shouldn't demand too much from other
languages. 8-)
Apart from that, I find your question a bit strange. Maybe that's
because Debian ships implementations for so many programming languages
that yet another one (or even a new revision of an existing one)
doesn't make a real difference. The separate compilation aspect is
important, but it currently does not matter much because Haskell
packages generally have very short dependency chains as far as other
Haskell packages are concerned.
On a more personal note, I found the non-predictable space behavior
very hard to deal with. I'd also like to see something like
unsafePerformIO in the language standard: a trapdoor into the IO monad
which may lead to the side effect happening multiple times, but which
is type-safe. (The rationale is that unsafePerformIO does occur in
real-world programs, so there seems to be a real-world demand for it,
but its horribly un-soundness makes it look really bad.) But I can
understand that tackling unsafePerformIO might take Haskell into a
direction the greater community has little interest in.
Reply to: