Opened 13 years ago

Last modified 3 years ago

#92 new enhancement

add First Class Labels

Reported by: claus.reinke@… Owned by: none
Priority: normal Milestone:
Version: Keywords: records "type-class programming"
Cc: Meta Owner:
State: discussion Section: N/A or multiple
Related Tickets:

Description (last modified by ijones)

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
  • 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)
  1. 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..

Attachments (1)

Data.Record.hs (4.6 KB) - added by claus.reinke@… 13 years ago.
Poor man's polymorphic extensible records

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by claus.reinke@…

Attachment: Data.Record.hs added

Poor man's polymorphic extensible records

comment:1 Changed 13 years ago by

Description: modified (diff)

comment:2 Changed 13 years ago by claus

Description: modified (diff)

comment:3 Changed 13 years ago by ijones

Description: modified (diff)
Summary: First Class Labelsadd First Class Labels

comment:4 Changed 13 years ago by ijones

adopt: maybe

comment:5 Changed 13 years ago by

impact: minor

comment:6 Changed 13 years ago by

Description: modified (diff)

comment:7 Changed 13 years ago by ijones

Description: modified (diff)

comment:8 Changed 13 years ago by john@…

topic: Records & Data Types

comment:9 Changed 3 years ago by Herbert Valerio Riedel

Milestone:

moving non-milestoned many year old legacy tickets out of the way

comment:10 Changed 3 years ago by Herbert Valerio Riedel

Priority: majornormal

Set default priority (as this confuses Trac otherwise)

Note: See TracTickets for help on using tickets.