> On Apr 8, 2016, at 7:10 AM, Norman Gray <nor...@astro.gla.ac.uk> wrote:
>>> I'd like to propose that there are three disciplined uses of macros: >>> >>> 1. data sublanguages: I can write simple looking expressions and >>> [...] >>> >>> 2. binding constructs: I can introduce new binding constructs with >>> [...] >>> >>> 3. evaluation reordering: I can introduce constructs that delay/postpone >>> [...] >>> [Note: In Haskell, you don't need that one.] > > This is a seriously naive question, because I have only trivial experience > with Haskell (and by extension other lazy languages), but aren't each of > these things that you can do with a lazy language? > > If I can control when an expression is evaluated, then I can obviously do (3), For "evaluation reordering," it means that with macros, you could take a strict language and make it lazy, *or* take a lazy language and make it strict. Or you could probably do other, weirder things that I can't think of right now. Haskell has forms for making specific things strict, but it's not the default. Whatever the default is, you can change it with macros. So in Haskell this category of macros would still exist, but `delay` wouldn't be one of them. I think macros like `do` that that insert monad threading would also be in this category? > but supposing I can also control the environment within which it's evaluated, > can't I also do (2) In a language with static scope, no, I don't think so. In racket, haskell, and most other languages, you always know at compile time what identifiers are bound. You could never have an identifier that could be bound at runtime, because the compiler would have seen that identifier and raised an error, at compile time. It's because of this compile-time knowledge that programmers can look at a program without running it, and still understand it. And also it's because of this that DrRacket can look at a program without running it, but still draw check-syntax arrows, or safely rename identifiers, jump to a definition, or lookup documentation. Since macros that define new binding constructs are normally defined in terms of existing binding constructs, the programmer still has all of this knowledge at compile time, and DrRacket can still provide all those tools. Because of that, both programmers and DrRacket can understand programs. If this could change at runtime, most of this would go away. But to use laziness to create new binding constructs without macros, that's what you would have to do. Alex Knauth -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
