Andy Wingo writes:
> Hi Julian,
>
> Just to add to the melee, I have been thinking hard about this too.
> Somehow output produced by a macro must have its free identifiers scoped
> in the module that was current when the macro was defined.
I've been reaching that conclusion too. (For others fol
Hi Julian,
Just to add to the melee, I have been thinking hard about this too.
Somehow output produced by a macro must have its free identifiers scoped
in the module that was current when the macro was defined.
This could mean that syntax objects need a new field, and that output
should be serial
Julian Graham writes:
> This does strike me as a serious problem (and it's a spanner in the
> works for implementing R6RS libraries). In effect, isn't the bug
> saying that Guile's syncase macros aren't totally hygienic? That is,
> in my example, if you provide your own binding for `foo-functio
Andreas Rottmann writes:
> Nothing, this is a deficiency in Guile:
> https://savannah.gnu.org/bugs/?20941. I wonder why it is marked as
> "invalid", though.
Regardless of how it's marked, I'm still hoping to get to this soon.
Neil
This does strike me as a serious problem (and it's a spanner in the
works for implementing R6RS libraries). In effect, isn't the bug
saying that Guile's syncase macros aren't totally hygienic? That is,
in my example, if you provide your own binding for `foo-function' in
the REPL environment, then
Julian Graham writes:
> Hi Guilers,
>
> Alright, I've been banging my head against this for several weeks now
> and only just had the time to sit down and research this: If you use a
> symbol in an `(ice-9 syncase)' macro definition that's bound in the
> lexical closure in which that definition l
Hi Guilers,
Alright, I've been banging my head against this for several weeks now
and only just had the time to sit down and research this: If you use a
symbol in an `(ice-9 syncase)' macro definition that's bound in the
lexical closure in which that definition lives, then that binding
should be t
