[Haskell-cafe] Return of the revenge of the revisit of the extensible records, reiterated

[Atze van der Ploeg]

> very cool work! Thanks for sharing! The ordering on symbols to get rid of
the permutation issue is slick.

Thanks!
>
> you should perhaps also share on the ghc-devs list, or maybe throw your
design ideas on a page on the ghc wiki, to document them?

Good idea! I'll do that friday, i'll keep you posted.

>
>
> On Wed, Nov 27, 2013 at 3:08 AM, Atze van der Ploeg <atzeus at gmail.com>
wrote:
>>
>> Actually, after your email I played around with variants and it turns
out they don't work at all. I'll rework the variants. The records work
beatifully though.
>>
>> > First, decomp is like lookup to me, so I expected the Right
>> > constructor for when that lookup succeeds.
>>
>> Agreed!
>>
>> > Second, (Label :: Label "x") is a pretty unacceptable way to write
>> > what is just x in other languages. One idea would be to
>> > follow <
http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-Labelable.html
>
>> > 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:
>> > <
http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-RecordPuns.html
>
>>
>> Yes, that is currently the most painful bit of the syntax. It should be
possible to adopt HList labelable. I would like a small syntactic extension
that allows 'x for (Label :: Label "x") indeed. I'll probably hack this up
later.
>>
>> > 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:
>> > <http://code.haskell.org/~aavogt/xmonad-hlist/>
>>
>> Depends, as far as I understand HList record sometimes require searching
for a permutation of l such that l~l' which seems expensive to me. This is
not necessary if we keep the row sorted. For projections and decompositions
the performance is (theoretically) the same: linear searching in a list
(sorted or unsorted list)  is O(n).
>>
>> The real benefit of keeping the row sorted is that { x = 0 , y = 0 } and
{ y = 0, x = 0 } have the same type. When a row is not sorted, as in HList,
then if we for example have an instance Eq for a row (because all elements
support Eq) then for using (==) both arguments would have to the same order
in the row or we need a manual call to a permutation function. When keeping
the row ordered, this is not necessary. The same kind of problem occurs
when we fix the type of a function to a specific row:
>> ( using whishful syntax )
>> f :: Rec [ x = Int , y = Int ] -> Int
>>
>> If the row is not ordered, then f { y = 0 , x = 0 } will not typecheck
and will require a manual call to permute the row.
>>
>> Cheers!
>>
>> Atze
>>
>>
>> >
>> >
>> >
>> > Regards,
>> > Adam Vogt
>> >
>> > 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
>> > > operations?
>> > > * Any comments on the interface and or its implementation?
>> > >
>> > > Cheers!
>> > >
>> > > Atze van der Ploeg
>> > >
>> > > _______________________________________________
>> > > Haskell-Cafe mailing list
>> > > Haskell-Cafe at haskell.org
>> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> > >
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131127/318fd5ce/attachment.html>