I’m used to lazy evaluation from Haskell, and find myself getting irritated with eager-by-default languages now that I’ve used lazy evaluation properly. This is actually quite damaging, as the other languages I use mainly make lazily evaluating stuff very awkward, normally involving the rolling out of custom iterators and so forth. So just by acquiring some knowledge, I’ve actually made myself less productive in my original languages. Sigh.
But I hear that AST macros offer another clean way of doing the same thing. I’ve often heard statements like ‘Lazy evaluation makes macros redundant’ and vice-versa, mostly from sparring Lisp and Haskell communities.
I’ve dabbled with macros in various Lisp variants. They just seemed like a really organized way of copy and pasting chunks of code around to be handled at compile time. They certainly weren’t the holy grail that Lispers like to think it is. But that’s almost certainly because I can’t use them properly. Of course, having the macro system work on the same core data structure that the language itself is assembled with is really useful, but it’s still basically an organized way of copy-and-pasting code around. I acknowledge that basing a macro system on the same AST as the language that allows full runtime alteration is powerful.
What I want to know is, is how can macros be used to concisely and succinctly do what lazy-evaluation does? If I want to process a file line by line without slurping up the whole thing, I just return a list that’s had a line-reading routine mapped over it. It’s the perfect example of DWIM (do what I mean). I don’t even have to think about it.
I clearly don’t get macros. I’ve used them and not been particularly impressed given the hype. So there’s something I’m missing that I’m not getting by reading over documentation online. Can someone explain all of this to me?
Lazy evaluation can substitute for certain uses of macros (those which delay evaluation to create control constructs) but the converse isn’t really true. You can use macros to make delayed evaluation constructs more transparent — see SRFI 41 (Streams) for an example of how: http://download.plt-scheme.org/doc/4.1.5/html/srfi-std/srfi-41/srfi-41.html
On top of this, you could write your own lazy IO primitives as well.
In my experience, however, pervasively lazy code in a strict language tends to introduce an overhead as compared to pervasively lazy code in a runtime designed to efficiently support it from the start — which, mind you, is an implementation issue really.