Open topics: Result, Either, Try, Future

[Rob Napier]

Wanted to throw out a few open topics:

* Generic error type

The consensus seems to be Result<T, Error> is better than Result<T>. I am waiting to hear any dissent on this, but it seem the way we're going. I've been playing with it, and it seems to work fine.

* try

I'm thinking of changing this to withError so that the parameter is more obvious. The idea is to make NSErrorPointer easy. See previous posting for the actual code.

* Either

Since that makes Result === Either with different words and different order of type declaration, does it makes sense to make Result explicitly conform to EitherType (https://github.com/robrix/Either). There seems to be consensus that Result's syntax is more approachable. There seems to be consensus that Result is still a good idea because its more approachable if you don't have a long FP background.

* Should Result be its own microframework called Result, a la Rob Rix's Either?

I'm tempted to go the other way and ask RobR to merge Either into LlamaKit so they can share Box rather than having tiny microframeworks that users have to individually manage. To me, "drop a single file into your project" is incredibly nice compared to "add three submodules that all have basically a single file in them." If CocoaPods were "the normal way" I might feel different, but I hat to make this stuff actually rely on a dependency management system. But I'm not sold either way; I'm interested in opinions.

It also looks like RobR is working on Prelude, which is something I also wanted to work on. I want to a version of many Haskell functions (mostly from Data.List) that works like Swift. So for instance, functions go at the end (backwards of Haskell), and naming according to Swift rather than Haskell conventions (reduce1, not foldl1). And no replacing existing stuff (so Optional, not Maybe). sum, product, scanl, zipWith, maximumBy, etc. I don't want to require all that in order to get Result, but I want it under a "LlamaKit" umbrella so it's easy to find things that work together.

Also pending is my Future work (GCD-based Results). Is anyone else already exploring that really well in a way that we might find consensus around a small type?

Thoughts? (Especially RobR?)

-Rob(N)

[Thomas Visser]

My two cents regarding the Future type. I've been building an approach to Futures in Swift here: https://github.com/Thomvis/BrightFutures. 

I'm definitely taking a different angle on the Future type than you seem to take with LlamaKit. I'm primarily fuelled by my experience with BFTask, vague memories of Haskell and studying of the Scala API doc. It might help you to see what you would want in a simple Future type and what you wouldn't want in there. Would be happy to hear about that too!

Best,

Thomas

Op dinsdag 2 december 2014 19:40:21 UTC+1 schreef Rob Napier: