Either #67

Closed
wants to merge 6 commits into
from

Projects

None yet

8 participants

@CodaFi
Collaborator
CodaFi commented Dec 17, 2015

This proposal implements a left-biased sum type for the Swift Standard Library.

Previous mailing list discussions can be found hereabouts.

@CodaFi CodaFi referenced this pull request in typelift/swift Dec 17, 2015
Closed

Either #2

@DavdRoman

@CodaFi I believe there's an error in the "Alternatives considered" section. Result: Error, Value should actually be suggested as Result: Value, Error so that it's left-biased.

@robrix robrix and 2 others commented on an outdated diff Dec 18, 2015
proposals/0015-either.md
+```
+
+## Impact on existing code
+
+As this is an addition to the Standard Library, no existing code should be affected
+unless the author happens to be using the identifier Either - in which case
+there is a strong chance that their Either and our Either are the same
+thing, aligning with the goal of removing duplicate implementations of
+this common type.
+
+The fears of the previous proposal that attempted to put a `Result<T>`
+type in the Standard Library, of duplicating existing functionality with respect to
+`throws` remain, but as noted before `throws` is not as
+flexible or declarative enough for all possible cases. If necessary,
+a note can be left in the documentation warning away users of the
+`Either` type that really need `throws`.
@robrix
robrix Dec 18, 2015

Speaking as the principal author of both a reasonably well-known Either and the de facto standard community implementation of Result, I would welcome nearly anything which hastens their demise.

That said, it’s notable that the latter has gained much more popular traction than the former (despite the latter’s youth), harmonizing with your comment later on that most uses of Either are really Result.

Therefore, I wonder if this proposal would be strengthened by the inclusion of examples of problems for which Either is well-suited, but where the norm is currently e.g. to return (A?, B?), or to abuse throws for control flow, or similar.

For example, early returns from reduce or other higher-functions are quite natural to model with Either<A, A>, where the Left case causes the immediate cessation of the operation & returns the enclosed value, while the Right case continues as normal. (Shades of Continuation and Free, but we won’t go there.)

@pthariensflame
pthariensflame Dec 18, 2015

Further improvement of https://github.com/TypeLift/Focus is effectively blocked on the availability of a universal Either, since it's crucial to more powerful prisms, as well as even the mere existence of traversals and partial lenses.

@CodaFi
CodaFi Jan 21, 2016 Collaborator

@robrix I think you will appreciate the new Motivating Examples section.

@CodaFi
Collaborator
CodaFi commented Dec 18, 2015

@DavidRoman So there is! Thank you for catching that, it should be fixed real soon.

@bitemyapp

What's the thinking behind a left-bias rather than a right-bias? The latter falls out naturally from type constructor currying in Haskell. Apologies if I'm asking a question which has an answer obvious to people more familiar with Swift's type system.

@CodaFi
Collaborator
CodaFi commented Dec 18, 2015

@bitemyapp I was swayed to change the type because of the argument @pthariensflame made while drafting and Rust's successful implementation which seems closer to Swift's philosophy on data types than Haskell. There is no precedent for bias in the standard library.

@bitemyapp

@CodaFi I didn't see a principled reason in the Rust documentation, but it's strictly less useful to have an unbiased Either type. Should take care to avoid making the mistake of naming the constructors "Result" and "Error" or something as well. The usefulness is the functorial bias. I've had situations where Left was my success case and Right was my failure mode because I wanted to keep "trying" an action that would fail repeatedly until it succeeded. The bias acted as a short-circuit and Left was my success. This, among other reasons, is why Haskell's Either just has "Left" and "Right" for the data constructors though I suspect that wasn't necessarily the original reason.

I've written about this some here: http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html

If your type constructors aren't ordered or curried, I don't know of an argument against left-bias, but please do avoid choosing to call the target the Functor is biased toward "Success". It'll give people the wrong understanding of what it is, means, and does even if that's the common case.

@CodaFi
Collaborator
CodaFi commented Dec 19, 2015

@bitemyapp Absolutely. Your blog was actually one of the things that informed my initial implementation of this proposal. My hope is that we can merge the Either I have drawn up as-is, but I recognize that there are people with a bitter taste in their mouth from learning and using Haskell's Either that will try to use that to argue either against the bias or for a Result<T>-esque implementation.

@lattner
Contributor
lattner commented Jan 8, 2016

This was very controversial and should be discussed more on the lists.

@lattner lattner closed this Jan 8, 2016
@CodaFi
Collaborator
CodaFi commented Jan 8, 2016

@lattner I recognize the proposal is controversial, so is there anything in particular you feel still needs to be teased out by the community? Discussion of the proposal itself seemed to fizzle out after the first week.

@lattner
Contributor
lattner commented Jan 9, 2016

Strong sentiment that we should do this. Per the last discussion, there was a (from my perspective) overwhelmingly negative reaction to it, and the core team is generally against adding features to the standard library unless it is very very strongly motivated.

@CodaFi
Collaborator
CodaFi commented Jan 9, 2016

@lattner I didn't get that feeling. I think the negative reaction came because discussion evolved into making this into a full-fledged feature of the type system. That, I definitely do not want.

@lattner
Contributor
lattner commented Jan 9, 2016

Ok, perhaps I misinterpreted the sentiment. How about you start a new thread with a link to your specific proposal for early feedback?

@lattner lattner reopened this Jan 9, 2016
@CodaFi
Collaborator
CodaFi commented Jan 9, 2016

Absolutely! Thank you.

@paulyoung

I'd very much like to see Either and Result types as part of the standard library.

@bitemyapp

cause considerable confusion to novices

Not in my experience.

Member

In a language that uses a type called Either for "this function possibly returns errors", you have to admit the principle of least surprise has been violated a bit. For those with little understanding of the computational interpretation of monads, the choice (no pun intended) seems arbitrary when it really is quite far from that.

In a language that uses a type called Either for "this function possibly returns errors",

It's not a property of the language and I provided an example in the thread that gives lie to the over-simplified framing of "Right is Result, Left is Error". I've had situations where I wanted the "success" case to short-circuit the lifting of over functions over Either, that meant my result/success case was Left. This is not hypothetical, I use Haskell for 100% of my day job work! I also teach and write about Haskell.

If you don't tell people confusing things, they won't be confused. Either is an anonymous sum type.

If I told you (a, b) was about first and last names, you'd tell me I was being silly, because you know it's the anonymous product or 2-tuple. This is an extreme example, but this is the mistake being committed here.

This does not have to be a confusing matter if things are not confused from the outset.

Let me demonstrate another datatype to reinforce my point, these. Who's the error in These? Just because the b value in That is the target of the Functor instance doesn't say anything about the semantics. Datatypes are structure, not semantics. Leave the semantics to specific libraries and applications.

Member

Precisely. I think we may be talking past each other here. I included that as a conceit that many on the mailing list had raised the general idea of "wait, what are Left and Right for". The last time this feature was discussed, the majority of the conversation centered around error handling and turning this proposal into an implementation of typed throws, and I need to discourage this proposal being viewed exclusively for that use case. You're exactly right

Leave the semantics to specific libraries and applications.

But we cannot ignore the opportunity we have to give this thing a more semantically meaningful name - one that discourages the "considerably confusing" case.

But we cannot ignore the opportunity we have to give this thing a more semantically meaningful name

You will confuse the matter if you bolt (frequently false!) semantics onto the inhabitants. I understand you and what you're saying, I just don't think you understand what a grave mistake it is to bolt limited, arbitrary semantics onto something so general is. It makes it harder to understand and it limits peoples' initial inclination to understand things in general.

We call them verbs, not words-for-going-places. We call them nouns, not Bob-words. We call them adverbs, not mightily-words. Stop projecting an unnecessary synecdoche onto the structure and you can avoid a mistake that'll stick with you for a long time. If programmers cannot understand why you'd want, or what it means, to have a generic sum type --- that's an education problem; not something to be catered to!

one that discourages the "considerably confusing" case.

There is nothing considerably confusing about Either. We've processed over 500 Zendesk tickets for haskellbook.com, I've taught and helped hundreds of people via IRC, Skype, and in person. Never once was Either being a sum type with two constructors a sticking point in its own right.

Member

Then I'll defer to your expertise and concede I've been trumpeting a straw man. It will be amended in my next commit.

CodaFi added some commits Jan 22, 2016
@CodaFi CodaFi Remove straw men
h/t @bitemyapp for pointing out my unfortunate choice of a strawman to
motivate the renaming section.
ea9d713
@CodaFi CodaFi Minor revisions to goals bd89719
@CodaFi CodaFi cleanup 1e9492a
@DougGregor
Member

The consensus on the list is skewing too negative to bring this specific proposal further in the process. Closing but feel free to continue the discussion on the swift-evolution list.

@DougGregor DougGregor closed this Feb 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment