[plt-scheme] make-set!-transformer baffling me...

> You're using Swindle, and its playing dirty tricks behind your back.
> I'm going to explain what happens and why it is useful, so it's going
> to be verbose.  [The bottom lines: (a) I fixed it to play nicely with
> these examples, (b) still, it is probably not what you want.]

I should have known!  One more thing to remember to test for first
before writing to the list -- make sure it doesn't work in a lower
language level.  Swindle is great though.

> This means that if you're using Swindle, you could re-do the pwd
> example like this:
>
>   => (defsubst pwd (current-directory))
>   => (defsubst (set-current-directory! new) (pwd new))
>   => (defsubst (set-current-directory! new) (current-directory new))
>   => (set! pwd "/tmp")
>   => pwd
>   #<path:/tmp/>

I will remember this.  Thanks.

>
> and without the above definition you get an error.  But this is, of
> course, bogus: you defined your own expansion for (set! pwd "C:/"),
> without using a `set-current-directory!' binding.  I've just committed
> a fix that tests if the original `set!' form receives a
> `set!-transformer', and if it is then it lets it do its thing -- so
> your examples work as they do in plain MzScheme.

Thank you!  I downloaded the svn trunk and it works great!

>
> But still, I think that you're going in the wrong direction.
> Providing a simple binding for `*features*' is not difficult, and the
> common idiom is to define it as a parameter (which you can wrap with
> some syntactic sugar to make it look like a settable identifier) which
> plays nicely with threads.  Like I said in a previous post -- this
> will actually make two separate values when used in run-time code and
> in macro code.  But if you really want the CL thing, then you'll
> probably end up trying to make:
>
>   #+foo ...
>
> work if 'foo is in `*features*'.  Implementing a `#+' reader macro
> will naturally introduce yet another level, with a third instance of
> the parameter, disconnected from the other two...

What I did was define a (cond-expand feature form) syntax that checks
the *features* (defined for syntax) variable for the feature and
either returns the form or returns (void).  The reader macro #+ just
returns a corresponding cond-expand.  So far, so good from my limited
testing.

The only caveat seems to be that each module that requires
feature-expressions.ss gets its own set of features, and there has to
be a top level (require (lib "features-expressions.ss")) to install
the reader macros.  Both of these are fairly easy to work around
though.

Jay