Peter Althainz | 3 May 12:16 2014
Picon

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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Anthony Cowley | 3 May 18:21 2014

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
adam vogt | 3 May 18:54 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Alberto G. Corona | 4 May 10:15 2014
Picon

Re: 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 <at> 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 <at> 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 <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



--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
mantkiew | 4 May 14:56 2014
Picon
Picon

Re: extensible records - Vinyl - alternatives?

‎I found this nice stackoverflow  answer. 

‎http://stackoverflow.com/questions/20910331/how-do-i-model-inheritance-in-haskell

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 <at> 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 <at> 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 <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



--
Alberto.

_______________________________________________
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
Alberto G. Corona | 4 May 22:28 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> gsd.uwaterloo.ca>:
‎I found this nice stackoverflow  answer. 


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 <at> 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 <at> 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 <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



--
Alberto.


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
adam vogt | 5 May 09:34 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> 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 <at> 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 <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
>
>
>
>
> --
> Alberto.
Alberto G. Corona | 5 May 10:15 2014
Picon

Re: extensible records - Vinyl - alternatives?

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:

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 <at> 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 <at> 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 <at> 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 <at> 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 <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
>
>
>
>
> --
> Alberto.



--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Tom Ellis | 5 May 10:36 2014
Picon

Re: extensible records - Vinyl - alternatives?

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
Alberto G. Corona | 5 May 11:10 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



--
Alberto.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Roman Cheplyaka | 5 May 11:06 2014

Re: extensible records - Vinyl - alternatives?

* Alberto G. Corona  <agocorona <at> gmail.com> [2014-05-04 10:15:33+0200]
> Are there any lens implementation of OOHaskell?.  That would produce a
> massive exodus from the OO comunity to haskell.

I bet it would not.

Roman
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Althainz | 5 May 09:21 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> 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 <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
Anthony Cowley | 5 May 16:12 2014

Re: extensible records - Vinyl - alternatives?


On May 5, 2014, at 3:21 AM, Peter Althainz <althainz <at> 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 <at> 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 <at> 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 <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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
adam vogt | 5 May 10:25 2014
Picon

Re: extensible records - Vinyl - alternatives?

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 <at> 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 <at> 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 <at> 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 <at> haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>
>

Gmane