Eli Barzilay wrote:
> Four minutes ago, Neil Toronto wrote:
>> I think we should retire this truthiness business, replace cond's
>> `=>' with something that lets you easily nest conds (I have a
>> proposal ready for this, and it is awesome),
>> (a) how is this related? (b) `=>' is not used to nest `cond's.
You use it to have the same computed value available in both the
test-expr and the then-body, which would otherwise require nested `cond's.
I got inspired by the #:when form in `for' loops that flattens nesting,
and wrote a `cond*' macro that allows this instead:
(cond* [... some stuff ...]
#:with (define m ...)
[(... something about m ...) (... something using m ...)]
... more things referring to m ...)
It's more general, since it doesn't require encoding the condition you
want to test as a truthiness value. Also, the `define' doesn't have to
be a `define' - it can be any legal expression.
It's flattened most of my numeric code. Numeric code often computes and
reacts to easily computable, approximate conditions first. When the easy
tests are inconclusive, it computes and reacts to progressively more
precise conditions that are more expensive.
>> and stop using truthiness idioms. It's obfuscating, it's hard on
>> newcomers, it makes reasoning about return values difficult, and
>> it's very last-century.
>> (And tail-call-{optimization,elimination} is very this-century...)
I've never heard this, and I am curious. How does truthiness in `and'
and `or' preserve proper tail calls?
Neil T