On Wed, Feb 13, 2019 at 11:06 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

Am Mi., 13. Feb. 2019 um 16:29 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:

Ok. I guess that (identifer->eqobj #'foo) is to be called by macro
transformers. In which syntactic environment does identifier->eqobj
look up the binding for #'foo to generate a key?

In the parlance of Syntax Abstraction: The syntax-case expander, (which serves as the basis of my expander), identifier->eqobj returns the label object if a matching substitution is found, or (syntax-object-expr id) (ie. the symbol) if not. No separate environment is required.

My point wasn't that it wouldn't be detectable but that the trick with
identifier-syntax/identifier->eqobj doesn't work in the general case.

The identifier-syntax / syntax-parameterize thing is a separable hack to "smooth over" the case of (fn (col) ... (with (col <other>) ...)). I'm proud of it only to the extent that I can follow what's going on - but because it produces non-intuitive behavior, I don't claim any merit for it.

Alex mentioned two advantages of raw symbols: (1) They don't need to
be exported and don't pollute the namespace. (2) We can bind the
identifiers with the same name as the state variables and can still
use the state variables.

The advantage (1) is a disadvantage when viewed from a different angle
(and the reason why we are having the discussion here). So what your
experiment tries to do is to retain advantage (2) even when state
variables are represented by identifiers and not by raw symbols

The current design tries to have it both ways -- literal identifier-matching at compile time and run-time matching on symbols when the former fails. So, while (with! ((foo 'bar)) ...) may call foo's setter function directly, (fn (foo) (with! ((foo 'bar)) ...) will produce code that searches for foo's setter function at runtime. These differing semantics depending on context are worrisome.