11–20 of 25 posts
Earlier quoted context omitted.
One reason I've heard is that sometimes you actually want those collisions (I haven't come across a good example though - anyone know of one?). For me the reason is just that defmacro is easier to read.
here's one: (defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))
Earlier quoted context omitted.
One reason I've heard is that sometimes you actually want those collisions (I haven't come across a good example though - anyone know of one?). For me the reason is just that defmacro is easier to read.
One example is the magical introduction of special variables. Here's "aif", implemented in PLT Scheme: (require (lib "defmacro.ss")) (define-macro (aif a b c) `(let ((it ,a)) (if it ,b ,c))) (aif (* 10 10) (+ it 1) 'oops) ==> 101 The "aif" form makes it so you don't have to create a temporary variable name first -- the temp var is just assumed to be named "it". If you're thinking, "whatever, I don't need that" you ar…
Earlier quoted context omitted.
One reason I've heard is that sometimes you actually want those collisions (I haven't come across a good example though - anyone know of one?). For me the reason is just that defmacro is easier to read.
here's one: (defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))
(cond ((assoc 'key collection)
=> (lambda (it) (do-something-with it)))
(else
(alternative)))
(aif it (assoc 'key collection)
(do-something-with it)
(alternative))
I'm a bit of a reformed macrologist; if I get an idea for a cool macro, I try to see how far I can take a non-macrotic version and compare that to what the syntactically-sugared version would be like. Most of the time, I wind up not bothering with a macro. I put macros in the same category as EVAL: If you think you need to use a macro, think again.
Earlier quoted context omitted.
One reason I've heard is that sometimes you actually want those collisions (I haven't come across a good example though - anyone know of one?). For me the reason is just that defmacro is easier to read.
here's one: (defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))
Earlier quoted context omitted.
here's one: (defmacro aif (test then &optional else) `(let ((it ,test)) (if it ,then ,else)))
In Scheme, the cases where one would use anaphoric IF can be handled using a COND clause with a "=>": (cond ((assoc 'key collection) => (lambda (it) (do-something-with it))) (else (alternative))) Alternatively, if you really wanted to create an AIF macro, you could use SYNTAX-RULES to create something that sugared up the above thusly: (aif it (assoc 'key collection) (do-something-with it) (alternative)) Or you could,…
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z...
Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.
Macros produce kickass code: http://neverfriday.com/blog/?p=10#more-10 If I didn't create a string-case= macro, I would have to write the final expression over and over again. With multiple string-case matches I would have to write string=? many many times: (cond ((or (string=? "hello" my-string) (string=? "world" my-string)) (print "match"))) To do that with the string-case= macro: (string-case= my-string (("hello"…
(cond ((or (string=? "hello" my-string)
(string=? "world" my-string))
(print "match")))
(string-case= my-string
(("hello" "world") (print "match")))
Earlier quoted context omitted.
In Scheme, the cases where one would use anaphoric IF can be handled using a COND clause with a "=>": (cond ((assoc 'key collection) => (lambda (it) (do-something-with it))) (else (alternative))) Alternatively, if you really wanted to create an AIF macro, you could use SYNTAX-RULES to create something that sugared up the above thusly: (aif it (assoc 'key collection) (do-something-with it) (alternative)) Or you could,…
You are right about cond, but don't forget that cond and other Scheme syntax can be implemented as hygienic macros: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z... Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.
I should have been more detailed and noted that on the "by all means use it" vs. "if you think you need it, think again" continuum, EVAL requires IMO more justification than a macro. The source of my concern over macros is that when designing them, care needs to be taken to clearly communicate their semantics, which is best done IMO by following the established conventions of the language and whatever other macros the user is expected to be familiar with.
Earlier quoted context omitted.
You are right about cond, but don't forget that cond and other Scheme syntax can be implemented as hygienic macros: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z... Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.
I thought a lot of Scheme implementations define IF in terms of COND. Is there some reason you're pointing this out? I should have been more detailed and noted that on the "by all means use it" vs. "if you think you need it, think again" continuum, EVAL requires IMO more justification than a macro. The source of my concern over macros is that when designing them, care needs to be taken to clearly communicate their se…
Earlier quoted context omitted.
I thought a lot of Scheme implementations define IF in terms of COND. Is there some reason you're pointing this out? I should have been more detailed and noted that on the "by all means use it" vs. "if you think you need it, think again" continuum, EVAL requires IMO more justification than a macro. The source of my concern over macros is that when designing them, care needs to be taken to clearly communicate their se…
You pointed out one could achieve much the same result as the aif macro by using cond. I wanted to point out that cond itself is an example of the power of macros.
Someone could give a "trust the programmer" argument for making unhygienic macros available in a language, but that nostrum is problematic because there are two programmers: the macro writer and the macro user. It's harder than you think to write a macro using DEFMACRO that always behaves the way a user might expect it to behave, and as a user of a macro, you need to wonder how hard the macro writer worked to protect you -- something that I don't like as a fan of black boxes.
Earlier quoted context omitted.
You are right about cond, but don't forget that cond and other Scheme syntax can be implemented as hygienic macros: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z... Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.
I thought a lot of Scheme implementations define IF in terms of COND. Is there some reason you're pointing this out? I should have been more detailed and noted that on the "by all means use it" vs. "if you think you need it, think again" continuum, EVAL requires IMO more justification than a macro. The source of my concern over macros is that when designing them, care needs to be taken to clearly communicate their se…