Option versus Maybe

[davidchambers]

I'm excited by the discussion in ramda/ramda-fantasy#139.

One potential problem has become apparent to me: there are two common names for this data type. Haskell uses "Maybe"; Scala uses "Option". Neither is better or worse than the other, but there are contexts in which one is more appropriate than the other. Sanctuary, for example, is strongly inspired by Haskell and PureScript so uses "Maybe", whereas Folktale draws inspiration from Scalaz and Cats (I believe), so uses "Option".

Since the goal is for this project is to be the canonical implementation of the Maybe/Option type, it would be nice if we could somehow please everyone. While someone could easily include…

const Nothing = None;
const Just = Some;

in her own code to use the "Haskell" data constructors, the string representation of Just(42) would still be 'Some(42)'.

I'm thinking through the ramifications of merging Sanctuary's Maybe type into this repository. Since Sanctuary is inspired by Haskell and PureScript I certainly want to keep using "Maybe" in that project, and I certainly don't want to monkey patch Option#toString.

Perhaps this project should export both Maybe and Option:

exports.Maybe = create('Nothing', 'Just');
exports.Option = create('None', 'Some');

const {Nothing, Just} = require('fantasy-options').Maybe;

const {None, Some} = require('fantasy-options').Option;

Maybe and Option would really be two names for the same type. Just(42) and Some(42) would be interchangeable, though they would have different string representations.

I realize the thoughts I'm sharing are not fully formed. My goal is to start a discussion rather than to propose a specific solution.

[safareli]

I think it would be better to chose one name instead of createing multiple, but same types. Also we can clone this repo into fantasy-maybe and work on that.

[safareli]

@fantasyland/core what do others think?

[SimonRichardson]

I don't care about the name, change it!

[TrevorBasinger]

We do have to consider that others have already written code with the current naming structure.

Names don't really matter to me. But I would hate for code to unexpectedly break. Perhaps a "deprecation" warning for a given period of time?

[SimonRichardson]

Versioning should solve this for us? Older versions should be on npm (etc) or you can still reference a commit, or just deprecate the repo and start another. As long as we don't have too:

1. Maintain code for the sake of it.
2. Have code that looks overly complicated because we're trying to do too much for too few!

[hojberg]

Whats the best way to move "Maybe" forward? I'd love to help.

[SimonRichardson]

Make a PR, should be quite simple tbh

[hojberg]

@SimonRichardson oh ok.
I was under the impression you'd make a new repo?

regardless i'm happy to open a PR :)

[hojberg]

Added PR: #9

[roobie]

Would it not be prudent to create a new repo with a more fitting name (i.e. fantasy-maybe)?

Alternatively, this repo could be renamed, but that would mean that contributors would have to update their local repos.

[joneshf]

Sorry to seem dense, but I've no clue what's being proposed here. Is there a less than three sentence summary?

[roobie]

@joneshf
If I understand correctly:

• Sanctuary does not necessarily want to implement its own Maybe/Option, but perhaps use this library instead,
• Sanctuary does not want use this monad by the name Option,
• This library should not export the same monad by two distinct names,

hence the rename of Option to Maybe

[joneshf]

Excellent! Thanks so much.

[davidchambers]

Alternatively, this repo could be renamed, but that would mean that contributors would have to update their local repos.

I think GitHub automatically redirects requests so this wouldn't be necessary. :)

[hojberg]

@SimonRichardson any update on creating a new repository (or renaming)? We could get a baseline going by simply using the renamed code from #9?

[SimonRichardson]

We should just rename this repo, i'll do it now.

[SimonRichardson]

It's done!

[roobie]

I propose that #9 gets merged, that the major version is incremented and a new release is created/published. After this is done, the discussion about replacing the implementation with the one from sanctuary can continue but consumers of this library have the opportunity to use the library as Maybe.

[joshburgess]

Any updates on this? It's been over a year. I agree with @roobie ... It would be cool to see #9 merged and then see whether or not @davidchambers 's Maybe implementation in Sanctuary would fit here.

[davidchambers]

sanctuary-maybe has been released. 🎉