proposal: standardize interface to Haskell' implementations

[Christopher Brown]

Claus,

I totally agree with you on this. With experience of developing HaRe  
and realising the limitations of using one compiler front end over  
the over. It would be so much easier to have a standard API - so that  
projects such as HaRe could be easily ported to another system if  
needs be - instead of a complete rewrite of the entire system.

I'm not quite sure I fully understand how you intend on making things  
like the AST standard? Have a standard AST structure?

It certainly worth some serious thought though...


Chris.



On 13 Feb 2006, at 10:29, Claus Reinke wrote:

> 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!-)
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://haskell.org/mailman/listinfo/haskell-prime

Christopher Brown
Ph.D. Student University of Kent. UK.
http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html