4 ms·

Something I've wondered is why we can't have a language that looks totally procedural but uses monads under the hood to reason about state at any given point in

Something I've wondered is why we can't have a language that looks totally procedural but uses monads under the hood to reason about state at any given point in the process. This would mostly be sugar, but I think it could make that stuff much more accessible. We get small, specialized fragments of this in Rust's borrow-checker and TypeScript's control-flow analysis, but I'm not aware of something that tries to take the whole of IO-monads and reshape them into a familiar format.

zozbot234 5y ago
Rust's borrow checker (or rather its affine typing, which the borrow checker partly implements - "affine" rather than linear, b/c the compiler is free to drop() objects that are no longer used) actually gets in the way of using monads to reason about state. That's one key reason why the language still lacks a general monad construct.
Y_Y 5y ago
What about Haskell? do putStr "What is your first name? " first <- getLine putStr "And your last name? " last <- getLine let full = first ++ " " ++ last putStrLn ("Pleased to meet you, " ++ full ++ "!") (see: https://en.m.wikibooks.org/wiki/Haskell/do_notation https://en.m.wikibooks.org/wiki/Haskell/do_notation )
- amusedcyclist 5y ago
  Gets a bit uglier if you use >>= instead lol
zeugmasyllepsis 5y ago
This might work out well in practice when tracking a single effect with a monad (e.g. with Haskell's `do` notation) but I think it quickly falls apart when working with multiple effects. Monads don't have a general form of composition - at the very least the order that they're composed matters to the outcome of the program. Procedural code is generally flexible enough to allow you to mix-and-match how effects gets handled, which I think would be difficult and impractical to work out in monadic contexts.
- zozbot234 5y ago
  If you want to mix and match effects without regard to order of composition, that's what Lawvere theories are for (commonly known as 'algebraic effects'). You're right that monads don't give you this, but there are ways of describing these patterns without resorting to "procedural" idioms.
AnimalMuppet 5y ago
It seems to me that if it looks totally procedural, then most programmers are going to reason about it totally procedurally. Using monads under the hood isn't going to buy you anything. In particular, it isn't going to make FP any more accessible, because the programmers won't be doing FP. They'll be doing procedural programming. Sure, the language may turn it into FP under the hood, but that's a detail of how the compiler generates its intermediate forms. That's not the claimed magic of FP; it's all in how you think. And if you think you're doing procedural, well... you don't get any FP magic that way.
- garethrowlands 5y ago
  True enough, when you're writing imperative Haskell, you're not hitting the claimed magic of FP. But: 1. Haskell lets your write the majority of your code in pure style. And it helps you separate the imperative parts (like pure core, imperative shell). 2. The compiler tries hard to generate the same machine code as C. The difference is that it gives the programmer more options: because the imperative parts are values (actions), it's strightforward to calculate them, which you can't do in C (you'd need the preprocessor or maybe LISP macros).

zozbot234 5y ago

Rust's borrow checker (or rather its affine typing, which the borrow checker partly implements - "affine" rather than linear, b/c the compiler is free to drop() objects that are no longer used) actually gets in the way of using monads to reason about state. That's one key reason why the language still lacks a general monad construct.

Y_Y 5y ago

What about Haskell? do putStr "What is your first name? " first <- getLine putStr "And your last name? " last <- getLine let full = first ++ " " ++ last putStrLn ("Pleased to meet you, " ++ full ++ "!") (see: https://en.m.wikibooks.org/wiki/Haskell/do_notation https://en.m.wikibooks.org/wiki/Haskell/do_notation )

amusedcyclist 5y ago
Gets a bit uglier if you use >>= instead lol

zeugmasyllepsis 5y ago

This might work out well in practice when tracking a single effect with a monad (e.g. with Haskell's `do` notation) but I think it quickly falls apart when working with multiple effects. Monads don't have a general form of composition - at the very least the order that they're composed matters to the outcome of the program. Procedural code is generally flexible enough to allow you to mix-and-match how effects gets handled, which I think would be difficult and impractical to work out in monadic contexts.

zozbot234 5y ago
If you want to mix and match effects without regard to order of composition, that's what Lawvere theories are for (commonly known as 'algebraic effects'). You're right that monads don't give you this, but there are ways of describing these patterns without resorting to "procedural" idioms.

AnimalMuppet 5y ago

It seems to me that if it looks totally procedural, then most programmers are going to reason about it totally procedurally. Using monads under the hood isn't going to buy you anything. In particular, it isn't going to make FP any more accessible, because the programmers won't be doing FP. They'll be doing procedural programming. Sure, the language may turn it into FP under the hood, but that's a detail of how the compiler generates its intermediate forms. That's not the claimed magic of FP; it's all in how you think. And if you think you're doing procedural, well... you don't get any FP magic that way.

garethrowlands 5y ago
True enough, when you're writing imperative Haskell, you're not hitting the claimed magic of FP. But: 1. Haskell lets your write the majority of your code in pure style. And it helps you separate the imperative parts (like pure core, imperative shell). 2. The compiler tries hard to generate the same machine code as C. The difference is that it gives the programmer more options: because the imperative parts are values (actions), it's strightforward to calculate them, which you can't do in C (you'd need the preprocessor or maybe LISP macros).