[racket] member et al.

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