Keep the present Haskell record system!
Henrik Nilsson
nhn at Cs.Nott.AC.UK
Wed Mar 1 03:26:14 EST 2006
Dear all,
I'm increasingly convinced that the records should be left alone for
Haskell', possibly modulo some minor tweaks to polish the system.
While there are a number of reasonable proposals out there for a
replacement record system, and while I do agree that a more
flexible system would be desirable, there just is no consensus
whatsoever as to which one is the way forward.
Moreover, my impression is that maintaining backwards compatibility
while truly addressing the shortcomings of the present system,
almost inevitably would lead to a language with TWO kinds of
records.
I must say I really don't like that prospect.
If the above is true, then that would imply that backwards
compatibility would have to be sacrificed in a serious way
if we were to move forward with a proposal for a new record
system.
I don't think there is a case for this in the context of Haskell'.
A while ago, I suggested some rules-of-thumb for when serious
backwards-compatibility breaking changes might be considered
for Haskell'. To recap:
If a proposed change breaks backwards compatibility, then it is
acceptable only if either
1. very little existing code is likely going to be broken in
practice, or
2.1. it is widely agreed that not addressing the issue really
would harm the long-term relevance of Haskell', and
2. it is widely agreed that attempting to maintain backwards
compatibility would lead to an unwieldy language design, and
3. the proposed design and its implications are well understood,
i.e. it has been implemented in at least one system and it has
been used extensively, or a strong argument can be made on
the grounds of, say, an underlying well-understood theory.
From the people who commented on that, there seemed to be some support
for this position, and no one, as far as I know, said they thought
that the above was too restrictive.
My position is that two parallel record systems is so unwieldy
so as to not be acceptable.
That would imply that fixing the records would break lots of code.
That means rule 1 above does not apply.
One can probably find some proposals out there that meet criteria 2.3.
However, I don't think 2.1 can be argued convincingly.
Yes, some people claim that no proper records is the key thing that
gets in the way of serious software development in Haskell.
I don't believe that as I see lots of serious Haskell software out there
that seems to have been developed just fine with the existing records
(or not using records at all, or using some kind of "home brewed"
records.)
(In contrast, it seems to me that lots of serious Haskell software out
there do use MPTCs, FDs, and rank-2 or higher types.)
Moreover, I think the current record system is being unfairly
discredited.
Yes, it is certainly not perfect. But by adopting some simple
conventions for naming fields to avoid name clashes, it is really
not that hard to use them in the way records are used in a language
like, say, C. (No, I'm not arguing that C's record system is great,
just that that basic kind of records evidentially is enough for
supporting some really serious software development efforts.)
Moreover, there is scope for improving the present
system a little bit without any major changes.
Anyway, the present records certainly beats having no records at
all hands down, and they are moreover very lightweight and fits
very nicely into Haskell.
For this, they deserve credit.
My proposal is thus that we move forward on records for Haskell' by
deciding to essentially keep the current record system.
All the best,
/Henrik
--
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.
More information about the Haskell-prime
mailing list