Designing the right record system for Haskell has proven to be tricky, the
only general agreement appearing to be that the old Haskell 98 records are not
sufficient. Yet the only record-related proposal ticket for Haskell' at this
stage is ticket:27, "create proposal(s): tweak the existing records system".
Between the extremes of designing and implementing a new record systems on the
one hand and just trying to tweak what we've got, there are opportunities
provided by Haskell's type class and instance language. While not offering a
replacement for a well-integrated proper record system, libraries
implementing record functionality can help to explore the gap between what we
want and what we have in Haskell records. Examples include
Any such libary will need to represent record field labels, and if record
field selection is based on type-level programming, each of these labels needs
to inhabit its own type.
I propose to add implicitly declared record field labels as first class
values to Haskell' (FirstClassLabels), to support experimentation with and
use of such record libraries (such typed constants have other uses in
type-level programming as well).
TODO:
1. need to identify which interfaces labels should support
- like constructors/constants: Read/Show/Matching
- a type-level equality predicate would also be useful, but seems hard to define with current extensions (we want it to be generic, but with functional dependencies)
2. could refine some of the record variants as libraries under Data.Record.VariantX
add impact information below:
> option 1: syntax change (and '#' as an identifier prefix might
> conflict with other uses)
> option 2: non-trivial change of module/type system
> option 3: change of module hierarchy, re-interpretation of
> import behaviour for specific modules
>
> option 3 is the smallest change I could think of (perhaps with
> John's modification to import constructors instead of variables),
> and I've selected minor impact..
