4 ms·

Monads and Macros

69 points by ColinWright 5y ago

Ericson2314 5y ago
Honestly it's posts like this that make me think the HN lisp bump is out of control. I have no idea what the hell the post is trying to stay, and as someone that cares enough about both to repeatedly complain that Template Haskell needs to be more like Racket with proper phase separation, I didn't learn anything and just see vague oft-repeated aphorisms juxtaposed.
- lopatin 5y ago
  https://www.youtube.com/watch?v=ADqLBc1vFwI https://www.youtube.com/watch?v=ADqLBc1vFwI
- chowells 5y ago
  Does the proposal to allow imports that only apply during template haskell evaluation improve things?
  - Ericson2314 5y ago
    See my comments to https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/ghc-proposals/ghc-proposals/pull/412, where I invoke Racket frequently. It's the right sort of goal, but we have to go all the way to full phase separation to make it mean something.
btilly 5y ago
For those who wonder why monads would be like burritos, read https://blog.plover.com/prog/burritos.html https://blog.plover.com/prog/burritos.html. Though a large burrito as a joke to represent both monads and macros is kind of catering to a niche audience.
WastingMyTime89 5y ago
> Few people are excited about both monads and macros; only one person that I know comes to mind. I don’t understand what the article is trying to convey. Everyone in the PL community know about monads and macros but they are tools and people are rarely excited about tools. The article seems to have a strong Haskell user bias. For example, both using macro and monads is very common in Ocaml. JaneStreet, the company which uses Ocaml the most, uses both extensively. Ocaml provides advanced macro functionalities (called ppx rewriters) and let-binding overloading to make writing monadic code easier. There is no opposition between these two functionalities.
- maxiepoo 5y ago
  Exactly, Haskell's "do" notation is essentially defined as a built-in macro, so if you ever want to use "do" notation in a language that doesn't have it built-in you will need to use macros. (Let-binding overloading is essentially do notation in case that's not clear)
  - tromp 5y ago
    do is more syntactic sugar for >>= (monadic bind) than macro. E.g. do s <- readLine "Enter name:" putStr $ "Hello, " ++ s reduces to readLine "Enter name:" >>= (\s -> putStr $ "Hello, " ++ s) But I agree you can use macros to implement syntactic sugar.
  - marcosdumay 5y ago
    Macros are way more powerful than binding, for both the best and the worst. Yes, you can use macros to add do-notation to a language. But you can also use macros to add things like type checks and new conditional statements. You can't add those with do-notation.
  - whateveracct 5y ago
    "do" is also no longer hard-coded. There are multiple language extensions that allow you to change what it desugars to, which is really cool.
- avgcorrection 5y ago
  > I don’t understand what the article is trying to convey. Lispers are from Mars and Haskellers are from Venus. That’s it.
- isaacimagine 5y ago
  As a compiler engineer, I get excited about tools. I think it's important to use mathematical foundations in a way that is both intuitive and transparent to the end user. Aside from monads and macros, OCaml remains a great example in this area because of its support for type inference and type annotations; on the surface, the code you write is mostly 'untyped,' save for at function boundaries and data definitions. Much how like monads and macros ultimately compile, so will correct typed and untyped code. I'm not sure how clear I'm being, but in essence: tools should be as lispy on the surface as possible (for ease of prototyping), while being built on haskelly* foundations (for correctness). There is no one silver bullet, it's about finding the right balance for the issue at hand: and as a tool, you should leave that decision to your end-users. *I use lisp and haskell to mirror the article, but this is true of any tool, imperative or functional, language or otherwise.
dustingetz 5y ago
macros are compilers, monads are interpreters
- celeritascelery 5y ago
  Trying to wrap my head around this. How are monads like interpreters?
  - chalst 5y ago
    If you look at each as languages for staging computations, what you stage with macros happens before "normal" computation, so likely happens at compile time, while what you stage with monads happens after, so must be deferred to run time.
  - dustingetz 5y ago
    google "monadic interpreter" One thing monad/bind can do that macros cannot is make arbitrary runtime decisions about what to do next, with runtime information. A macro is constrained by what is known statically in the AST. This is why compiled languages are far easier to optimize (it is merely algebraic rewrites of the AST) whereas dynamic languages have runtime eval.
  - Tyr42 5y ago
    Lets get concrete and make a simple example State monad. You have access to an extra variable S, with getS and setS, and each of those return values of our StateMonad. Using these (and >>= aka bind) you can write something which increments the number in the state by one, yes? increment = do s <- getS setS (s+1) and this increment is a value of our StateMonad. This doesn't run on it's own though, it needs the "interpreter" to run the state monad, and put in a initial value of the state, and maybe take it out at the end. That's the way you can think of Monads as interpreters in a very rough sense. Now, you can do fancier things, where you can set up a "free monad", which is basically going to record everything into a syntax tree, and then you really have an interpreter. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
AzzieElbab 5y ago
Macros ! Monads !! Monads via macros !!!
bjoli 5y ago
Alexis King had a talk about Hackett, a sadly abandoned, metaprogrammable haskell: https://youtu.be/5QQdI3P7MdY https://youtu.be/5QQdI3P7MdY

69 points by ColinWright 5y ago

Honestly it's posts like this that make me think the HN lisp bump is out of control. I have no idea what the hell the post is trying to stay, and as someone that cares enough about both to repeatedly complain that Template Haskell needs to be more like Racket with proper phase separation, I didn't learn anything and just see vague oft-repeated aphorisms juxtaposed.

lopatin 5y ago
https://www.youtube.com/watch?v=ADqLBc1vFwI https://www.youtube.com/watch?v=ADqLBc1vFwI
chowells 5y ago
Does the proposal to allow imports that only apply during template haskell evaluation improve things?
- Ericson2314 5y ago
  See my comments to https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/ghc-proposals/ghc-proposals/pull/412, where I invoke Racket frequently. It's the right sort of goal, but we have to go all the way to full phase separation to make it mean something.

btilly 5y ago

For those who wonder why monads would be like burritos, read https://blog.plover.com/prog/burritos.html https://blog.plover.com/prog/burritos.html. Though a large burrito as a joke to represent both monads and macros is kind of catering to a niche audience.

WastingMyTime89 5y ago

> Few people are excited about both monads and macros; only one person that I know comes to mind. I don’t understand what the article is trying to convey. Everyone in the PL community know about monads and macros but they are tools and people are rarely excited about tools. The article seems to have a strong Haskell user bias. For example, both using macro and monads is very common in Ocaml. JaneStreet, the company which uses Ocaml the most, uses both extensively. Ocaml provides advanced macro functionalities (called ppx rewriters) and let-binding overloading to make writing monadic code easier. There is no opposition between these two functionalities.

maxiepoo 5y ago
Exactly, Haskell's "do" notation is essentially defined as a built-in macro, so if you ever want to use "do" notation in a language that doesn't have it built-in you will need to use macros. (Let-binding overloading is essentially do notation in case that's not clear)
- tromp 5y ago
  do is more syntactic sugar for >>= (monadic bind) than macro. E.g. do s <- readLine "Enter name:" putStr $ "Hello, " ++ s reduces to readLine "Enter name:" >>= (\s -> putStr $ "Hello, " ++ s) But I agree you can use macros to implement syntactic sugar.
- marcosdumay 5y ago
  Macros are way more powerful than binding, for both the best and the worst. Yes, you can use macros to add do-notation to a language. But you can also use macros to add things like type checks and new conditional statements. You can't add those with do-notation.
- whateveracct 5y ago
  "do" is also no longer hard-coded. There are multiple language extensions that allow you to change what it desugars to, which is really cool.
avgcorrection 5y ago
> I don’t understand what the article is trying to convey. Lispers are from Mars and Haskellers are from Venus. That’s it.
isaacimagine 5y ago
As a compiler engineer, I get excited about tools. I think it's important to use mathematical foundations in a way that is both intuitive and transparent to the end user. Aside from monads and macros, OCaml remains a great example in this area because of its support for type inference and type annotations; on the surface, the code you write is mostly 'untyped,' save for at function boundaries and data definitions. Much how like monads and macros ultimately compile, so will correct typed and untyped code. I'm not sure how clear I'm being, but in essence: tools should be as lispy on the surface as possible (for ease of prototyping), while being built on haskelly* foundations (for correctness). There is no one silver bullet, it's about finding the right balance for the issue at hand: and as a tool, you should leave that decision to your end-users. *I use lisp and haskell to mirror the article, but this is true of any tool, imperative or functional, language or otherwise.

dustingetz 5y ago

macros are compilers, monads are interpreters

celeritascelery 5y ago
Trying to wrap my head around this. How are monads like interpreters?
- chalst 5y ago
  If you look at each as languages for staging computations, what you stage with macros happens before "normal" computation, so likely happens at compile time, while what you stage with monads happens after, so must be deferred to run time.
- dustingetz 5y ago
  google "monadic interpreter" One thing monad/bind can do that macros cannot is make arbitrary runtime decisions about what to do next, with runtime information. A macro is constrained by what is known statically in the AST. This is why compiled languages are far easier to optimize (it is merely algebraic rewrites of the AST) whereas dynamic languages have runtime eval.
- Tyr42 5y ago
  Lets get concrete and make a simple example State monad. You have access to an extra variable S, with getS and setS, and each of those return values of our StateMonad. Using these (and >>= aka bind) you can write something which increments the number in the state by one, yes? increment = do s <- getS setS (s+1) and this increment is a value of our StateMonad. This doesn't run on it's own though, it needs the "interpreter" to run the state monad, and put in a initial value of the state, and maybe take it out at the end. That's the way you can think of Monads as interpreters in a very rough sense. Now, you can do fancier things, where you can set up a "free monad", which is basically going to record everything into a syntax tree, and then you really have an interpreter. http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

AzzieElbab 5y ago

Macros ! Monads !! Monads via macros !!!

bjoli 5y ago

Alexis King had a talk about Hackett, a sadly abandoned, metaprogrammable haskell: https://youtu.be/5QQdI3P7MdY https://youtu.be/5QQdI3P7MdY