4 ms·
There is a point to it though - continuations, for instance, have monadic structure - but at the cost of introducing a strict evaluation order. There is other w
by alipang 8y ago
There is a point to it though - continuations, for instance, have monadic structure - but at the cost of introducing a strict evaluation order. There is other work related to the linear logic that does what Monads do - provide an abstract syntax - but working better with laziness, so it's not exactly wrong to give Monads an operational perspective.
There are many perspectives one can use to understand Monads. The operational one is valid - and useful for many beginners. Of course, it's not the only way to look at them, as you point out.
- a-saleh 8y agoWhat is this linear-logic thing that does what monads do? I haven't yet grokked linear-logic (apart from the advert, that you might want to use it to reason about resource constraints), so I would like to read about this :)
- drb91 8y agoI think the commenter is referring to the process of declaring an order for executing a compute graph. With CSP languages this is established by the order in which the statements appear and reference each other, and computation is explicit: all previous statements in a given process have finished executing at any given point. This is in contrast to Haskell that uses monads to declare the computation graph (well, functions, but monads are under discussion here). In this world, data is computed lazily as needed. The questions you ask about the code center around functions and their dependencies, not necessarily computation order. A task that is trivial to express with on paradigm might be non-trivial to express on the other: haskell is excellent about expressing lazy computation and side effects, whereas a CSP language will offer easy reasoning about the specific and correct order of execution. Note I am not a PL expert, just an enthusiast. My diction may be off for the domain.
- alipang 8y agoAn introduction was posted here recently - which may be good, depending on how comfortable you are with logic in general. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.673.1176&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.673...
- fanf2 8y agoYou might like to look at Clean (terrible name) which is roughly as old as Haskell and in a similar style, but instead of Monads it uses linear types to enforce the order of IO - https://clean.cs.ru.nl/Clean https://clean.cs.ru.nl/Clean
- lmm 8y agoThe operational perspective is valid but it doesn't help to answer the question, IMO. If your answer to "what is the problem?" is "the problem is our hard-to-predict evaluation strategy", then the beginner's natural follow-up question is "why not just use a normal evaluation strategy?", and there's no good answer to that one (indeed many regard Haskell's laziness as the wrong choice; in recent times we've seen post-Haskell languages e.g. Idris moving away from it, and the best-known industrial deployment of Haskell uses a strict variant). Meanwhile I find monads very useful in Scala, even without any laziness in sight.
- AnimalMuppet 8y agoIf you actually need to care about the evaluation strategy, then Haskell may not be the language for your project. > Meanwhile I find monads very useful in Scala, even without any laziness in sight. But do you use monads for all the things Haskell programmers use them for? Or only a subset of those things?
- Retra 8y agoMost projects do not make a language choice based on the needs of the model, but based on the needs of the developers. It's the same reason you've chosen English to write your comment in, rather than some other language that might express it better.
- lmm 8y ago> If you actually need to care about the evaluation strategy, then Haskell may not be the language for your project. Almost all projects end up needing to care about performance at some point or other, if only a little. (So yes, Haskell is probably not a suitable language for most projects, sadly) > But do you use monads for all the things Haskell programmers use them for? Or only a subset of those things? All the things, as far as I'm aware. Certainly the obvious ones like IO.
- alipang 8y agoMost monads I'm aware of have an operational interpretation. The `Maybe` (or `Option`) monad, for instance, has the single effect fail :: Maybe a fail = Nothing as soon as `fail` is "evaluated". Evaluation here is in the monadic sense - and is not related to the evaluation strategy of the host language. List monads have a non-determinism operational interpretation. The `State`, `Writer` and `Continuation` monads obviously do as well. You could say the `Reader` monad has the single effect ask :: Reader e e but thinking about this operationally is certainly not that helpful as this returns a single constant value from the environemnt. The same thing goes for `Free` which is essentially a data structure for the abstract syntax of Monads. However in some sense even for this part of you understanding of free monads is likely based in providing a natural transformation to an interpretation in another monad (i.e. `iterM`)