4 ms·

This article helps explain the how, but doesn't really cover the why. Coming from a functional programming perspective (Ruby, Elixir, Clojure [yes I know]), I d

This article helps explain the how, but doesn't really cover the why. Coming from a functional programming perspective (Ruby, Elixir, Clojure [yes I know]), I don't see where macros become useful or anything more than a curiosity outside of a couple situations: 1. Implementing a DSL, which is its own beast and is more often a bad idea than not; or 2. Actually, I can't think of anything else. Granted, I might be spoiled by modern conveniences already implemented in Clojure, such as cond. It's just hard to see what macros can give me that I can't accomplish with functions. If code is data, then aren't functions, which operate on data, already what we're looking for?

nickpsecurity 10y ago
"Implementing a DSL, which is its own beast and is more often a bad idea than not" Those using languages supporting that disagree. Let's assume the DSL is syntax embedded in a language like LISP or Haskell so you don't get stuck in the DSL. Essentially, there's not much difference between a DSL and library in terms of what's required to use it. You still learn what you type to achieve a certain effect. You still can use rest of language. Main difference is both (a) matches the problem domain more closely and (b) limits you to expressing just what you need to solve the problem. These are why the BASIC-oriented 4GL's were quite successful. LISP, too, given it's also easy to process. REBOL & recently Red take it further. Kay et al are working wonders where a whole system is expressed in readable code that's a tiny fraction of code in a non-DSL system. The combo of easy-to-modify language and DSL toolkit (esp Racket or Red) also leads to methodologies like this one from sklogic where it's easy to do components with a series of DSL's that are thrown together & many pieces autogenerated: "The method is very simple: * describe the problem in plain English (maybe with some diagrams) * iterate it a few times until you have a syntax you think is unambiguous enough * strip this syntax from all the sugar you just introduced in order to define an AST * find DSLs in your toolbox that are potentially close to the one you're building and cherry-pick the necessary language components from them * write a sequence of very simple transforms that would lower your source AST into a combination of the parts of the ASTs of the target DSLs of your choice * Done. An efficient DSL compiler is ready, with a language designed as closely to your current view of the problem domain as possible. * If you later find that your DSL is inadequate and your understanding of the domain was insufficient, than just start over again, this entire process is so cheap and simple that it does not really matter." It also helps with verification. You can define DSL's for specific types of OS components or app software that make correct-by-construction easier. CertiKOS is doing that: http://flint.cs.yale.edu/certikos/publications/ctos.pdf http://flint.cs.yale.edu/certikos/publications/ctos.pdf http://flint.cs.yale.edu/certikos/certikos.html http://flint.cs.yale.edu/certikos/certikos.html

nickpsecurity 10y ago

"Implementing a DSL, which is its own beast and is more often a bad idea than not" Those using languages supporting that disagree. Let's assume the DSL is syntax embedded in a language like LISP or Haskell so you don't get stuck in the DSL. Essentially, there's not much difference between a DSL and library in terms of what's required to use it. You still learn what you type to achieve a certain effect. You still can use rest of language. Main difference is both (a) matches the problem domain more closely and (b) limits you to expressing just what you need to solve the problem. These are why the BASIC-oriented 4GL's were quite successful. LISP, too, given it's also easy to process. REBOL & recently Red take it further. Kay et al are working wonders where a whole system is expressed in readable code that's a tiny fraction of code in a non-DSL system. The combo of easy-to-modify language and DSL toolkit (esp Racket or Red) also leads to methodologies like this one from sklogic where it's easy to do components with a series of DSL's that are thrown together & many pieces autogenerated: "The method is very simple: * describe the problem in plain English (maybe with some diagrams) * iterate it a few times until you have a syntax you think is unambiguous enough * strip this syntax from all the sugar you just introduced in order to define an AST * find DSLs in your toolbox that are potentially close to the one you're building and cherry-pick the necessary language components from them * write a sequence of very simple transforms that would lower your source AST into a combination of the parts of the ASTs of the target DSLs of your choice * Done. An efficient DSL compiler is ready, with a language designed as closely to your current view of the problem domain as possible. * If you later find that your DSL is inadequate and your understanding of the domain was insufficient, than just start over again, this entire process is so cheap and simple that it does not really matter." It also helps with verification. You can define DSL's for specific types of OS components or app software that make correct-by-construction easier. CertiKOS is doing that: http://flint.cs.yale.edu/certikos/publications/ctos.pdf http://flint.cs.yale.edu/certikos/publications/ctos.pdf http://flint.cs.yale.edu/certikos/certikos.html http://flint.cs.yale.edu/certikos/certikos.html