template haskell library for OO-like selector syntax?
In my current application, I'm really missing the ability from OO to do things like someData.field1.field2 = "foo" What's do I mean? - field selectors are scoped so that names don't clash with each other or global names - this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level). Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax. Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell? Dennis
You can use `makeFields` from the `lens` package to get something like: someData ^. field1 . field2 along with modifiers: someData & field1 . field2 %~ (* 2) and setters: someData & field1 . field2 .~ 42 where `field1` is polymorphic and can apply to many different data types Matt Parsons On Mon, May 14, 2018 at 6:41 PM, Dennis Raddle <dennis.raddle@gmail.com> wrote:
In my current application, I'm really missing the ability from OO to do things like
someData.field1.field2 = "foo"
What's do I mean?
- field selectors are scoped so that names don't clash with each other or global names
- this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level).
Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax.
Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell?
Dennis
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
In Haskell, if using immutable data, this would requiring doing a data update on every level
I'm not sure what you mean but in either case it doesn't have to do with immutability. Haskell is lazy, so your updates will only happen if the field is later accessed. The other fields in the record will only be updated if they A) change and B) are later accessed. If you just updated one field of a record the other fields will still have pointers to the old data. Otherwise, I agree with Matt's answer. Lenses handle this problem nicely :) On 05/14/2018 07:41 PM, Dennis Raddle wrote:
In my current application, I'm really missing the ability from OO to do things like
someData.field1.field2 = "foo"
What's do I mean?
- field selectors are scoped so that names don't clash with each other or global names
- this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level).
Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax.
Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell?
Dennis
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io <http://iohk.io> Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output <http://iohk.io> Twitter <https://twitter.com/InputOutputHK> Github <https://github.com/input-output-hk> LinkedIn <https://www.linkedin.com/company/input-output-global>
Dennis probably means that when in imperative language you'd write employee.department.manager.salary += 1000 in vanilla Haskell it would be like newSalary = employee.department.manager.salary + 1000 newManager = employee.department.manager {salary = newSalary} newDepartment = employee.department {manager = newManager} newEmployee = employee {department = newDepartment} Lazyness have nothing to do with it. This is actually where lenses usually come in, although I'd argue that the data should rather be restructured.
On 2018. May 15., at 16:01, Vanessa McHale <vanessa.mchale@iohk.io> wrote:
In Haskell, if using immutable data, this would requiring doing a data update on every level
I'm not sure what you mean but in either case it doesn't have to do with immutability. Haskell is lazy, so your updates will only happen if the field is later accessed. The other fields in the record will only be updated if they A) change and B) are later accessed. If you just updated one field of a record the other fields will still have pointers to the old data.
Otherwise, I agree with Matt's answer. Lenses handle this problem nicely :) On 05/14/2018 07:41 PM, Dennis Raddle wrote:
In my current application, I'm really missing the ability from OO to do things like
someData.field1.field2 = "foo"
What's do I mean?
- field selectors are scoped so that names don't clash with each other or global names
- this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level).
Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax.
Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell?
Dennis
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> Only members subscribed via the mailman list are allowed to post.
--
Vanessa McHale Functional Compiler Engineer | Chicago, IL
Website: www.iohk.io <http://iohk.io/> Twitter: @vamchale PGP Key ID: 4209B7B5
<https://twitter.com/InputOutputHK> <https://github.com/input-output-hk> <https://www.linkedin.com/company/input-output-global> _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
On Tue, May 15, 2018 at 7:27 AM, Mig Mit <migmit@gmail.com> wrote:
Dennis probably means that when in imperative language you'd write
employee.department.manager.salary += 1000
in vanilla Haskell it would be like
newSalary = employee.department.manager.salary + 1000 newManager = employee.department.manager {salary = newSalary} newDepartment = employee.department {manager = newManager} newEmployee = employee {department = newDepartment}
Lazyness have nothing to do with it. This is actually where lenses usually come in, although I'd argue that the data should rather be restructured.
That's what I mean. In what sense can I restructure the data? My current application has lots of "composite" data... conceptually, "things" each of which hold a lot of "other things" each of which hold a lot of "still other things". And sometimes I want to update a single one of those "still other things". Lenses seem like a good solution, but if you have a better idea, let me know. D
On 2018. May 15., at 16:01, Vanessa McHale <vanessa.mchale@iohk.io> wrote:
In Haskell, if using immutable data, this would requiring doing a data update on every level
I'm not sure what you mean but in either case it doesn't have to do with immutability. Haskell is lazy, so your updates will only happen if the field is later accessed. The other fields in the record will only be updated if they A) change and B) are later accessed. If you just updated one field of a record the other fields will still have pointers to the old data.
Otherwise, I agree with Matt's answer. Lenses handle this problem nicely :) On 05/14/2018 07:41 PM, Dennis Raddle wrote:
In my current application, I'm really missing the ability from OO to do things like
someData.field1.field2 = "foo"
What's do I mean?
- field selectors are scoped so that names don't clash with each other or global names
- this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level).
Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax.
Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell?
Dennis
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
--
*Vanessa McHale* Functional Compiler Engineer | Chicago, IL
Website: www.iohk.io <http://iohk.io/> Twitter: @vamchale PGP Key ID: 4209B7B5
[image: Input Output] <http://iohk.io/>
[image: Twitter] <https://twitter.com/InputOutputHK> [image: Github] <https://github.com/input-output-hk> [image: LinkedIn] <https://www.linkedin.com/company/input-output-global> _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
And sometimes I want to update a single one of those "still other things".
Lenses seem like a good solution
Lenses are the best solution currently available. If you're worried about this being inefficient due to immutability... don't be. Due to laziness (and more general compiler optimizations), GHC can do this efficiently. On 05/15/2018 04:00 PM, Dennis Raddle wrote:
And sometimes I want to update a single one of those "still other things". **
Continuing my example, you can store manager-to-salary mapping separately, in which case you won't need deep updates. I don't think there is a universal solution, same as there is no universal "best" way to translate an imperative program into a functional language. Az iPademről küldve 2018. máj. 15. dátummal, 23:00 időpontban Dennis Raddle <dennis.raddle@gmail.com> írta:
On Tue, May 15, 2018 at 7:27 AM, Mig Mit <migmit@gmail.com> wrote: Dennis probably means that when in imperative language you'd write
employee.department.manager.salary += 1000
in vanilla Haskell it would be like
newSalary = employee.department.manager.salary + 1000 newManager = employee.department.manager {salary = newSalary} newDepartment = employee.department {manager = newManager} newEmployee = employee {department = newDepartment}
Lazyness have nothing to do with it. This is actually where lenses usually come in, although I'd argue that the data should rather be restructured.
That's what I mean.
In what sense can I restructure the data? My current application has lots of "composite" data... conceptually, "things" each of which hold a lot of "other things" each of which hold a lot of "still other things". And sometimes I want to update a single one of those "still other things".
Lenses seem like a good solution, but if you have a better idea, let me know.
D
On 2018. May 15., at 16:01, Vanessa McHale <vanessa.mchale@iohk.io> wrote:
In Haskell, if using immutable data, this would requiring doing a data update on every level
I'm not sure what you mean but in either case it doesn't have to do with immutability. Haskell is lazy, so your updates will only happen if the field is later accessed. The other fields in the record will only be updated if they A) change and B) are later accessed. If you just updated one field of a record the other fields will still have pointers to the old data.
Otherwise, I agree with Matt's answer. Lenses handle this problem nicely :)
On 05/14/2018 07:41 PM, Dennis Raddle wrote: In my current application, I'm really missing the ability from OO to do things like
someData.field1.field2 = "foo"
What's do I mean?
- field selectors are scoped so that names don't clash with each other or global names
- this way of selecting data can be used both for reading it, and for updating specific fields of some data deep in a data hierarchy (In Haskell, if using immutable data, this would requiring doing a data update on every level).
Any attempt to do this in Haskell, for me anyway, results in an explosion of names and a lot of boilerplate code and a resulting heavy syntax.
Is there a way of obtaining OO-like concise syntax, perhaps with Template Haskell?
Dennis
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
--
Vanessa McHale Functional Compiler Engineer | Chicago, IL
Website: www.iohk.io Twitter: @vamchale PGP Key ID: 4209B7B5
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
participants (5)
-
Dennis Raddle -
Matt -
Mig Mit -
MigMit
-
Vanessa McHale