proposal: standardize interface to Haskell' implementations

[Henrik Nilsson]

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 at 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.