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. Jeronimo Pellegrini (24 Oct 2020 23:20 UTC)
Re: SRFI-212: aliasing to a *not yet* bound identifier, and modules/libraries. Marc Nieper-Wi├čkirchen (25 Oct 2020 08:10 UTC)

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

Marc Nieper-Wißkirchen <xxxxxx@gmail.com> writes:

> Hi,
>
> thanks for your interest in this SRFI.

Thank you for proposing it!

> Am So., 25. Okt. 2020 um 00:00 Uhr schrieb Jeronimo Pellegrini (via
> srfi-212 list) <xxxxxx@srfi.schemers.org>:
>>
>> 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
>
> At the moment, SRFI 212 says that the identifier that receives the
> binding will be unbound as well.

Ok, that clarifies it!

>> 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).
>
> This is a test of Chez's REPL, whose semantics differ from those of a
> top-level program. If this were part of a top-level program, you
> wouldn't be able to "set!" an unbound identifier. (Moreover, Chez
> doesn't allow to alias an unbound identifier there.)

Sure, but I could define one. And in that case, one would be a
new binding, so Chez will not answer 10. But Kawa will.
So this seems like an area where compatibility is not to be
expected anyway.

>> 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
>
> This would be no error if a global "b" was bound.

Yes, I meant when b is not bound.

>> 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?
>
> The binding of "b" at the point where the "alias" definition occurs
> counts. So if "b" is unbound there, "x" will be unbound there as well.
>
> Note that "alias" does not make "x" and "b" equivalent. It just copies
> the (lexical) binding at that point.

Right, that is clear now.

>> 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
>
> Can you give an example? I think I understand but I am not 100% sure.

(in-module acme) ;; set the current module

(define a -1)

(let ((b -2))
  (alias c a)  ;; this refers to the symbol a in module "acme", and not
               ;; anywhere else!

The same for libraries,

(define-library (acme)
  (export c)
  (begin
    (define a -1)
    ...
    (alias c a) ;; this refers to a in acme
  ))

If I import acme and then refer to c, I should get whatever a is bound
to inside acme. Right?

>> refer to "b in that module/library" -- is that the intended behavior?
>> Then, could it be made explicit in the SRFI text?
>
> I can speak explicitly of "lexical bindings" in SRFI 212 if this
> helps.

I believe it would make it more clear, yes!

Jeronimo