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 :

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.

...

. Also consider lens' makeClassy as another solution to the records

There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage problem.

Regards, Adam

On Sat, May 3, 2014 at 6:16 AM, Peter Althainz 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.

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 :

‎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 :

...

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.

...

. Also consider lens' makeClassy as another solution to the records

There are quite a few other libraries < http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage problem.

Regards, Adam

On Sat, May 3, 2014 at 6:16 AM, Peter Althainz 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 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 :

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

...

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

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.

...

. Also consider lens' makeClassy as another solution to the records

There are quite a few other libraries <http://www.haskell.org/haskellwiki/Extensible_record#Libraries_on_hackage problem.

Regards, Adam

On Sat, May 3, 2014 at 6:16 AM, Peter Althainz 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 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 :

...

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