<p dir="ltr"><br>
> very cool work! Thanks for sharing! The ordering on symbols to get rid of the permutation issue is slick.</p>
<p dir="ltr">Thanks!<br>
><br>
> 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?</p>
<p dir="ltr">Good idea! I'll do that friday, i'll keep you posted.</p>
<p dir="ltr">><br>
><br>
> On Wed, Nov 27, 2013 at 3:08 AM, Atze van der Ploeg <<a href="mailto:atzeus@gmail.com">atzeus@gmail.com</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> > First, decomp is like lookup to me, so I expected the Right<br>
>> > constructor for when that lookup succeeds.<br>
>><br>
>> Agreed!<br>
>><br>
>> > Second, (Label :: Label "x") is a pretty unacceptable way to write<br>
>> > what is just x in other languages. One idea would be to<br>
>> > follow <<a href="http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-Labelable.html">http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-Labelable.html</a>><br>
>> > and create values/labels which will do something like:<br>
>> ><br>
>> > x .=. 1 -- call to inj perhaps?<br>
>> ><br>
>> > v ^? x -- call to decomp<br>
>> ><br>
>> > Another idea is to make `x stand for (Label :: Label "x"),<br>
>> > much like 'x and ''x in template haskell. Trying out<br>
>> > a good syntax by using a quasiquoter or preprocessor<br>
>> > before getting something into ghc is probably worth doing.<br>
>> > One example that has not been as useful as originally<br>
>> > thought it would be is:<br>
>> > <<a href="http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-RecordPuns.html">http://hackage.haskell.org/package/HList-0.3.0.1/docs/Data-HList-RecordPuns.html</a>><br>
>><br>
>> 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.<br>
>><br>
>> > On a somewhat related note, would your strategy of<br>
>> > having sorted labels give better compile times for<br>
>> > for code which uses records that are a bit larger<br>
>> > than a toy example:<br>
>> > <<a href="http://code.haskell.org/~aavogt/xmonad-hlist/">http://code.haskell.org/~aavogt/xmonad-hlist/</a>><br>
>><br>
>> 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).<br>
>><br>
>> 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:<br>
>> ( using whishful syntax )<br>
>> f :: Rec [ x = Int , y = Int ] -> Int<br>
>><br>
>> 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.<br>
>><br>
>> Cheers!<br>
>><br>
>> Atze<br>
>><br>
>><br>
>> ><br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Adam Vogt<br>
>> ><br>
>> > On Tue, Nov 26, 2013 at 12:09 PM, Atze van der Ploeg <<a href="mailto:atzeus@gmail.com">atzeus@gmail.com</a>> wrote:<br>
>> > > Dear all,<br>
>> > ><br>
>> > > Extensible records have been a long outstanding feature request for GHC.<br>
>> > > Using the new closed type families and type literals, it is actually<br>
>> > > possible to implement Daan Leijen's "`Extensible Records with Scoped Labels"<br>
>> > > system as a library.<br>
>> > ><br>
>> > > I have implemented this library at <a href="https://github.com/atzeus/openrec">https://github.com/atzeus/openrec</a> (the<br>
>> > > documentation is at <a href="http://homepages.cwi.nl/~ploeg/openrecvardocs/">http://homepages.cwi.nl/~ploeg/openrecvardocs/</a>). The<br>
>> > > only thing it requires is the availability of a closed type family that<br>
>> > > compares two type level symbols (i.e. the ordering on strings):<br>
>> > > type family (m :: Symbol) <=.? (n :: Symbol) :: Bool<br>
>> > > patches to GHC that implement this built-in closed type family are also at<br>
>> > > the github site.<br>
>> > ><br>
>> > > I would like to generate some discussion about:<br>
>> > > * Is this the interface we would like for open records and variants?<br>
>> > > * Would it be worthwhile to invest in syntactic sugar for open record<br>
>> > > operations?<br>
>> > > * Any comments on the interface and or its implementation?<br>
>> > ><br>
>> > > Cheers!<br>
>> > ><br>
>> > > Atze van der Ploeg<br>
>> > ><br>
>> > > _______________________________________________<br>
>> > > Haskell-Cafe mailing list<br>
>> > > <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> > > <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>> > ><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
</p>