3 ms·

In Haskell some big rules you get around are: 1. Functional purity must be maintained for all code. This means for example that no side effects (IO) may happen

In Haskell some big rules you get around are: 1. Functional purity must be maintained for all code. This means for example that no side effects (IO) may happen. Thus some monads exist for the simple purpose of doing IO. 2. As you mentioned, state may not be mutated. To circumvent that there's a monad that simply marks a code block as "variables of this type may be changed in here, as long as they don't get out of this scope". 3. I only know about this vaguely, but as i understand it Haskell is strictly typed. This makes some things inconvenient, so Maybe allows some loose typing. I can't give examples in JS, but i actually got one for python: Decorators. In Python you cannot implement a function with this specification: It takes exactly these inputs in this order: 1) a function object, 2) a function name, 3) a multiline anonymous function. It calls the function passed as the first parameter, with the third parameter as its parameter. It takes the result, which is expected to be a function, and installs it in its calling scope as a new function, with the name passed in the second parameter. Since this is not possible to implement in pure python, decorators were implemented in the core. I'm not 100% sure, but i think they actually do qualify as monads.

dllthomas 13y ago
For the record, Data.Dynamic has a type called Dynamic which can be used to weaken typing. It's not a monad, though - it only implements Show and Typeable (and recently Exception, apparently). http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Dynamic.html#t%3ADynamic http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Dy...
tel 13y ago
1. IO doesn't have to be a monad, it simply was designed that way because the monad interface is so nice. In older (very functional) versions of Haskell this wasn't the case. 2. That's honestly not a bad description of the State monad spoken using procedural vocabular, but it is very far away from an accurate representation. At the very least it's worth noting that this isn't a syntactic thing—all of the elements are first-class. 3. Maybe is still strictly typed. It causes the possibility of null to be represented at the type level so that nobody ever accidentally forgets to check it. I never get null errors in Haskell. Finally, decorators are Functors perhaps, if you strain to look at them that way, but not at all monads.
- Mithaldu 13y ago
  > Finally, decorators are Functors perhaps, if you strain to look at them that way, but not at all monads. You can't say such a thing and then run away without saying why not. How is anyone supposed to learn about this if nobody explains the why? :) Edit: > 3. Maybe is still strictly typed. It causes the possibility of null to be represented at the type level so that nobody ever accidentally forgets to check it. I never get null errors in Haskell. Let me reword point 3. Haskell is strict about types in that it asks you to do a lot of checking. Using Maybe you can make Haskell behave like a loose language that doesn't require any checking from you.
  - tel 13y ago
    Python decorators are basically as follows @f def g(args) body translates as g := f(fun(args) body) If my syntax makes sufficient sense (g := a translates as "assign a to g"). That means that decoration is nothing much more than function composition which forms a very particular functor. That same Functor also provides a monad, but continuing to work this example until that's clear is so far from obvious that I think it'd only serve to mislead.
    - Mithaldu 13y ago
      If it isn't a monad, but provides one, then this seems to be the perfect example to explain on, since decorators are understood and monads are something smaller than decorators and as such should be able to be explained by reducing the explanation of decorators. Also do keep in mind that i didn't say decorators were a monad in any language, just in python, because they cause a curious side effect that is otherwise only attainable with much self-repeating and hard-to-read syntax.
      - tel 13y ago
        Yes. Decorators do not provide a monad at all, not even in Python. The very dim relation between the two is academic at best and completely irrelevant at worst.

dllthomas 13y ago

For the record, Data.Dynamic has a type called Dynamic which can be used to weaken typing. It's not a monad, though - it only implements Show and Typeable (and recently Exception, apparently). http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Dynamic.html#t%3ADynamic http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Dy...

tel 13y ago

1. IO doesn't have to be a monad, it simply was designed that way because the monad interface is so nice. In older (very functional) versions of Haskell this wasn't the case. 2. That's honestly not a bad description of the State monad spoken using procedural vocabular, but it is very far away from an accurate representation. At the very least it's worth noting that this isn't a syntactic thing—all of the elements are first-class. 3. Maybe is still strictly typed. It causes the possibility of null to be represented at the type level so that nobody ever accidentally forgets to check it. I never get null errors in Haskell. Finally, decorators are Functors perhaps, if you strain to look at them that way, but not at all monads.

Mithaldu 13y ago
> Finally, decorators are Functors perhaps, if you strain to look at them that way, but not at all monads. You can't say such a thing and then run away without saying why not. How is anyone supposed to learn about this if nobody explains the why? :) Edit: > 3. Maybe is still strictly typed. It causes the possibility of null to be represented at the type level so that nobody ever accidentally forgets to check it. I never get null errors in Haskell. Let me reword point 3. Haskell is strict about types in that it asks you to do a lot of checking. Using Maybe you can make Haskell behave like a loose language that doesn't require any checking from you.
- tel 13y ago
  Python decorators are basically as follows @f def g(args) body translates as g := f(fun(args) body) If my syntax makes sufficient sense (g := a translates as "assign a to g"). That means that decoration is nothing much more than function composition which forms a very particular functor. That same Functor also provides a monad, but continuing to work this example until that's clear is so far from obvious that I think it'd only serve to mislead.
  - Mithaldu 13y ago
    If it isn't a monad, but provides one, then this seems to be the perfect example to explain on, since decorators are understood and monads are something smaller than decorators and as such should be able to be explained by reducing the explanation of decorators. Also do keep in mind that i didn't say decorators were a monad in any language, just in python, because they cause a curious side effect that is otherwise only attainable with much self-repeating and hard-to-read syntax.
    - tel 13y ago
      Yes. Decorators do not provide a monad at all, not even in Python. The very dim relation between the two is academic at best and completely irrelevant at worst.