proposal: standardize interface to Haskell' implementations

[Claus Reinke]

eeek! how negative!-)

would all pessimists and nay-sayers please return to their seats,
fasten their seat-belts and refrain from smoking - the haskell'
process is preparing for lift-off!

by cs standards, Haskell is _old_. it already was old when java
entered the scene, and java is not exactly the new kid on the block.

the *only* reason why such things would be impossible now 
would be if we once again decided not to do anything about them.

when java was new, they completely ignored reflection support.
even when it turned out to be badly needed in practice, it was
only added in half-hearted and incomplete ways. iirc, it was 
only at about version 1.2 that reflection support was beginning
to be taken seriously, and the transition pains, incomplete and
unstable apis where considerable. but by today, we find 
ourselves in a situation where _proposals_ for the advanced
research vehicle Haskell refer to _current practice_ in the dull
industry standard Java. where does that leave us?

you're right that not all haskell implementations are the same.
perhaps you even underestimate the differences: even those
implementations that already have an interactive loop and are
implemented in haskell will not usually have the ast/type info
in whatever form the standard will require.

the point is to standardise an api to functionality that all
haskell implementations will need in some form or other and 
that all haskell tools should be able to depend on. whether 
that api is implemented as a separate haskell library like a 
haskell-src-exts package extended with type info, or whether
that api is implemented by converting internal formats to
standardised structures is a completely different matter (do
you remember "hmake interactive"?-).

i was *not* suggesting to standardise how things are 
*implemented*, but how things are *used* and *presented*.
you will notice that my main list was limited to facilities needed in
every implementation, with features that might only be partially
available (pretty-printing, evaluation) in parentheses.

it does not matter whether your optimizer is implemented by
posting sources to the programming language shootout, whether 
your parser is based on neural net hardware, or whether your
full type system is going to puzzle type theoreticians for years
to come. what matters is that you are trying to implement haskell',
and you have to parse and type-check source code and produce
user-readable error messages. and if it type-checks, there will
presumably be some means to run the thing, right?

these things need to be implemented, but they should not
have to be implemented again and again in every tool. that
is exactly what a standard is for! even (n+1) implementations
(n proper haskell' implementations and 1 haskell'-in-haskell'
standard library) would be an improvement over the situation 
we have today. naturally, the haskell' implementers would be
_very_ keen to optimize their version of the haskell'-in-haskell' 
library _if_ they want all those tools to be useable with _their_ 
implementation..

>> [an innocent question
>I know this was me, and various things I do would be a LOT easier if
>this standard interface did exist, but I don't think its possible.

as I was trying to explain, you are far from the first person in that
situation. but if Haskell' makes a start on the issue, you might become
one of the last persons with that problem!

>Maybe, as all the various implementations stabalise and start to
>provide some API's, in the future it will be possible to write a
>standard library that translates between the various API's and then
>you would have a standard interface. Unfortunately, I think thats
>still years and years away.

that's what I was thinking at around 1997, when I first felt the need
for this kind of API. unless we change our thinking into something
more optimistic, this kind of thing is never going to happen!

cheers,
claus

>And as someone who uses Ada on a weekly basis, I'm opposed to 
>doing anything similar to Ada in any way ;)

oh, i'm only using it when i want to refer to voluminous standards!-)