> In asking about e.g. generic programming, arrows, etc, I am
> not suggesting
> we converge on a standard right now. I am trying to explore how much
> stock the language implementors currently put into these
> proposals.
I can't speak for others, but I can give my own impressions. In general,
I'm keen to implement language and type system extensions that
i) have a concrete, sound, design that shows how to fit them
into the existing Haskell language,
and that even I can understand
ii) there is reason to believe that the design is a stable one
[very tiresome to implement something only to discover that
the goalposts have moved]
iii) don't take a vast amount of work to implement
iv) have clear enough benefits to a wide enough audience
to justify the costs
GHC has support for, among other things,
a) multi-parameter type classes,
b) universal and existential quantification in constructor args,
c) foreign langauge interface,
because they seemed to me to fall into the set.
I think that the following also fall into the set
d) records a la TREX
e) functional dependencies in type classes (a la Jones)
f) implicit parameters (a la Meijer/Lewis/Shields)
but we havn't implemented any of them yet. Jeff Lewis is doing
(e) in GHC, though, and all three are in (some version of) Hugs.
So far
g) polytypic programming
h) arrows
i) a hierarchial module system
...what else...?
don't fall into the set. It may be my own ignorance, but I can't
readily lay my hands on a document entitled "Proposal for adding
arrows to Haskell" for example. (In fact I agreed
with John Hughes that if he wrote such a proposal for arrows I'd think
hard about implementing it.)
It's one thing to describe a language feature in general; quite
another to express it as an extension to an existing language.
I don't want to give the impression that I think the advocates of
polytypism or arrows (...etc...) have done a poor job of describing
them. Far from it -- there are lots of papers about polytypism for
example, and it is fine work. But as a not-very-bright implementor
I'm just not going to get around to implementing a general idea; I
need a precise design.
There's a bit of a chicken and egg problem here: there is
not much incentive for folk to develop a design if there's no chance
that it'll be implemented. We have to solve that by iterating one step
at a time.
A recurrent theme of several threads on this list has been:
Haskell belongs to all of us.
If you are willing
to contribute, a good way to do so is to articulate (and refine through
debate) sound, concrete designs, whether for language features or libraries.
Producing such a design doesn't guarantee that it'll be implemented
(unless you implement it yourself, which is also possible). But not
producing
the design does pretty much guarantee that it won't be implemented! Sven's
wish list makes a good clearing house for such designs.
Simon
