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
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.h...
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....
Yes, that is currently the most painful bit of the syntax. It should be
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 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,
( 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
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
wrote: 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. the performance is (theoretically) the same: linear searching in a list (sorted or unsorted list) is O(n). 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: 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe