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

[...]

>> > 2) the implementation must provide a function (identifier->eqobj #'id) which returns a unique key associated with the identifier's binding (or non-binding).   Two identifiers produce the same eq? key IFF then they match hygienically, and are free-identifier=?.    These keys are the runtime keys used to store values in the state.   All state-variables are bound.
>>
>> What you call a "function" has to be syntax, doesn't it?
>
>
> No.   But the #' thing certainly needs to be.  So, yes, if it were written (identifier->eqobj foo), then it would have to be syntax.

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?

[...]

>> However, this won't work in a robust way (without surprises):
>>
>> (fn (col)
>>   (let loop ((col col) (foo 0))
>>     (if (zero? col)
>>         (each foo (fn (col) ...))
>>         (loop (- col 1) (+ foo col)))))
>
>
> That's the motivation for the strong error detection.   The (fn (col) on the 4th line, when expanding will detect that col is not a state-variable and produce a syntax error.

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.

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.
However, the example above shows that we don't have advantage (2) in
the general case, even with your code.

[...]

>> identifier->eqobj seems to be much more problematic.
>
>
> No doubt.   Just an experiment to explore the space and trigger more ideas.

While I'm still not convinced that SRFI 159 is a good use case for
your experiments (and that the semantics would be rather surprising
compared with the rest of the standard and the SRFIs as SRFI 39),
exploring whether identifier->eqobj (or something equivalent) can be
added in a sound way to Scheme's syntax system and whether it can be
implemented by expanders based on syntactic closures and expanders
based on the marks and substitutions algorithm looks definitely worth
exploring to me.

Marc