3 ms·
just deferred evaluation of it's arguments You get that for free with a lazy language. You can write any sort of control flow mechanism to your heart's content
by chongli 7y ago
just deferred evaluation of it's arguments
You get that for free with a lazy language. You can write any sort of control flow mechanism to your heart's content and it's just a function in Haskell. People have written all manner of fancy coroutine systems, continuations, etc, without the need for macros.
moving that transformation to compile time
Haskell, gives you a great deal of control over this. Some of the best libraries make use of this functionality for things like stream fusion. Additionally, Haskell can lift constants to the top level so they're only evaluated once, on demand. This gives you free memoization without increasing code size (as you would if you precomputed a large constant).
- ddragon 7y agoI wasn't trying to argue that this was the only or even the best way of doing it, just why it's advantageous that you separate runtime and compile time functions, especially in languages with eager evaluation. The advantage of macros is just that they are simple to understand and use (for most you basically just have to understand tree data types, or just cons, especially for CL style macros), to implement (since every (?) language already have an AST representation, and particularly powerful in Lisp for obvious reasons) and the language doesn't even really have to support them in their normal syntax (fully separating runtime programming syntax and compile time programming syntax if they want). And for that they give a lot of power by allowing easy language extensions, syntactic sugar and powerful optimizations.