New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Either #67

Closed
wants to merge 6 commits into
base: master
from

Conversation

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 Dec 17, 2015

Closed

Either #2

@DavdRoman

This comment has been minimized.

Show comment
Hide comment
@DavdRoman

DavdRoman Dec 18, 2015

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

DavdRoman commented Dec 18, 2015

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

Show outdated Hide outdated proposals/0015-either.md
`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`.

This comment has been minimized.

@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.)

@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.)

This comment has been minimized.

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

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

This comment has been minimized.

@CodaFi

CodaFi Jan 21, 2016

Collaborator

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

@CodaFi

CodaFi Jan 21, 2016

Collaborator

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

@CodaFi

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Dec 18, 2015

Collaborator

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

Collaborator

CodaFi commented Dec 18, 2015

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

@bitemyapp

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Dec 18, 2015

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.

bitemyapp commented Dec 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Dec 18, 2015

Collaborator

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

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

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Dec 19, 2015

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

bitemyapp commented Dec 19, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Dec 19, 2015

Collaborator

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

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

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Jan 8, 2016

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 8, 2016

Collaborator

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

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

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Jan 9, 2016

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 9, 2016

Collaborator

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

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

This comment has been minimized.

Show comment
Hide comment
@lattner

lattner Jan 9, 2016

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 9, 2016

Collaborator

Absolutely! Thank you.

Collaborator

CodaFi commented Jan 9, 2016

Absolutely! Thank you.

@paulyoung

This comment has been minimized.

Show comment
Hide comment
@paulyoung

paulyoung Jan 19, 2016

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

paulyoung commented Jan 19, 2016

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

@bitemyapp

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Jan 21, 2016

cause considerable confusion to novices

Not in my experience.

cause considerable confusion to novices

Not in my experience.

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 22, 2016

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.

Member

CodaFi replied Jan 22, 2016

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.

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Jan 22, 2016

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.

bitemyapp replied Jan 22, 2016

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.

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 22, 2016

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.

Member

CodaFi replied Jan 22, 2016

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.

This comment has been minimized.

Show comment
Hide comment
@bitemyapp

bitemyapp Jan 22, 2016

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.

bitemyapp replied Jan 22, 2016

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.

This comment has been minimized.

Show comment
Hide comment
@CodaFi

CodaFi Jan 22, 2016

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.

Member

CodaFi replied Jan 22, 2016

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

Remove straw men
h/t @bitemyapp for pointing out my unfortunate choice of a strawman to
motivate the renaming section.
@DougGregor

This comment has been minimized.

Show comment
Hide comment
@DougGregor

DougGregor Feb 3, 2016

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.

Member

DougGregor commented Feb 3, 2016

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