Am Mi., 13. Feb. 2019 um 18:07 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.

A macro transformer that calls identifier->eqobj on an identifier
#'foo may insert code such that the resulting code after the expansion
causes #'foo to have more wraps than #'foo had when it was inspected
by the macro transformer.

This may not be problematic for the current experiment, but it seems
to prevent a clear semantics for identifier->eqobj.

How would identifier->eqobj be implemented on a system that is based
on syntactic closures?

[...]

> 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.

That's indeed a bit strange.

In some sense, your experiment is trying to make Scheme into a kind of
LISP-2: Everything would work if there were two namespaces, one for
variables, keywords, pattern variables, etc. and another one for state
variables. While not without merits, this is probably the reason why
it leads to surprising semantics for a Scheme programmer.

What do you think of my proposal with the unquote syntax? It has the
advantage of being backward compatible with SRFI 159, but has the
disadvantage that it may encourage the use of raw symbols for state
variables.

Marc

P.S.: I am wondering whether we should continue this discussion
outside of the SRFI-159 mailing list (or under a new heading) so the
attention is not distracted away from the original question.