Re: Strange behavior in a catch with (and) and (or)

[Jim Blandy <jimb at red-bean dot com>]

This is really cool.  Mikael knows the evaluator much better than I
do, so I'm interested to see what he says, but I think this is a
fundamental bug in Guile's evaluator.  Check this out:

    guile> (define (run-thunk t) (t))
    guile> (run-thunk +)
    0
    guile> (run-thunk *)
    1
    guile> (run-thunk and)
    #t
    guile> (run-thunk *)
    #t
    guile> (define (run-thunk t) (t))
    guile> (run-thunk *)
    1
    guile> (run-thunk cond)
    standard input:57:23: In procedure cond in expression (t):
    standard input:57:23: bad or missing clauses
    ABORT: (misc-error)
    guile> 

Here's my understanding, which may well be wrong:

In Guile, an identifier gets bound to syntax the same way it gets
bound to any other value.  Thus:

    guile> cond
    #<macro 40143740>
    guile> (let ((x cond)) x)
    #<macro 40143740>
    guile> (let ((x cond)) (x (#f 0) (#t 1)))
    1
    guile> (let ((x quote)) (x (howdy there kids)))
    (howdy there kids)
    guile> 

This kind of thing should be a syntax error --- uses of `quote' like
the one above are not variable references, since quote is not a
variable, according to R5RS 3.1:

    An identifier that names a type of syntax is called a `syntactic
    keyword' and is said to be `bound' to that syntax.  An identifier
    that names a location is called a `variable' and is said to be
    `bound' to that location.

quote is a syntactic keyword, not a variable.

The reason the null-case function breaks after you apply it to `and'
is that, the first time Guile applies certain macros, it rewrites its
internal representation of expression according to the macro's
expansion, so it won't need to expand it again later.  The result is
that, after evaluating (run-thunk and) once, that subexpression of
run-thunk's definition has effectively been replaced with #t.

Ugly ugly ugly.