Dear all, Claus Reinke wrote:
what I have in mind are things to come, which would be quite different from the initial steps we could reasonably expect Haskell' to take. initially, a separate libary may be an acceptable start; but ultimately, I don't want two separate Haskell implementations shipped for each installation.
for the moment, I'd like the Haskell' committe to say this is useful, and commit to making a start, then see how far we can get.
I don't think anyone is saying a library like this would not be useful.
at the very least, Language.Haskell needs to be expanded on, to cope with modules, to provide type information, and to cope with language extensions [...] But ultimately, there will be ramifications for future language definitions (how to pass from programs to representations and back? how to type these things? how to extend programs at runtime? [...] Simon M adds extensible data types to the list. I'm sure there's more, once we start looking.
I find it interesting to note the the folks who claim this is a libary-only problem are willing to put up with lots of non-Haskell' hacks [...] I'd prefer to flush out these secret hacks hidden in so-called libraries, and to call a language feature a language feature.
Point taken. However: 1. I'm sorry, but it seems to me that the scope of the project you are suggesting is just way beyond what possibly could fit within the Haskell' effort. 2. It seems the language features you would need standardized to be able to design suitably comprehensive and flexible library (like extensible data types) are also way beyond what we can hope to cover within the Haskell' effort. At this point it is not even clear what these features really are. Thus, if it at this point is can be convincingly argued that there is a small, well-defined set of some minor extensions that, if they were part of Haskell', would make it possible to do a substantially better job than the present "Haskell.Language", then that case should be made. But, in my opinion, arguing that case must not amount to a complete library design: there just isn't time for that. Otherwise, I'm sure a separate effort to standardize an interface to Haskell<whatever>, would yield some very valuable input to design of the next major version of Haskell. Yes, not doing that work as part of the Haskell' effort or in parallel with it, might mean that Haskell' isn't as "future proof" as it ideally should be. However, I think the next major Haskell revision is likely to include some changes that breaks backwards compatibility seriously anyway, so I am not too worried about that. All the best, /Henrik
"Ideals are like stars. You may never be able to reach them, but you can navigate by them."
Not terribly accurately though, which is why they invented GPS. :-) -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.