[Haskell-cafe] Return of the revenge of the revisit of the extensible records, reiterated
vogt.adam at gmail.com
Tue Nov 26 21:00:06 UTC 2013
The following code I come up with using your
variants is unsatisfying for a couple reasons
I explain below:
case inj (Label :: Label "x") 1 of
v | Left one <- decomp (Label :: Label "x") v -> one :: Double
_ -> 5 -- aside: any guarantees about this being unreachable?
First, decomp is like lookup to me, so I expected the Right
constructor for when that lookup succeeds.
Second, (Label :: Label "x") is a pretty unacceptable way to write
what is just x in other languages. One idea would be to
and create values/labels which will do something like:
x .=. 1 -- call to inj perhaps?
v ^? x -- call to decomp
Another idea is to make `x stand for (Label :: Label "x"),
much like 'x and ''x in template haskell. Trying out
a good syntax by using a quasiquoter or preprocessor
before getting something into ghc is probably worth doing.
One example that has not been as useful as originally
thought it would be is:
Third, I think the literal 1 needs a type annotation, but
it should be possible for it to be constrained to Double.
On a somewhat related note, would your strategy of
having sorted labels give better compile times for
for code which uses records that are a bit larger
than a toy example:
On Tue, Nov 26, 2013 at 12:09 PM, Atze van der Ploeg <atzeus at gmail.com> wrote:
> Dear all,
> Extensible records have been a long outstanding feature request for GHC.
> Using the new closed type families and type literals, it is actually
> possible to implement Daan Leijen's "`Extensible Records with Scoped Labels"
> system as a library.
> I have implemented this library at https://github.com/atzeus/openrec (the
> documentation is at http://homepages.cwi.nl/~ploeg/openrecvardocs/). The
> only thing it requires is the availability of a closed type family that
> compares two type level symbols (i.e. the ordering on strings):
> type family (m :: Symbol) <=.? (n :: Symbol) :: Bool
> patches to GHC that implement this built-in closed type family are also at
> the github site.
> I would like to generate some discussion about:
> * Is this the interface we would like for open records and variants?
> * Would it be worthwhile to invest in syntactic sugar for open record
> * Any comments on the interface and or its implementation?
> Atze van der Ploeg
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe