SRFI 212: Aliases Arthur A. Gleckler (22 Sep 2020 19:00 UTC)
Re: SRFI 212: Aliases Per Bothner (22 Sep 2020 19:53 UTC)
Re: SRFI 212: Aliases Marc Nieper-Wißkirchen (22 Sep 2020 20:26 UTC)
Re: SRFI 212: Aliases Jim Rees (23 Sep 2020 13:15 UTC)
Re: SRFI 212: Aliases Jim Rees (23 Sep 2020 13:16 UTC)
Re: SRFI 212: Aliases Marc Nieper-Wißkirchen (23 Sep 2020 13:23 UTC)
Re: SRFI 212: Aliases Jim Rees (23 Sep 2020 13:53 UTC)
Re: SRFI 212: Aliases Marc Nieper-Wißkirchen (23 Sep 2020 14:03 UTC)
Re: SRFI 212: Aliases Jim Rees (25 Sep 2020 02:38 UTC)
Re: SRFI 212: Aliases Marc Nieper-Wißkirchen (25 Sep 2020 05:58 UTC)
Re: SRFI 212: Aliases Jim Rees (25 Sep 2020 18:10 UTC)

Re: SRFI 212: Aliases Marc Nieper-Wißkirchen 22 Sep 2020 20:25 UTC

Thank you very much for your comments, Per! I wasn't aware of Kawa's
implementation, but I will mention it in the next draft.

Initially, I also thought renaming Chez's `alias' to `define-alias'
because it is allowed where a definition is allowed, but then decided
against it because in case the right-hand side is undefined, it does
not really define anything. Moreover, every other definition actually
introduces new bindings, which `alias' doesn't, so dropped the idea of
the `define-' prefix. But Kawa surely has some renaming facility to be
able to support SRFI 212.

Am Di., 22. Sept. 2020 um 21:53 Uhr schrieb Per Bothner <xxxxxx@bothner.com>:

> For the record, the ones that don't work are:
>
> (1)
>     (let ((y +))
>        (define-alias x y)
>        (define y *)
>          (free-identifier=? #'x #'y))   ⟹ #f rather than error
>
> This could be an extension because of more liberal Kawa ordering rules;
> I haven't looked into it.

As the R7RS phrase "it is an error" allows an implementation to do
anything, returning `#f' is fine. I haven't tested this example with
Chez, but chances are that it also returns `#f' there. Only a few
syntax expanders actually produce errors when a keyword is redefined
whose meaning has already been used in the same block of definitions.

> (2)
>   (alias inject unquote)
>      `(list (inject (+ 1 2)) 4)
> ==> (list (inject (+ 1 2)) 4) rather than (list 3 4)
>
> This may be just a missing followAliases call in the implementation.

I hope so because `inject' and `unquote' have become
`free-identifier=?' and that should be test `quasiquote' uses.

> (3)
>     (syntax-case #'pear ()
>        (pvar
>         (let* ()
>           (alias fruit pvar)
>           (syntax->datum #'(a fruit)))))
> /tmp/x.scm:34:30: reference to pattern variable pvar outside syntax template
> /tmp/x.scm:34:10: invalid argument to location

Does the error happen at the alias statement? If so, it seems that the
test of referencing a pattern variable outside a syntax template is
too eager. It should only raise an error when the binding is actually
used, which could also happen when `fruit' is referenced outside a
syntax template.