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