Re: [Chicken-users] bug using syntax-case in load'ed files

[felix winkelmann]

On 10/23/06, Alejandro Forero Cuervo <address@hidden> wrote:
> This is just to report a bug I found in the syntax-case egg.  I hope
> it is not a misundertanding on my case.
>
> If I run csi and eval
>
>     (use html-stream syntax-case srfi-40)
>     (stream-cons "foo" stream-null)
>
> I get
>
>     Error: unbound variable: stream-cons .
>
> I tested under Chicken 2.5.  Interestingly, if I change the order and
> put syntax-case first (or if I remove html-stream), the second
> expression evaluates successfully.

This is related to what Andreas reported (the macro-expander gets
replaced while compiling and loading separate files), so let me
put the basic problem and the way to approach this in different
words:

Chicken supports two different languages: one is a fairly R5RS-
compliant Scheme and uses a low-level "defmacro"-style macro system.
Another is a somewhat more R5RS-compliant Scheme with
syntax-case and a version of "define-macro" that is built on top
of syntax-case (Actually there are many more languages and macro-expanders, but
lets consider them at another time).

So I recommend to chose whatever language suits you best
and stick to it, throughout all your source-files, preferably keeping
it out of the source completely (by compiling/interpreting with "-R
syntax-case").
It is very error-prone to mix high-level and low-level macros and
loading code at run-time or using "include" in the wrong place can
lead to very confusing behaviour.
An exception to the one-language-for-all-rule is when you want to use
functionality that is only available in one macro system (say, sxml-match).
In that case, put the use into a separate compilation unit and thus
avoid mixing up the compile/expansion-time environment. Scheme systems
like PLT or Scheme48 have funky module systems to handle this, chicken
does it more like C does, by using batch-compiled compilation units.

Sorry, I have no quick-and-easy fix for this.


cheers,
felix

--
http://galinha.ucpel.tche.br:8081/blog/blog.ssp