Do you miss null references from your old imperative programming days? Wish that the worlds best imperative language had null references? Now your wishes have come true with the new partial-lens package! partial-lens augment edwardk's data-lens package with partial lens. Partial lenses are like regular lenses but have the possibility of not referencing anything. In other words, null references are possible. One notable different with null references from this package is that you can set them without getting a run-time error. Instead setting a null reference is a no-op; however it is possible to determine if setting failed from the return value of the assignment operation. Actually I don't have any applications for partial lenses myself, so if you find this library useful, please let me know. I wrote this mostly because we know what partial lenses are in theory (they are the coalgebras of the (Identity :+: Store b) comonad) but I wanted to see what a real library would look like. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
How does this relate to the Maybe lenses in fclabels [1]?
Erik
[1] http://hackage.haskell.org/packages/archive/fclabels/1.0.4/doc/html/Data-Lab...
On Wed, Dec 21, 2011 at 04:54,
Do you miss null references from your old imperative programming days? Wish that the worlds best imperative language had null references? Now your wishes have come true with the new partial-lens package!
partial-lens augment edwardk's data-lens package with partial lens. Partial lenses are like regular lenses but have the possibility of not referencing anything. In other words, null references are possible. One notable different with null references from this package is that you can set them without getting a run-time error. Instead setting a null reference is a no-op; however it is possible to determine if setting failed from the return value of the assignment operation.
Actually I don't have any applications for partial lenses myself, so if you find this library useful, please let me know. I wrote this mostly because we know what partial lenses are in theory (they are the coalgebras of the (Identity :+: Store b) comonad) but I wanted to see what a real library would look like.
-- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Wed, 21 Dec 2011, Erik Hesselink wrote:
How does this relate to the Maybe lenses in fclabels [1]?
Erik
[1] http://hackage.haskell.org/packages/archive/fclabels/1.0.4/doc/html/Data-Lab...
It appears to be somewhere between similar and the same. *** Comparison of API Data.Label.Maybe.get corresponds to Data.Lens.Partial.getPL Data.Label.Maybe.set roughly corresponds to Data.Lens.Partial.trySetPL except that trySetPL will bail out early if the reference is null. We can match the signature of set more precisely by: Data.Label.Maybe.set l v r ~ Data.Lens.Partial.trySetPL l r <*> pure v Data.Label.Maybe.modify would correspond to Data.Lens.Partial.tryModPL if I had implemented it ... which maybe I ought to. Data.Label.Maybe.embed corresponds to a composition of totalLens and maybeLens. More specifically Data.Label.Maybe.embed l ~ Data.Lens.Partial.maybeLens . Data.Lens.Partial.totalLens l Data.Label.MaybeM.gets roughly corresponds to Data.Lens.Partial.Lazy.accessPlus except that accessPlus is particular to StateT because partial-lens is a Haskell 98 compliant package. I need to write partial-lens-fd which will contain a function precisely corresponding to Data.Label.MaybeM.gets I don't have Data.Label.MaybeM.asks, because there was no corresponding functionality in data-lens. We should probably add a version of this. *** Comparison of representation The usual differences between data-lens and fclabels applies to partial-lens as well. The representation for data-lens and partial-lens allows modify to be done with one case analysis on a record since the getter and setters are combined into one coalgebra whereas in fclabels two case analysis must be done: one for the getter and one for the setter. When chains of lenses are composed, I'm told the differences become more apparent. In partial-lens, the combination of getter and setter into a single coalgebraic operations means that the getter and setter are statically forced to return Nothing on the same record; but this is not enforced with the fclabels representation. That said, perhaps the MaybeLens from fclabels is trying to do something different. I don't know what laws you expect to hold for the getter and setters of a maybe lens since it isn't documented (actually I appear to have also forgotten to document the coalgebra laws for a comonad in my package) so perhaps MaybeLens are intended to be more general than partial lenses. For example maybe a user wants to make it illegal to set the birth date to be greater than the death date in a record. In this case getting the birth date will succeed, but setting will fail if the provided birth date out of bounds. This is possible to write using MaybeLens, but is impossible with partial lenses since with partial-lenses either the reference is null, meaning getting and setting both fail, or it is not null which means that getting and setting both succeed. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On Wed, Dec 21, 2011 at 16:39,
On Wed, 21 Dec 2011, Erik Hesselink wrote:
How does this relate to the Maybe lenses in fclabels [1]?
Erik
[1] http://hackage.haskell.org/packages/archive/fclabels/1.0.4/doc/html/Data-Lab...
It appears to be somewhere between similar and the same.
*** Comparison of API
Data.Label.Maybe.get corresponds to Data.Lens.Partial.getPL
Data.Label.Maybe.set roughly corresponds to Data.Lens.Partial.trySetPL except that trySetPL will bail out early if the reference is null. We can match the signature of set more precisely by:
Data.Label.Maybe.set l v r ~ Data.Lens.Partial.trySetPL l r <*> pure v
Data.Label.Maybe.modify would correspond to Data.Lens.Partial.tryModPL if I had implemented it ... which maybe I ought to.
Data.Label.Maybe.embed corresponds to a composition of totalLens and maybeLens. More specifically
Data.Label.Maybe.embed l ~ Data.Lens.Partial.maybeLens . Data.Lens.Partial.totalLens l
Data.Label.MaybeM.gets roughly corresponds to Data.Lens.Partial.Lazy.accessPlus except that accessPlus is particular to StateT because partial-lens is a Haskell 98 compliant package. I need to write partial-lens-fd which will contain a function precisely corresponding to Data.Label.MaybeM.gets
I don't have Data.Label.MaybeM.asks, because there was no corresponding functionality in data-lens. We should probably add a version of this.
*** Comparison of representation
The usual differences between data-lens and fclabels applies to partial-lens as well. The representation for data-lens and partial-lens allows modify to be done with one case analysis on a record since the getter and setters are combined into one coalgebra whereas in fclabels two case analysis must be done: one for the getter and one for the setter. When chains of lenses are composed, I'm told the differences become more apparent.
In partial-lens, the combination of getter and setter into a single coalgebraic operations means that the getter and setter are statically forced to return Nothing on the same record; but this is not enforced with the fclabels representation.
That said, perhaps the MaybeLens from fclabels is trying to do something different. I don't know what laws you expect to hold for the getter and setters of a maybe lens since it isn't documented (actually I appear to have also forgotten to document the coalgebra laws for a comonad in my package) so perhaps MaybeLens are intended to be more general than partial lenses.
For example maybe a user wants to make it illegal to set the birth date to be greater than the death date in a record. In this case getting the birth date will succeed, but setting will fail if the provided birth date out of bounds. This is possible to write using MaybeLens, but is impossible with partial lenses since with partial-lenses either the reference is null, meaning getting and setting both fail, or it is not null which means that getting and setting both succeed.
Thanks for the detailed explanation! It seems they are indeed (almost) the same, apart from the differences in representation. The original motivation for the Maybe lenses in fclabels was accessing record fields with Maybe types and composing these lenses (even in the presence of multiple Maybes). It does not come from a category theoretical starting point, hence no laws (yet). Your final example is interesting, I'd never considered doing something like that. Erik
participants (2)
-
Erik Hesselink -
roconnor＠theorem.ca