SRFI-212: aliasing to a *not yet* bound identifier, and modules/libraries. Jeronimo Pellegrini (24 Oct 2020 22:00 UTC)
Re: SRFI-212: aliasing to a *not yet* bound identifier, and modules/libraries. Marc Nieper-Wi├čkirchen (24 Oct 2020 22:26 UTC)
Re: SRFI-212: aliasing to a *not yet* bound identifier, and modules/libraries. Marc Nieper-Wi├čkirchen (25 Oct 2020 08:10 UTC)

SRFI-212: aliasing to a *not yet* bound identifier, and modules/libraries. Jeronimo Pellegrini 24 Oct 2020 22:00 UTC

Hello,

I was hoping to use aliases in a proposal for a rewrite of STklos'
macro system, and I'd like to know what would be the expected behavior
when I make an alias to an identifier that is not yet bound. Both Chez
and Kawa seem to allow this, although Kawa issues a warning:

Kawa:

#|kawa:1|# (define-alias one two)
/dev/tty:1:19: warning - no declaration seen for two
#|kawa:2|#  (set! one 10)
#|kawa:3|# two
10

Chez:

> (import (chezscheme))
> (alias one two)
> (set! one 10)
> two
10

I actually think this is useful (at least for me).

Would it be a good idea to add this to the spec, or could it perhaps
be a problem?

For example,

(let ((a 10))
  (alias x b)
  (let ((b 20))
    x))          ;; error! x is an alias to global b

However -- if between the second and third line on that code, for
example, a thread sets a binding for global b, then I would expect
that the code would return the new value of b, since x *is* a binding
to "whatever binding b has at the moment in the global environment".
Or is it not the idea?

Also, I suppose that if (alias x b) is done inside a module or library,
and the alias is not to a locally created identifier, the binding should
refer to "b in that module/library" -- is that the intended behavior?
Then, could it be made explicit in the SRFI text?

Thank you!
Jeronimo