Higher Kinded Types (Monads, Functors, etc.)

(Elviro Rocca) #1

Hi everyone, I read every post in the Higher-Kinded Types ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html ) thread from about a year ago, and I was wondering what's the status on the matter: I'm aware of the proposal draft ( https://github.com/typelift/swift/issues/1 ), but I'd like to know if the Swift team has reconsidered the possible relevance of HKT for Swift in the foreseeable future.

By reading the discussion I found that the main concern from the Swift team was about practical use cases that could be of interest for a huge chunk of Swift developers: I don't think that a language feature should be there only if affects the majority of users, because of course you always have users at many different levels of awareness and understanding, not to mention experience and background, but I understand that, considering the time constraints in language development and proposals review, the focus should (initially) be on things that matter the most to the vast majority of developers.

But the idea of opposing a proposal because it's "hard to understand" (to some people, with different background) is baffling to me: there could be NO evolution whatsoever if everyone's only focus was on what feels familiar. But I don't want to talk about this: I just want to mention that if someone argues that they're not understanding a construct even if they consider themselves smart and experienced, that's their problem (maybe they're simply non experienced in that particular field), not a problem of the construct itself. And the fact that most things are mappable is not something functional programmers "believe": there's a huge corpus of research in the field of abstract mathematics that confirms this intuition. But anyway, let's move on.

I'd like to mention something that I consider a practical use case for the need of being able to express something like mappables and flatMappables in a abstract way: what's usually referred to as "monad transformers". I know that it's another concept that can be hard to grasp if you're not used to work with monads, but bear with me. Also, not sure about the etiquette here: it's an old discussion, but I wanted to offer my two cents.

Many functional programming techniques try to achieve true composability of code by decomposing logic in generic classes, that express a particular piece of that logic: the "Result" type ( https://github.com/antitypical/Result ) is a classic case (the same concept is similarly implemented by Swift throwable functions, but in a less composable way). There are many more types that do this, for example the Deferred type ( https://github.com/bignerdranch/Deferred ) was also mentioned in the discussion. Another type that I use a lot is the Writer type ( https://en.wikipedia.org/wiki/Monad_(functional_programming)#Writer_monad <https://en.wikipedia.org/wiki/Monad_(functional_programming)#Writer_monad> ) that lets me accumulate an auxiliary result while executing an algorithm ( for example, generating an index path while traversing a tree ). And the Optional type is already in Swift. But while these types are useful by themselves, they become even more powerful when combined: for example, Deferred + Result is basically a Future, that is, an asynchronous computation that can fail. Even more interesting is a Deferred + Writer + Result (I going to refer to it as "DefWriRes"), something that I currently use while developing my HTTP clients, because I can accumulate information about request and response in a clean, composable way: unfortunately, mapping and flatMapping breaks when combining these types, because mapping a DefWriRes will require a function working on Writer, while I really just work on the type wrapped by the internal Result. Monad transformers work that way: they allow you to "go deeper" in combined monads. Now, the interesting thing is that to map a DefWriRes we only need to now that Deferred, Writer and Result are mappable, but without this abstraction I'm forced to copy and paste hundreds of lines of code (for every possible combination) where the only thing that changes is the type definition, because the method calls are just maps.

The case is similar for flatMap, so I need to call "flatMap" on something that's flatMappable, with the difference that I need to be able to unwrap the value in the Result (so I need to know how Result works, it's not just mapping), and I need to be able to create a "empty" Writer and Deferred (that's already achievable by the type system). But the case is similar, the only difference is that I need a specific "ResultTransformer" (I actually implemented this via protocols and constrained extensions, but the implementation details are not relevant for the case).

So what's the use case? If I was able to generically express a mappable and a flatMappable, I could combine those things multiple times at any level without rewriting the same almost identical code for every combination. And even if you're not a functional programmer, types like these are very useful to clearly and cleanly express the semantics of your code: in fact, the Optional type is extremely useful exactly for this, and I'm thankful for the fact that it is in the standard library, along with the respective map and flatMap methods.

What do you think? Thanks

Elviro

7 Likes
Questions about the future of Protocols with Associated Types
Generic associated type
(Chris Lattner) #2

Hi everyone, I read every post in the Higher-Kinded Types ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html ) thread from about a year ago, and I was wondering what's the status on the matter: I'm aware of the proposal draft ( https://github.com/typelift/swift/issues/1 ), but I'd like to know if the Swift team has reconsidered the possible relevance of HKT for Swift in the foreseeable future.

Hi Elviro,

HKT’s come up from time to time, so there is definitely interest, that said, I can’t imagine that this will be a priority to get done in Swift 4.

By reading the discussion I found that the main concern from the Swift team was about practical use cases that could be of interest for a huge chunk of Swift developers: I don't think that a language feature should be there only if affects the majority of users, because of course you always have users at many different levels of awareness and understanding, not to mention experience and background,

Right. I’m personally not opposed to having advanced features in Swift when they are highly motivated. We only aim to make sure that they only affect/benefit people who want to use them. Advanced features that beginners are forced to reckon with violate our goals to have a shallow learning curve. HKTs seem like they’d be fine in this regard.

but I understand that, considering the time constraints in language development and proposals review, the focus should (initially) be on things that matter the most to the vast majority of developers.

Right, this is the principle reason I can’t imagine that HKTs will get prioritized. There are a *TON* of improvements that will have widespread positive impact, and the Swift compiler team is very thinly spread. We are forced to pick and choose a few things that we think will have the biggest impact on the entire Swift community.

-Chris

···

On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution <swift-evolution@swift.org> wrote:

3 Likes
(Elviro Rocca) #3

Hi Chris, thanks a lot for the answer, that's exactly what I wanted to read and it gives me hope for the language's future :slight_smile:

- Elviro

···

Il giorno 12 dic 2016, alle ore 06:46, Chris Lattner <clattner@apple.com> ha scritto:

On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi everyone, I read every post in the Higher-Kinded Types ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html ) thread from about a year ago, and I was wondering what's the status on the matter: I'm aware of the proposal draft ( https://github.com/typelift/swift/issues/1 ), but I'd like to know if the Swift team has reconsidered the possible relevance of HKT for Swift in the foreseeable future.

Hi Elviro,

HKT’s come up from time to time, so there is definitely interest, that said, I can’t imagine that this will be a priority to get done in Swift 4.

By reading the discussion I found that the main concern from the Swift team was about practical use cases that could be of interest for a huge chunk of Swift developers: I don't think that a language feature should be there only if affects the majority of users, because of course you always have users at many different levels of awareness and understanding, not to mention experience and background,

Right. I’m personally not opposed to having advanced features in Swift when they are highly motivated. We only aim to make sure that they only affect/benefit people who want to use them. Advanced features that beginners are forced to reckon with violate our goals to have a shallow learning curve. HKTs seem like they’d be fine in this regard.

but I understand that, considering the time constraints in language development and proposals review, the focus should (initially) be on things that matter the most to the vast majority of developers.

Right, this is the principle reason I can’t imagine that HKTs will get prioritized. There are a *TON* of improvements that will have widespread positive impact, and the Swift compiler team is very thinly spread. We are forced to pick and choose a few things that we think will have the biggest impact on the entire Swift community.

-Chris

1 Like
(Félix Fischer) #5

What is so inherently wrong about Haskell? And how are Monads cancers?

3 Likes
(Hooman Mehr) #6

:smile:

I understand what you mean, and sympathize. But it is already too late.

I have seen Swift code that only a Haskel programmer would understand (given the excessive use of custom operators).

Actually, I would love to see higher kinded types. As a pragmatic language, Swift should let people work the way they are comfortable with. In a team project, the team leader needs to decide which features of the language are off-limits for that project or are reserved for some specific parts.

For example, if you look at Swift C++ source code, you will see that it uses a very conservative and straightforward style of C++ programming, which is preferred for a code base as large as the Swift compiler.

1 Like
(John McCall) #7

Just a reminder to keep the conversation respectful. If you don’t like Haskell, fine, but I’m sure you can find some constructive way to talk about the specific things you dislike, to the extent that it’s relevant to Swift.

9 Likes
(Saagar Jha) #9

There’s a lot of things that can be done nicely in Swift using code that uses constructs similar to those provided in Haskell; Swift aims to provided these facilities so that such code is possible. However, it also aims to be a good pedagogical language, which means that these advanced features are selectively disclosed. If you feel that this is not done correctly, please feel free to share why you think so here; however, blanket statements such as “FP is brain damaging for most developers and I get he feeling the Haskell group has hijacked Swift” are not helpful.

(Anthony Latsis) #10

Isn’t this all simulated with generics and protocol oriented programming on Swift? Or you would like some specific formal construct aka category, followed by new keywords, that would be like a constrained protocol with a functor and other requirements?

#11

I guess my command of english is to bad to describe what I mean. I can code without problems in a lot of languages, but FP always leads to heavy headache when I try to understand it, has been so since University. For me it’s mind boggling and I fear as a user of Swift to be forced to use it which would force me to abandon Swift 8(

(Anthony Latsis) #12

Let me put it this way: The developement of new theories, let it be category theory, and evolution of exact sciences in general, doesn’t prevent kids from learning and understanding math at school and arithmetics at the kindergarten.

(Saagar Jha) #13

So the root issue here is not the fact that functional programming’s inclusion in Swift is bad, rather, it’s the fact that it hasn’t quite “clicked” for you.

Sure, that’s fine. Everyone was there at some point.

The nice thing about Swift is that you’re really not forced to do anything; if you don’t like using something you don’t have to. It’s there if you want to reach for it, but if you’re not comfortable with something or have strong opinions against using it usually you can stay away from it. It’s very possible to use Swift as a imperative language if you don’t want to dive into the functional part yet.

We don’t want you to abandon Swift! Rather, we’d really like for Swift to be a way for you to experience a new way of programming and try it out. Ideally, it would be a great way for you to “get your feet wet” with functional programming so you could understand how it worked and not be afraid of it anymore.

1 Like
#14

That’s not going to happen as long as a simple FP hello world tutorial leads to splitting headache and is full of insane amounts of math lingo.

(Tino) #15

Some time ago (most likely it started when multicore became more or less standard), FP got quite a lot attention (which it deservers - it can circumvent threading problems which are much more complicated than, let’s say, a monad) - but, as often in our industry, imho it got hyped as well.
I don’t mind people being attracted by FP, and Swift getting better support for that model - it just starts getting problematic when supporters propagate it to be the one and only way to write software and try to cripple other aspects of Swift.
OO has never been a silver bullet, and the same is true for FP (btw, one of Swifts most prominent features - Optionals - are monads ;-)

(Anthony Latsis) #16

Could you clarify why, please?

(Saagar Jha) #17

I’d suggest starting off by taking a look at map(_:), filter(_:), or reduce(_:_:) and trying to understand what they do, as well as the equivalent imperative code. I can’t suggest any good guides off of the top of my head, but I’m sure someone on these forums can suggest one.

#18

They are syntactic sugar around a simple loop? Or what do you mean?

(Saagar Jha) #19

No, not quite, but it’s good to see that you understand what they do. I’m not going to try to discuss all of functional programming in this thread, but I urge you to try to understand how the paradigm shift that these functions provide: instead of having a set of work that you’ve essentially hard-coded into the body of a for loop, you’re now able to provide custom code that can change.

(Gwendal Roué) #21

He means that map, filter and reduce come from FP. We’re all quite used to them now. But they really were invented by FP people. And it happens that those are so handy and easy to understand that we all love them. They have entered our culture.

We’re in a moment in the history of programming language design where FP has a strong influence.

But influence does not mean ruling. I’m not sure you have to fear that words like “monads”, “functors”, “materialize”, “reify”, and other weird abstract beasts would enter your daily Swift job, and push you out. On the contrary, the Swift core team has been, so far, able to offer a pretty balanced language.

1 Like
(Gwendal Roué) #22

Do you love Swift immutable structs (let vs. var, etc.) ? It’s FP heritage.

Do you love map and filter? It’s FP heritage.

Do you love closures? It’s FP heritage.

2 Likes
#23

No, fail to see the real value in them.

Ditto, they are just syntactical sugar around easily written loops.

Love is to much as I only use them a callbacks.