4 ms·
Sure, you can do it that way -- but isn't it ugly? Isn't it harder to read? One thing I recently did that required a lot of macros was writing a unit test fram
by zck 13y ago
Sure, you can do it that way -- but isn't it ugly? Isn't it harder to read?
One thing I recently did that required a lot of macros was writing a unit test framework for Arc, the Lisp Hacker News is written in. (framework, with examples, here: https://bitbucket.org/zck/unit-test.arc https://bitbucket.org/zck/unit-test.arc) So to create a suite, you write:
(suite math
this-will-pass (assert-same 4 (+ 2 2))
this-will-fail (assert-same 3 (+ 2 2)))
Like stopwatch, instead of passing a lambda that runs the body of the unit test, it just lets you put the body in. Why? In c-like languages, you don't write an if statement this way:
if((val % 2 == 0), lambda (): { return true; }, lambda (): { return false; })
Isn't it easier to write:
if(val %2 == 0) {
return true;
} else {
return false;
}
So if using lambdas isn't good for if, why is it good for stopwatch?
Also, none of math, this-will-pass, or this-will-fail are predefined in the language, or even by my framework. You don't have to use strings, as you might otherwise:
(suite "math"
"this-will-pass" (assert-same 4 (+ 2 2))
"this-will-fail" (assert-same 3 (+ 2 2)))
Why might this be useful? Well, when you're writing a function:
int abs(int val){ return val<0 ? -val : val; }
Wouldn't you find it annoying to write:
int "abs" (int "val"){ return val<0 ? -val : val ; }
So Lisp lets you incorporate your code as part of the language, and doesn't force you (as much) to hammer your thoughts into the built-in structures of it.
- ufo 13y ago> Sure, you can do it that way -- but isn't it ugly? Isn't it harder to read? Its the old tradeoff between using long-winded existing constructs or paying a complexity cost and forcing the reader to learn a new abstraction or DSL. But I like your example. I imagine the extra lambda or string-quoting noise starts getting significant when you have lots of tiny test cases.
- zck 13y ago>Its the old tradeoff between using long-winded existing constructs or paying a complexity cost and forcing the reader to learn a new abstraction or DSL. Yeah, that's definitely true. When macros are used to add to the language, you're acting, by definition, as a language designer. You can make good or bad choices. I normally think it's good to eliminate boilerplate (e.g., the lambda calls in the examples) and to simplify things (passing bare symbols instead of strings). To my eye, the new coder actually has to learn less than if they had to remember to wrap with lambdas, or use strings: you code just like other parts of the language. And that's a win. However, bad choices with macros can definitely be made. Some people consider the loop macro ugly, because it's a hairy ball of special cases with new syntax.