3 ms·

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

by 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.
  - Mithaldu 13y ago
    Yes what? Also, you wrote: > decoration [...] forms a [...] functor. That [...] Functor also provides a monad That is entirely at odds with the statement: > Decorators do not provide a monad at all Frankly, at this point i'm strongly considering the possibility that you're just trolling me.
    - tel 13y ago
      I'm not trolling, we're just talking around one another. There are a significant number of concepts that aren't easily explained in plain english required to get at the heart of "what is a monad?". Even that question itself is already making an interesting choice of definition and set of questions that can be confusing unless analyzed carefully (in particular "Monad" as a noun can mean something very different from monad as an adjective and both meanings are frequently used in descriptions of "what monads are"). I'm attempting to be strongly consistent in everything I'm saying, but it's not necessarily possible to both do that and keep speaking simply. The why of monads is that they're a very nice API or Interface that allows you to write easily analyzed and easily refactored programs. Most of the other descriptions are the why of a particular type which happens to instantiate the API.
      - Mithaldu 13y ago
        That sounds nice and all, but i still don't know why you contradicted yourself.
        tel 13y ago
        Okay, I'll explain it. Apologies for the apparent contradiction—I'm not trying to move the goal posts, just trying to avoid going into the weeds. As I said, Python decorators are essentially just a syntax for function composition. @deco def g(args): g := deco(g(args): body) body where (g := a) means a is assigned to the name g. As it turns out, functions form a type which is a functor over the result type. The fmap (arrow map) is just function composition. In Haskell you would write this as instance Functor ((->) r) where fmap g f = g . f where the (.) syntax is also function composition, very similar to the @deco syntax in Python. In this sense, I stated that @deco is a Functor. Now, the function data type also admits a Monad instance (which some people abuse terminology to say "functions are monads" but I highly dislike that terminology when speaking carefully). instance Monad ((->) r) where return a = \_ -> a (f >>= g) x = g (f x) x So in this way, the function type instantiates both Functor and Monad, but composition (which is (.) in Haskell and @deco is Python) is not directly related to the Monad. Instead, a function's Monad instance allows us to "defer application" and translate something like \x -> (1 + x, 2 + x) into do a <- (1+) b <- (2+) return (a, b) In this format it's pretty stupid looking, but we also tend to call this monad instance the "Reader Monad" which indicates computations which occur under a fixed set of configuration information—some static global variables. For instance, if I had a Key type which represented some encryption key I could change my encrypt and decrypt functions from encrypt :: Key -> String -> String decrypt :: Key -> String -> String to encrypt :: String -> Reader Key String decrypt :: String -> Reader Key String which, allows us to defer that extra `Key` argument until later. So, that's what I meant by saying that @deco isn't the Monad that its Functor represents—it only has the composition aspect, not the deferred application aspect.
      - jerf 13y ago
        'There are a significant number of concepts that aren't easily explained in plain english required to get at the heart of "what is a monad?".' Indeed, it's arguably not even the right question. "When is something monadic?" is a better one; "monad" is an adjective, not a noun. In Java terms, "Monad" is an interface and something is "monadic" if it implements the interface. (Except Java's type system can not express "Monad", so that doesn't work as a concrete example, but the idea is there.) I'm sure you've seen me claim this on /r/haskell, where I think people operate in a context where they find this so obvious that the very idea that there could be a problem is confusing... this is the sort of context that leads me to that claim, though. Regardless of whether it's a noun in math, in programming it's an adjective.

by tel 13y ago

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.
- Mithaldu 13y ago
  Yes what? Also, you wrote: > decoration [...] forms a [...] functor. That [...] Functor also provides a monad That is entirely at odds with the statement: > Decorators do not provide a monad at all Frankly, at this point i'm strongly considering the possibility that you're just trolling me.
  - tel 13y ago
    I'm not trolling, we're just talking around one another. There are a significant number of concepts that aren't easily explained in plain english required to get at the heart of "what is a monad?". Even that question itself is already making an interesting choice of definition and set of questions that can be confusing unless analyzed carefully (in particular "Monad" as a noun can mean something very different from monad as an adjective and both meanings are frequently used in descriptions of "what monads are"). I'm attempting to be strongly consistent in everything I'm saying, but it's not necessarily possible to both do that and keep speaking simply. The why of monads is that they're a very nice API or Interface that allows you to write easily analyzed and easily refactored programs. Most of the other descriptions are the why of a particular type which happens to instantiate the API.
    - Mithaldu 13y ago
      That sounds nice and all, but i still don't know why you contradicted yourself.
      - tel 13y ago
        Okay, I'll explain it. Apologies for the apparent contradiction—I'm not trying to move the goal posts, just trying to avoid going into the weeds. As I said, Python decorators are essentially just a syntax for function composition. @deco def g(args): g := deco(g(args): body) body where (g := a) means a is assigned to the name g. As it turns out, functions form a type which is a functor over the result type. The fmap (arrow map) is just function composition. In Haskell you would write this as instance Functor ((->) r) where fmap g f = g . f where the (.) syntax is also function composition, very similar to the @deco syntax in Python. In this sense, I stated that @deco is a Functor. Now, the function data type also admits a Monad instance (which some people abuse terminology to say "functions are monads" but I highly dislike that terminology when speaking carefully). instance Monad ((->) r) where return a = \_ -> a (f >>= g) x = g (f x) x So in this way, the function type instantiates both Functor and Monad, but composition (which is (.) in Haskell and @deco is Python) is not directly related to the Monad. Instead, a function's Monad instance allows us to "defer application" and translate something like \x -> (1 + x, 2 + x) into do a <- (1+) b <- (2+) return (a, b) In this format it's pretty stupid looking, but we also tend to call this monad instance the "Reader Monad" which indicates computations which occur under a fixed set of configuration information—some static global variables. For instance, if I had a Key type which represented some encryption key I could change my encrypt and decrypt functions from encrypt :: Key -> String -> String decrypt :: Key -> String -> String to encrypt :: String -> Reader Key String decrypt :: String -> Reader Key String which, allows us to defer that extra `Key` argument until later. So, that's what I meant by saying that @deco isn't the Monad that its Functor represents—it only has the composition aspect, not the deferred application aspect.
    - jerf 13y ago
      'There are a significant number of concepts that aren't easily explained in plain english required to get at the heart of "what is a monad?".' Indeed, it's arguably not even the right question. "When is something monadic?" is a better one; "monad" is an adjective, not a noun. In Java terms, "Monad" is an interface and something is "monadic" if it implements the interface. (Except Java's type system can not express "Monad", so that doesn't work as a concrete example, but the idea is there.) I'm sure you've seen me claim this on /r/haskell, where I think people operate in a context where they find this so obvious that the very idea that there could be a problem is confusing... this is the sort of context that leads me to that claim, though. Regardless of whether it's a noun in math, in programming it's an adjective.