The Future of Haskell discussion at the Haskell Workshop

[Adrian Hey]

On Tuesday 09 September 2003 01:57, nilsson@cs.yale.edu wrote:
> Here is how Simon Peyton Jones summarized the discussion:
>
>     The conclusion I took away was this
>
>     There are undoubted advantages to having better records, but
>
>       (a) they all make the language more complicated
>
>       (b) there are many possible design choices
>             (not only has/lacks, but also record concatenation,
>             length vs depth subtyping, and more I'm sure)
>
>       (c) they almost certainly conflict with existing programs
>
>       (d) the existing system is really not too bad

I rarely use named fields in my Haskell progs with Haskell as it is
for 2 reasons..
 1- The field names must be unique
 2- In ghc at least, you can't mix field names with existential
    quantification (well you couldn't last time I tried it:-)

>     That all argues for the status quo.

IMHO preserving the status quo wrt records should be low priority.
It really doesn't bother me much if new (useful) language features break
existing code. I think this is a better option than permanently
impoverishing the language and/or forcing users to migrate their
entire code to some other less impoverished language which may
appear in the future.

What I don't particularly want to see is some "half baked" record system,
the usefulness of which has been compromised by the need to retain
backwards compatibility. I quite liked what I saw of the "First Class
Modules" paper. Is there some reason why we can't have (shouldn't have?) that.
(Apart from the additional workload it places on Haskell implementors :-)

Regards
--
Adrian Hey