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!-)