`or' and `and' are macros, and it doesn't work to pass them as
procedure arguments.
I forget for the moment what R5RS says; I suspect the above is not
allowed, and so perhaps Guile should detect it and report an error.
The detailed reason for this is Guile's memoization - but that's not
really the main point.
If guile will continue to behave this way, then yes, reporting an error
would save some pain. As a user, I would much prefer to view it as a bug,
because I don't want to have to care whether something like (and...) is
implemented as a macro or as a procedure. This may be hopelessly naive.
I tried to find the part of R5RS that defines this behavior. Section 4.3
talks about keywords binding to macro transformers in a very different way
than it talks about variables binding to values in 4.1.1, as if it is
licensing a separate namespace, reminiscent of Lisp's function and data
namespaces (except that a single identifier may only mean one at a time).
Section 7.1.3 makes explicit that procedure calls are different from macro
uses, which are (<keyword> <datum>*), not (<operator> <operand>*),
consistent with the above. This looks to the untrained eye like a wart.
In contrast, the guile docs on Procedures and Macros talk about macros as
first class things: "when a symbol defined to this value appears as the
first symbol in an expression", which makes me think I can define a symbol
to that value, pass it around, and expect it to work as the first symbol in
an s-expression. I see that "pass it around" is never made explicit, but
it would certainly be consistent, and partly The Way Things Are. I hope
that a memoization bug won't kill this bit of beauty.
I apologise if I badly misunderstood something. I am a novice here, and
speak only as a relatively recent user, curious to learn more.
Thanks,
Grem
--
------ __@ Gregory A. Marton http://csail.mit.edu/~gremio/
--- _`\<,_ .
-- (*)/ (*) Oh Lord, give me patience... NOW!
~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~++~~~~~~~
