[swift-evolution] [Preemptive Proposal] Operator for Lenses

[Craig Cruden]

If I read this right, things like “withFilter” in Scala could be considered a lens on the original collection.  In that it does not actually perform any function on the collection, but the following function call on the views the data through that lens.

Scala

val a = List(1,2,3,4,5)

>> a: List[Int] = List(1, 2, 3, 4, 5)

val b = a.withFilter(x => x % 2 == 0 )

>> scala.collection.generic.FilterMonadic[Int,List[Int]] = scala.collection.TraversableLike$WithFilter at 77f0d43c

val c = b.map(x => x)

>> c: List[Int] = List(2, 4)

> On 2016-01-15, at 8:11:56, Michael Henson via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It's a way of referring to a specific member of a type with a data structure that, when given an instance of the type, behaves as if it's actually a direct reference to that member on that instance.
> 
> If you have:
> 
> struct Example {
>     let name: String
> }
> 
> If you have a Lens for the 'name' member of the 'Example' type:
> 
> let nameLens = Example#name // assume this generates a Lens, for this example
> 
> then you can hold on to that, pass it around, etc. and apply it to any Example instance you might encounter later on.
> 
> The idea comes primarily from Functional Programming. I'm not familiar enough with FP concepts to go into depth about the ways it's useful in that field, but it has come up in Swift because there isn't currently a way to refer to getters and setters on data properties in the same way that you might be able to directly refer to a member function. The Lens approach seems to be the current front-runner for Swift's answer to that problem.
> 
> Mike
> 
> On Thu, Jan 14, 2016 at 4:44 PM, Andrey Tarantsov <andrey at tarantsov.com <mailto:andrey at tarantsov.com>> wrote:
> Could you please explain what a lens is/means? I only found [1], but quick skimming didn't reveal any lenses.
> 
> [1] https://www.youtube.com/watch?v=estNbh2TF3E <https://www.youtube.com/watch?v=estNbh2TF3E>
> 
> A.
> 
> 
>> On Jan 15, 2016, at 6:10 AM, Michael Henson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> There hasn't been a major Lens thread on the list so far, but I'm intrigued by the idea and was tinkering with a related proposal until I stumbled across Brandon William's "Lenses in Swift" video and discovered that Lenses cover everything I wanted to do and more.
>> 
>> The one thing that stuck with me, though, is the question of syntax. If Lenses are to be a native part of the Swift language, how would one declare them?
>> 
>> We've currently got not-so-secret methods at the type level of Structs and Classes for every member function:
>> 
>> class Example {
>>     func action() {}
>> }
>> 
>> let example = Example()
>> example.action // () -> Void
>> Example.action // (Example) -> Void
>> 
>> That looks a lot like a Lens on the member function, though if I understand correctly the current plan is for those to go away in a future version.
>> 
>> We also have to deal with Type-level members and functions:
>> 
>> class Example {
>>    static action() {}
>>    static name: String
>> }
>> 
>> Example.action() // () -> Void
>> Example.name // String
>> 
>> So, using a dot-operator as the way to get a Lens could be problematic due to name collisions.
>> 
>> The Proposal:
>> 
>> Use the '#' character in place of the dot operator to retrieve a Lens for a Type/member pair:
>> 
>> Example#action() // (Example) -> Void
>> Example#name    // Lens<Example,String>, autogenerated to work on the 'name' member
>> 
>> Member function names should be fully-specified with the mechanism from Doug Gregor's method naming proposal.
>> 
>> Some notes:
>> * A specific operator stands out and is easier to scan for as a code reader.
>> * The octothorpe seems to be available in Swift.
>> * It also has a current meaning in a technology familiar to most everyone - the Document Fragment in HTML - which could make the idea easier to explain to newcomers, by analogy.
>> 
>> What about Lenses on Type-level members? My first thought is that we don't have to support that because they're more like namespaced globals rather than parts of a data type. They can always be referenced directly. That might be a vacuous observation to people more familiar with the Lens concept, but I noted it for completeness.
>> 
>> Mike
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160115/05ebb97c/attachment.html>