Records (was Re: [Haskell] Improvements to GHC)

[John Lask]

correct me if I am wrong but ...

1. Field namespaces: solved by using type classes

    This would imply that the type of the field is the same between all 
instances of this common field.

    Under this proposal two fields with same label and different type would 
not be possible
    eg { name :: String }, { name :: Int }


John

----- Original Message ----- 
From: "Rob Ennals" <rob.ennals at gmail.com>
To: "Johannes Waldmann" <waldmann at imn.htwk-leipzig.de>
Cc: <haskell at haskell.org>
Sent: Wednesday, November 23, 2005 1:32 AM
Subject: Re: Records (was Re: [Haskell] Improvements to GHC)


Hi guys,

Since discussion has returned to records, it might be useful for me to
post a link to a proposal that I knocked up a while back when this
topic came up a few years ago:

http://www.cambridge.intel-research.net/~rennals/records.pdf

The basic idea is to keep records largely as they are, but add two 
extensions:

- field getter functions are placed in type classes

- fields desugar to setter functions as well as getters

Useful features of this approach are:
- backward compatibility with existing code
- the existing type-class mechanism is used for shared field names
- setters can be redefined if a type is changed, just as getters can now


To go through Dave's issues:

1. Field namespaces: solved by using type classes
2. Multi-constructor getters: solved by desugaring to functions
3. "Safe" getters for multi-constructor data types: ditto
4. Getters for multiple data types with a common field: solved by
type-classes (no special "constains" feature required)
5. Setters as functions: yep
6. Anonymous records: not supported
7. Unordered records: yep (if I understand the problem correctly)

And Georg's points:
8. Subtyping: yep -using type classes
9. higher order versions for selecting, updateing ... : not sure what
is meant here


Of course, my proposal might very well not do what you want, but I
thought it was worth posting it again.

Hope people find this useful.


-Rob


On 11/22/05, Johannes Waldmann <waldmann at imn.htwk-leipzig.de> wrote:
> On records in Haskell - can we start by formulating requirements
> (design goals). What do we want from a record system,
> and what are non-goals.
>
> Some of the proposals here sound like records should be more like
> objects (with some kind of inheritance). Do we really want this?
> We already have inheritance (for interfaces). Isn't that enough?
>
> My main objection is that concrete data types (e. g. records)
> should not be exposed by a module anyway,
> and should definitely not be a base for derivations
> (Compare the OO design pattern literature).
>
> Still if they are exposed (or while we're inside a module),
> what makes the current records quite impractical
> is the namespace issue (for component names).
>
> Sure, one thing would be to invent some ad-hoc solution
> (automatic qualification by type name or something)
> but another possibility is to allow ad-hoc polymorphisms
> generally in the language.
>
> Just my 2 cent (and none of them new, I'm afraid)
> --
> -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
> ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
_______________________________________________
Haskell mailing list
Haskell at haskell.org
http://www.haskell.org/mailman/listinfo/haskell