The Goal and open questions

[Rob Napier]

So, to sum up the goal of LlamaKit: There are a small number of very important features, of particular use to FP, but useful broadly, that are missing in Swift. Many programmers and framework writers would like to have a unified, near-consensus solution on these rather than each creating a nearly-identical-but-incompatible implementation. LlamaKit is designed to provide that as a small bag of low-overhead tools that more impressive things can be built on.

The most glaring example is Result (and the odious Box). Everyone needs it. Ideally everyone should be able to share the same type for nice interop. I believe we're pretty close to consensus on what it should look like. My current thinking is to put that in a tiny micro-framework called LlamaCore. That way, LlamaKit can have some other things in the repo without impacting consumers who *just* want Result.

I believe that operators and some functions (sequence, pure) are useful, but I think they should be kept out of LlamaCore. Custom operators are dangerous for a low-level framework to inject. Top-level functions are not as dangerous, but are still not always desirable because they pollute the consumer. I'd like to put operators in their own framework (LlamaOps). Helpful FP functions can go into another framework (LlamaLamb? :D more likely LlamaFunc). But I may leave most of this to others (like TypeLift) entirely.

My ideal situation is that there be a top-level LlamaKit that you can import and get everything (except LlamaOps) in one go. I don't know if you can really do this in Swift today. Does anyone know? While I want to keep things separate, I also worry about fragmenting too much and making it very complicated to consume.

After Result is settled, my other little project is LlamaFuture, which are the concurrency primitives. I know that TypeLift is also going down this road. Ideally, I'd like to provide a simple Future that others could build on, like Result. The main issues:

* Future should be based on GCD, not pthreads

* Future's API should *integrate* with GCD. The caller should be able to pass dispatch_queue_t. LlamaKit embraces Cocoa.

* Future should depend on no more than LlamaCore (and possibly not even that).

I'm struggling with how to break it up. Currently my Future cannot fail. There's a separate Task that contains a Future<Result<>>. There are many things you pass to a dispatch queue that can't fail, so I wanted to make the lowest-level primitive match that. I also have in mind a Promise, which is a Future that you complete by hand (but that raises the question of whether it's failable). Anyway, the design of this is an open question that I'd love to talk about because I think I can provide a very powerful GCD-based Future that could be shared without imposing much on higher-level libraries. My current sketch is here:

https://github.com/LlamaKit/LlamaKit/blob/a4de305580966b0c6efd9ad4181be4a7099c13cf/LlamaKit/Future.swift

Between TypeLift and RxCocoa, I think we have a great divergence of consumers. If LlamaKit can provide the small pieces of overlap between them, I think that would be incredibly powerful and prove that even very different approaches could interoperate. So I'm looking for your least-common-denominators here. What does everyone agree on?

-Rob

[Robert Widmann]

TypeLift has frameworks in the works for the latter 3/5ths of this post, so I'll just address the first part.  I do think Justin is right about there needing to be a bare minimum "framework" for functional programming.  Even if that means there's a repo sitting out there somewhere with 4 swift files in it, there is a need and we can fill it.  Once you do figure out either Kit or Core, it's possible for me to then make the Basis depend on it, thus, I think, fixing that issue Justin brought up on Swiftz.

What I really don't want is to see 6 different solutions to the same problem that just happen to be "more functional" or "more practical".  Ideally, and I am playing devil's advocate here, I would want to see LlamaKit become a part of TypeLift.  I feel like the Org can do more than just act as a Haskell to Swift transpiler.  Namely, provide a gradient that a particular framework or application author can use to dial up the level of FP concepts they want to include in their frameworks.  So I think it'll go something like this at first:

- Llama[Kit/Core]: The barest of bare files to get started with Functional Swift.  Either, Result, Box.  No "category theory", no algorithms, no operators.

- Basis: Basic algorithms and typeclasses.  Implementation of famous classes.  Typeclass conformances for Llama[Kit/Core] structures.  A gammut of common functional operators.

- Swiftz (before an eventual split): Data-Lens, STL extensions, Serialization Primitives, more complex algebraic structures.  More typeclass conformances.  Some "less common" operators

Future:

- Llama[Kit/Core]:

- Basis

- Swiftz

- Lens

- Parallel/Concurrent

- Serial

- SwiftCheck

- HTTP

- Random

- Etc. 

[Rob Napier]

I don't have any problem with moving under Basis or Core or the like. But the key I think is goal. At the bottom, I think we need the goal of "works fantastic with Cocoa and stdlib" and explicitly not the goal of "replaces or ignores Cocoa and stdlib." If on top of that are libraries that to varying degrees ignore or highly-augment-to-the-point-it's-a-different-thing (I put RxCocoa in that camp), that's fine. I just want to make sure that the very lowest layers embrace (to the point that they don't bother to abstract) Sequence, Collection, Array, GCD, NSURLSession, etc.

From your earlier posts and some of my discussions with Max, my understanding was that the goal with Basis/Swiftz was "Haskell in Swift" or possibly "stdlib done right." I'm explicitly trying to avoid those. If we can find a substrate that embraces existing Swift, stdlib, and Cocoa, I'm onboard. And frankly I'd rather work on a substrate later of TypeLift than create a separate framework. I do like the idea of a smooth spectrum.

Justin provides a great example of a non-haskell-ish consumer (who still has good awareness of FP). And I think common consumers should help drive the framework. So "would Justin use it?" I think is a fair criteria for success here.

Rob

--
You received this message because you are subscribed to the Google Groups "llamakit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to llamakit+u...@googlegroups.com.
To post to this group, send email to llam...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/llamakit/b22e9708-a87d-4038-8630-1e026799cab9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Widmann]

The thing is: where does Cocoa end and Swift begin?  Max and I seem to be using more pthreads than GCD, and I think that's partially because GCD (and Cocoa) has the same problems we're trying to solve: it's a really really big dependency to support.  And we'd only really need a very very small part of it to actually get stuff done at the higher layers.  I think Swiftz, for all its hardline approaches, is ultimately the way forward.  Maybe it's just too revolutionary.  Besides, I wonder what will become of these libraries when/if Swift becomes FOSS.  Not that I want to even think about the portability question, I just think it's a more future-proof approach.

[Rob Napier]

My entire goal is what I believe Swift's main goal is: To write really fantastic Apple-platform apps. I don't want to make any tradeoffs that move against that goal, even tradeoffs that make it easier to write really fantastic programs on other platforms. Those aren't the problem I'm trying to solve, and I don't think will ever be the problem Swift is trying to solve. Whether some piece of Swift becomes open source or not doesn't really matter to that (ObjC is open source today, so is Core Foundation).

So where does Swift end and Cocoa begin? Nowhere. They are the same, just like ObjC. At least for the purposes of LlamaKit. Cocoa is not a dependency; it is the platform.

The Swift team has been very clear about why Swift doesn't have concurrency primitives in the language: because GCD is Swift's concurrency primitive. If Swift evolves to a more powerful one, then I would very likely move to it. There is no chance that Apple will migrate Swift back to pthreads as its preferred concurrency system. That's a dead end and Apple actively discourages its use.

-Rob

[Justin Spahr-Summers]

On 2014-09-28, at 07:46, Rob Napier <robn...@gmail.com> wrote:

My entire goal is what I believe Swift's main goal is: To write really fantastic Apple-platform apps. I don't want to make any tradeoffs that move against that goal, even tradeoffs that make it easier to write really fantastic programs on other platforms. Those aren't the problem I'm trying to solve, and I don't think will ever be the problem Swift is trying to solve. Whether some piece of Swift becomes open source or not doesn't really matter to that (ObjC is open source today, so is Core Foundation).

So where does Swift end and Cocoa begin? Nowhere. They are the same, just like ObjC. At least for the purposes of LlamaKit. Cocoa is not a dependency; it is the platform.

I haven’t really chimed in on this thread, because I think you’ve summarized my point-of-view very well. I agree with all of this, and the other stuff about not trying to replace stdlib as well.

I love functional programming, and I love Haskell. However, when the rubber meets the road, it’s often difficult/unintuitive/complex to replace existing Cocoa idioms with pure FP idioms _while still appealing to Cocoa developers_. That last part is really the key—I want to build libraries that Cocoa developers love to use, not that they’re scared to use.

By necessity, ReactiveCocoa suffers from this problem to some extent, but I think its surprisingly significant adoption speaks to how well our compromises have paid off. If we push the envelope too far, we’ll be turning off potential users in the name of idealism, which is far more destructive (to the general welfare) than not being able to use Haskell idioms in Swift.

To be clear, in my role as an _application developer_ (working on a team that’s highly receptive to such things), I fully support everything that TypeLift, Swiftz, full LlamaKit, etc. are doing, and will probably take advantage of their APIs within actual applications. It’s just too costly to force all of those patterns onto everyone who wants to use my _libraries_.

[Robert Widmann]

I guess what I'm trying to get at is what happens to the huge amount of code Apple has stuck up in its platform. Cocoa is _massive_ and incredibly pervasive. You can't just start rewriting this thing in Swift and not make any huge paradigm changes. You also can't just keep it around while you spent time, money, and effort pushing your new language for the "next 10 years". It may be pragmatic to stress Cocoa-y patterns and libraries and the platform as a whole now, but I have a strong feeling the platform will shift. What direction, I can't say. But that doesn't mean we can't have a guess.

I've said it at least 3 times now: Idiomatic Swift is an oxymoron as of right now. When Apple spends the next few years improving its STL, the language, and its core productsaround it, then I'll be happy to revisit the question. But for now, arguing a Cocoa-only, OO-only, FP-only, FRP-Only, etc. approach because of a twisted definition of comfort are all equally shady. We're all trying to find what works because, frankly, nobody even Apple seems to know. I've just bet my horses on pure-ish FP augmentations to the STL. We will _never_ get a pure Swift, it just won't happen. But what we can get is a set of best practices out of an exploration of a number of tried and tested concepts.

This is ultimately why I want a gradient. If we're going to "force" a particular pattern on anybody, it'll be because they want to use, say Actors built on MVars, rather than roll something in GCD, or Lenses instead of setters and getters. If you want the advanced stuff, you have to play by our rules, but a common foothold at the bottom is good for everybody.