No subject

expecting the approach
will include a Has class with methods get and set. It would
be sweet if in
future the same Has class could be extended to extended(!)
records, anonymous
records, renamed labels, projections on records, merged
records (as you'd get
from a relational join), etc. Specifically:
Has r l t => ... really must mean
there's exactly one field labelled l in record r,
at type t
(which is a constraint on whatever merged/extended
term r is)
compare TRex's
(r\l) => ... Rec {| l : t | r |} ... which really
means
there's exactly one field labelled l in the Rec, at
type t
In hindsight, I think it was unfortunate that the original
TRex paper [1] used
the word "lacks" in context of its notation for constraining
the record
structure. (I'm looking especially at section 2.1 'Basic
Operations'.) In all
the operations, the types always include a Rec term with
_both_ l and r. They
don't all have a term of a 'bare':
Rec {| r |}
TRex is trying to avoid a positional specification of the
record fields (which
is 'implementation determined'/hidden from the programmer).
But I think of 'bare' r as representing a record with a
'hole' at
whatever position l is in the full record. (So the
constraint (r\l) means: you're
going to find a Rec with exactly one l in it; if you also
find a Rec with 'bare'
r, that means the same Rec, but with a 'hole'.)
The HList guys picked up the word "lacks", and adapted it
(successfully in
context of what they were doing) to build 'Type Indexed
Hlist's -- that is,
record-like structures with exactly one field labelled l.
Perhaps TRex should have used a notation something like:
(rr :> l @ t) => Rec {| rr |} ... -- HasUnique
rr l t
... Rec {| rr \ l |} ... -- rr with a
hole in place of l
You say:
> As one anecdote, I've been very pleased using Daan
Leijen's scoped labels
approach
My anecdote: the new approaches and extensions to type
inference in GHCi have
been frustratingly slow in arriving and maturing. But we now
have working
superclass constraints, including type equality (~), and
some heavy-weight
type inference. I've built a toy (and somewhat limited)
polymorphic record
system (with Has/get/set), which:
treats Data types as records; and
treats tuples as anonymous (type-indexed) records; and
implements project, extend and merge.
It relies on overlapping instances (so I don't mention it in
polite company --
at least it doesn't use FunDeps to boot!). I achieve the
effect of 'HasUnique'
through instance resolution: if there's more than one
occurence of label l in
the record term, GHC bitches. (This is fragile: I can't use
IncoherentInstances, and sometimes UndecidableInstances
gives trouble.)
[1] A Polymorphic Type System for Extensible Records and
Variants, Gaster/Mark
P. Jones, 1996.