4 ms·

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

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.

Zababa 5y ago
Speaking about OCaml too, OCaml throws away the types after the typechecking, so in a way you could even argue that the types themselves are a form of macros over the untyped lambda form, which sounds pretty close to Lisp. The dichotomy of Lisp and Haskell is a false one. Maybe the dichotomy would be better as "static" vs "dynamic", but about the language/runtime, not the typing. For example, in Lisp, you have REPL-driven development, where you know errors will happen but you can easily correct them, while in Haskell you try to minimize the errors with the help of the compiler and once the system is done you usually have to recompile it.
- isaacimagine 5y ago
  To that end, there are type systems in some languages (turnstile in racket comes to mind) that are implemented entirely using macros. Turnstile isn't enough to model certain type systems (for reasons too complex to reasonably cover here), but it's interesting to see that types-as-macros-over-the-untyped-lambda-form has been done to a reasonable degree of success.

Zababa 5y ago

Speaking about OCaml too, OCaml throws away the types after the typechecking, so in a way you could even argue that the types themselves are a form of macros over the untyped lambda form, which sounds pretty close to Lisp. The dichotomy of Lisp and Haskell is a false one. Maybe the dichotomy would be better as "static" vs "dynamic", but about the language/runtime, not the typing. For example, in Lisp, you have REPL-driven development, where you know errors will happen but you can easily correct them, while in Haskell you try to minimize the errors with the help of the compiler and once the system is done you usually have to recompile it.

isaacimagine 5y ago
To that end, there are type systems in some languages (turnstile in racket comes to mind) that are implemented entirely using macros. Turnstile isn't enough to model certain type systems (for reasons too complex to reasonably cover here), but it's interesting to see that types-as-macros-over-the-untyped-lambda-form has been done to a reasonable degree of success.