backwards compatibility

[davidchambers]

@JAForbes has expressed a desire to maintain compatibility with union-type. I have expressed a desire to simplify the API to bring it into line with other Sanctuary projects. Both options have merit.

What we could do is have two branches: compatibility and master. The former would respect the union-type API; the latter would not. I could revert the experimental changes I made to #3, and once that pull request is merged we could publish v0.1.0. We'd then create the compatibility branch from the master branch. I would then open a pull request against master. After merging it we would publish v1.0.0. Development could then continue independently on these two branches. We could continue to make releases from the compatibility branch, though we'd be restricted to v0.Y.Z versions. We could increment the minor version for breaking changes and suggest that those on the compatibility branch depend on 0.1.x or 0.2.x or similar.

This strikes me as a good compromise. Do you agree?

[JAForbes]

First of all, I want to thank you for all the incredible additions and explorations you've made to date @davidchambers . I'm sorry I've not replied to everything yet, I have limited time at the momemnt but I am truly excited.

I have deployed code in numerous contexts that relies on paldepind/union-type, so I would get a lot of value from a direct port released as soon as possible. And I imagine others would benefit from the existence of a direct port. But I would also like sanctuary to explore union-types freely and come up with a solution that is highly composable and unsurprising. I personally subscribe to the same interface design philosophies as you @davidchambers, so I would also get a lot of value out of sanctuary's own interpretation.

I wouldn't want sanctuary to be required to maintain 2 interfaces. I would prefer to avoid instance methods, in fact I've been wondering whether we could just have a single case function that can pattern match any sanctuary type, and a union-type constructor factory.

So instead of List.case, we just have a single case with type inference. It could be more complicated to implement, but would allow for some very interesting patterns.

const Maybe = 
  $.UnionType('my-module/Maybe', {
    Just: [a]
    ,Nothing: []
  })

// Maybe a -> Maybe a -> Number
const addMaybe = 
  $.case([
     [Just(a), Just(a), (a,b) => a + b ]
    ,[Nothing, Just(a), (a, b) => 0 + b]
    ,[$.Any, $.Any , K(0) ]
  ])

addMaybe( Maybe.Just(4), Maybe.Nothing ) //=> 0
addMaybe( Maybe.Just(4), Maybe.Just(4) ) //=> 0
addMaybe(3, 4) //=> TypeError

This would more closely model a language level operator. We'd still be able support all existing features, like recursive types (with a sentinel), discriminated unions etc, generated constructors. But we could also use it against sanctuary types that are not generated by union-types.

Whether or not we explored this API or that API I think its clear its worth exploring union-types in sanctuary in depth instead of being tied to an API that was written with different goals and philosophies. I want to prevent a situation where we are bound to a legacy API on day 1.

So I wish for sanctuary to continue exploring any trajectories that match its core mission and philosophy.

However, I still do need a backwards compatible version, and I feel that could be useful to others. So I propose I simply release the backwards compatible version under my own namespace (under a different name). And in the near future when sanctuary has an answer to union-types, I will make the backwards compatible version a small wrapper on top of sanctuary's solution.

Then we won't need to juggle minor/major semver's etc. It might also provide a clear path from a more variadic audience to sanctuary with a less steep learning curve (I imagine front-end developers use union-type to emulate the Elm Architecture - they may benefit from a direct port; see the benefits of sanctuary / ramda and then explore it further ).

Does that sound good @davidchambers? I'd still be very invested in sanctuary's union-types and sanctuary in general and I would like to continue to contribute. I feel sanctuary-union-type will be a worse library if it makes concessions so early on without having the time to explore, experiment and refine.

[davidchambers]

However, I still do need a backwards compatible version, and I feel that could be useful to others. So I propose I simply release the backwards compatible version under my own namespace (under a different name). And in the near future when sanctuary has an answer to union-types, I will make the backwards compatible version a small wrapper on top of sanctuary's solution.

This sounds like an excellent idea to me! You're welcome to use any of my patches in #3 which are useful to you as you prepare to release an initial version of the package.

I look forward to discussing the "sanctified" API with you. I'll open a new issue for this purpose.

[jmatsushita]

Hello,

I'm interested in pattern matching on algebraic data structures and wonder if currently I should head towards https://github.com/JAForbes/sum-type or if there's a more idiomatic way to do this in sanctuary?

Cheers,

Jun

[davidchambers]

I suggest using sum-type, @jmatsushita. It will likely be possible to use sanctuary-union-type one day, but that could be two months from now or two years from now so don't hold your breath. ;)

[jmatsushita]

Ok thanks!