[plt-scheme] exception in local variable access from augmented method

From: Dimitris Vyzovitis (vyzo at media.mit.edu)
Date: Sat Dec 6 13:26:52 EST 2008

On Sat, 6 Dec 2008, Matthew Flatt wrote:

> At Sat, 6 Dec 2008 12:42:10 -0500 (EST), Dimitris Vyzovitis wrote:
>>    (define-syntax (~set! stx)
>>      (syntax-case stx ()
>>        ((_ tgt v)
>>         (and (identifier? #'tgt)
>>              (set!-transformer? (syntax-local-value #'tgt (lambda () #f))))
>>         ((set!-transformer-procedure (syntax-local-value #'tgt)) stx))
>> [...]
>> It seems the culprit here is the set! renaming breaking the transformer
>> syntax-id-rules (they match with free-identifier=?, don't they?)
> Yes, that's right. The transformer procedure is expecting a syntax
> object that matches
>    (set! id ....) ; where `set!' is free-identifier=? to the usual one
> but it's getting an object that matches
>    (~set! id ....) ; where `~set!' is not free-identifier=? to `set!'
> In other words, you're breaking a contract (that should be) on the
> procedure of a `set!-transformer'.

So what is a custom set! expander to do here? It cannot judge smudge the 
syntax to use the built-in set! by passing #'(set! tgt v), since the 
transformer may be from a context where set! is itself (the 
custom expander) and/or does a recursive expansion.

Even if the aforementioned contract is 'all set!-transformers shall 
receive #%kernel set! to denote mutator expansion', things will still 
break; the set!-transformer is passed through but then syntax-id-rules 
written with the new set! breaks in the lower layer.

> For the particular transformer procedure inside the class system, since
> the `set!' pattern doesn't match, the transformer assumes that it must
> be getting a pattern of the form `(id ....)', and so it expands to a
> procedure application.

So, why isn't this the fault of the class systems set!-transformer? It 
lifts code out of user code, so by matching the builtin set! (and not 
the context's set!) it changes the semantics of the lifted code. In a 
sense it breaks a contract by not respecting the context specific set!
[modulo the elusive 'set!-transformer contract']

-- vyzo

Posted on the users mailing list.