> Most Lisp dialects don't have any sort of destructuring for abstract data
> types, but I question whether destructuring is really all that useful
> anyway. If you have a type with 20 or 30 components -- which is not all
> that unusual, in my experience -- it's much easier to grab the ones you
> want by name than by trying to remember the positions of all n
> components.
>
> Why doesn't Haskell allow you to name components?
No real reason other than not wanting to add complexity. At a Glasgow
workshop two years back the Glasgow Haskellers worked out a couple of
schemes for adding records to Haskell. The implementation seemed
straightforward, if reasonable design decisions were made.
For example, if you disallow identical field names (or require
discriminating type information in this case, as with SML) then the
field names can easily be used to generate position-dependent code.
It is not hard to infer record types in this scheme.
data Day = ...; Month = ...; Year = ...
record Date = << year @ Year, month @ Month, day @ Day >>
pensioner birthday @ << month@August, year >> = year <= 1928
==> data Day = ...
data Date = Date Day Month Year
pensioner (Date _ month@August year) = year <= 1928
pensioner :: Date -> Bool
[I've used alphabetical ordering of field names to get a canonical
component ordering, though an implementation might get away with
just using the ordering in the original definition, or might
optimise the ordering to minimise the deconstruction required.]
This doesn't allow you to write functions which e.g. select the
first component of an arbitrary-sized tuple, but should you be
allowed to do that? Also, should you be able to specify
defaults for field values, so allowing
record Date = << year :: Year = 1993, month :: Month, day :: Day >>
taxdate = << day@17, month@June >>
Should you be able to specify that a record must contain *exactly* the
fields named as in SML, or is it always more useful and flexible to
leave this unspecified.
Syntax seemed to be the other "big" issue. For instance, should I be
able to omit a pattern as with "year" in the first example, should "@"
be overloaded like this, what characters delimit records...
I can't remember the other suggestion, though I do remember that
it involved a dual to case-expressions. Phil Wadler was keen on this.
Kevin
PS Allowing abstract record types as mentioned above would add a
certain amount of complication, but might be worthwhile?
module Accounts ( Employee << age, birthday >> )
record Employee =
<< age@Age, salary@Integer, birthday@Date,
health@HealthRecord >>
...
The main complication is if field positions or types change --
that information has to be communicated to a using module.
