extensible records - Vinyl - alternatives?
Dear All, I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case. I've found 2 libraries making this work, so far: HList Vinyl I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl). What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view? regards Peter
Disclaimer: I do contribute to Vinyl, so I'm not objective. Things I like about vinyl: - It is, for the most part, pretty simple. You can reimplement it in very few lines of code, which is good so you don't feel like you're getting locked into someone else's choices. I take advantage of this when exploring design spaces all the time. - It is, for the most part, pretty fast. You might be reluctant to introduce an abstraction in code whose performance you care about. You might think the abstraction is only worth it when complexity reaches a certain level. Vinyl's repo has a benchmark suite of *dead simple* usage that demonstrates minimal loss of performance. I really like this! Otoh, the HList contributors are amazing, so being able to benefit from their expertise is quite appealing. Anthony
On May 3, 2014, at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Peter, Could you show what you mean by "named labels"? Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens'). HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels. There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage>. Also consider lens' makeClassy as another solution to the records problem. Regards, Adam On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Are there any lens implementation of OOHaskell?. That would produce a massive exodus from the OO comunity to haskell. 2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage
. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ 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
-- Alberto.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
hmmm.. I doubt that the solution mentioned in the link can cover all the cases mentioned in the OOHaskell paper. The best OO EDSL must be something like OOHaskell with nice method invocation syntax. 2014-05-04 14:56 GMT+02:00 <mantkiew@gsd.uwaterloo.ca>:
I found this nice stackoverflow answer.
http://stackoverflow.com/questions/20910331/how-do-i-model-inheritance-in-ha...
It seems that the "inheritance " pattern proposed there could be nicely automated, that is have an EDSL allowing me to write
``` Camera inherits Pos, Vel ```
which would get desugared according to the pattern as in the answer.
Has anybody done anything similar?
Michal
*From: *Alberto G. Corona *Sent: *Sunday, May 4, 2014 4:15 AM *To: *adam vogt *Cc: *Peter Althainz; haskell-cafe *Subject: *Re: [Haskell-cafe] extensible records - Vinyl - alternatives?
Are there any lens implementation of OOHaskell?. That would produce a massive exodus from the OO comunity to haskell.
2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries < http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage
. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ 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
-- Alberto.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alberto.
Hi Alberto, The examples in http://code.haskell.org/OOHaskell/ need some work to compile with the current GHC and HList. The examples don't involve nesting of records, so it's not really clear that involving lens would make those examples more compelling. Regards, Adam On Sun, May 4, 2014 at 4:15 AM, Alberto G. Corona <agocorona@gmail.com> wrote:
Are there any lens implementation of OOHaskell?. That would produce a massive exodus from the OO comunity to haskell.
2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries
<http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage>. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ 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
-- Alberto.
Hi adam, This is highly speculative, and I´m not an expert on lens (not even a newbie), but I think that it can be applied to more than plain haskell records. In the other side The OOHaskell solution, that uses HList, is a better Object oriented system than the Object system in many OO languages. But the syntax is ugly. Maybe lens can give the syntactic sugar and some more composability. This is the OOHaskell paper: http://arxiv.org/pdf/cs/0509027v1.pdf More than evolving the actual code, I mean to use the ideas and solve the problems mentioned in this paper. IMHO the Stack overflow solution that you mention above has the problems associated with type classes mentioned in this paper. It add getters and setters to type classes but it does not meet other requrements necessary for being the better OO language possible. The OO people are not impressed when they see their favorite paradigm as a haskell sublanguage, but I´m sure that they would burn their homes and will convert to haskellism if they, in addition to getters and setters, see the right syntax for method invocation and inheritance. 2014-05-05 9:34 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hi Alberto,
The examples in http://code.haskell.org/OOHaskell/ need some work to compile with the current GHC and HList. The examples don't involve nesting of records, so it's not really clear that involving lens would make those examples more compelling.
Regards, Adam
On Sun, May 4, 2014 at 4:15 AM, Alberto G. Corona <agocorona@gmail.com> wrote:
Are there any lens implementation of OOHaskell?. That would produce a massive exodus from the OO comunity to haskell.
2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries
< http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage . Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ 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
-- Alberto.
-- Alberto.
First, sorry for parasitizing this thread with this unrelated subject. Tom, The OOHaskell paper gives encapsulation. mutable state, inheritance, overriding, It uses haskell type safety to the limit, and virtual methods among other things. That is more than what most OO languages can offer (specially type checking) These things are important in the mind of the OO people. Type classes while providing other different and more powerful advantages, do not cover these requirements. They are also very important for translating without pain, many tons of object oriented code to Haskell. 2014-05-05 10:36 GMT+02:00 Tom Ellis < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk>:
On Mon, May 05, 2014 at 10:15:30AM +0200, Alberto G. Corona wrote:
The OOHaskell solution, that uses HList, is a better Object oriented system than the Object system in many OO languages.
That's very interesting. Could you say a bit more about why?
Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alberto.
Hi Adam, thanks for your answer, I will re-check HList with Labelable labels. With regards to your question "named labels": good point, all records indeed have "named labels" so what was my statement? I actually thought that Vinyl does keep run-time information of the labels from a Blog about vinyl-gl, but actually I'm not so sure about it anymore, so it is more a question: do those alternatives of extensible records differentiate by the way they keep runtime information of labels? regards Peter 2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage
. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Peter, If you compare the two, you can see that some parts are nearly the same: ::: ~ Tagged :& ~ HCons RNil ~ HNil The labels aren't there at runtime in either library, since the label that is part of ::: (or Tagged) is missing from the data constructor (ie. it is a phantom type). But you can still define functions that depend on the type of a record: see the Show instances of either record type for example. So in some weak sense you have the same "runtime information of labels" in both libraries. Regards, Adam On Mon, May 5, 2014 at 3:21 AM, Peter Althainz <althainz@gmail.com> wrote:
Hi Adam,
thanks for your answer, I will re-check HList with Labelable labels. With regards to your question "named labels": good point, all records indeed have "named labels" so what was my statement? I actually thought that Vinyl does keep run-time information of the labels from a Blog about vinyl-gl, but actually I'm not so sure about it anymore, so it is more a question: do those alternatives of extensible records differentiate by the way they keep runtime information of labels?
regards Peter
2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries
<http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage>. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On May 5, 2014, at 3:21 AM, Peter Althainz <althainz@gmail.com> wrote:
Hi Adam,
thanks for your answer, I will re-check HList with Labelable labels. With regards to your question "named labels": good point, all records indeed have "named labels" so what was my statement? I actually thought that Vinyl does keep run-time information of the labels from a Blog about vinyl-gl, but actually I'm not so sure about it anymore, so it is more a question: do those alternatives of extensible records differentiate by the way they keep runtime information of labels?
We have runtime information due to singleton types. When using the Symbol kind, you can demote your type-level label to a value-level String. This is not unique to Vinyl. Anthony
regards Peter
2014-05-03 18:54 GMT+02:00 adam vogt <vogt.adam@gmail.com>:
Hello Peter,
Could you show what you mean by "named labels"?
Vinyl is a fine choice, but have you looked at HList >= 0.3? The lenses/labels done with Data.HList.Labelable are prettier than the vinyl alternative in my biased opinion. Furthermore, they support changing types in the record unlike vinyl (ie. they provide a Lens not Lens').
HList is a bit slow at compile time <http://code.haskell.org/~aavogt/HList-benchmark/a.html> if you make records with many fields. That situation may improve soon if we take advantage of the ordering on Symbol that ghc-7.8 introduced. In other words, we will probably follow the lead of <http://www.haskell.org/haskellwiki/CTRex> and make Records sorted by their labels.
There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage>. Also consider lens' makeClassy as another solution to the records problem.
Regards, Adam
On Sat, May 3, 2014 at 6:16 AM, Peter Althainz <althainz@gmail.com> wrote:
Dear All,
I'm searching a handsome library for handling large amounts of configuration data in a flexible manner. So to speak I want to use some kind of inheritance of data fields. I think this is where the extensible records discussion is a proper description of my use case.
I've found 2 libraries making this work, so far:
HList Vinyl
I currently prefer Vinyl due to the complex types in HList, lens compatibiliy, named labels. (I love the HList and OOHaskel papers, but for practical use, I currently prefer Vinyl).
What do you think, what is the best way nowadays to use extensible records? Is Vinyl a good choice from your point of view?
regards Peter
_______________________________________________ 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
participants (7)
-
adam vogt -
Alberto G. Corona -
Anthony Cowley -
mantkiew＠gsd.uwaterloo.ca -
Peter Althainz -
Roman Cheplyaka -
Tom Ellis