[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] variable datums with syncase transformer
From: |
Neil Jerram |
Subject: |
Re: [patch] variable datums with syncase transformer |
Date: |
Wed, 05 Mar 2008 20:55:33 +0000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Note that `@' and `@@' rely on an interesting property of the evaluator:
> you type `(@ (guile) car)', `@' returns a *variable*, but what you get
> is a *procedure*, because in the meantime, the evaluator automagically
> performed a `variable-ref'. This is not very elegant in my opinion.
However, I think it means that if the variable is then changed, the
code that included the (@ ...) expression will get the new value next
time it is executed.
This means that `(@ module identifier)' acts like a plain old
`identifier', in the sense that it gives you a location - whose value
may change over time - rather than the fixed value of the identifier
at the time the code was first executed.
I think that's a feature, and it's probable that someone somewhere is
relying on it.
> With that in mind, I propose instead the following patch, which also
> fixes your problem AFAICS:
>
> --- /home/ludo/src/guile/1.8/guile-core/ice-9/boot-9.scm.~1.356.2.10.~
> 2007-09-01 19:11:00.000000000 +0200
> +++ /home/ludo/src/guile/1.8/guile-core/ice-9/boot-9.scm 2008-03-05
> 17:25:15.000000000 +0100
> @@ -2988,7 +2988,7 @@
> (let ((var (module-variable (resolve-interface mod-name) var-name)))
> (if (not var)
> (error "no such public variable" (list '@ mod-name var-name)))
> - var))
> + (variable-ref var)))
>
> ;; The '@@' macro is like '@' but it can also access bindings that
> ;; have not been explicitely exported.
> @@ -2997,7 +2997,7 @@
> (let ((var (module-variable (resolve-module mod-name) var-name)))
> (if (not var)
> (error "no such variable" (list '@@ mod-name var-name)))
> - var))
> + (variable-ref var)))
If I've understood it correctly, I think this patch would change
existing behaviour, by returning a fixed value rather than a location.
Could we not look at fixing (ice-9 syncase) instead, so that it
understands variables?
Regards,
Neil