Last call for comments on SRFI 206: Auxiliary Syntax Keywords Arthur A. Gleckler (13 Oct 2020 18:57 UTC)
Re: Last call for comments on SRFI 206: Auxiliary Syntax Keywords Marc Nieper-Wißkirchen (14 Oct 2020 05:35 UTC)
Reference implemenation Shiro Kawai (14 Oct 2020 07:04 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 07:32 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 08:44 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 08:46 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 08:53 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 09:00 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 09:11 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 09:19 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 09:38 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 10:01 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 11:12 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (14 Oct 2020 11:23 UTC)
Re: Reference implemenation Shiro Kawai (14 Oct 2020 11:47 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (22 Oct 2020 11:18 UTC)
Re: Reference implemenation Shiro Kawai (23 Oct 2020 07:59 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (23 Oct 2020 08:28 UTC)
Re: Reference implemenation Marc Nieper-Wißkirchen (23 Oct 2020 08:34 UTC)

Re: Reference implemenation Marc Nieper-Wißkirchen 14 Oct 2020 11:23 UTC

Am Mi., 14. Okt. 2020 um 13:12 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> I can see it is doable; after all, if you preprocess the entire source and fully rename identifiers so that no shadowing happens, it becomes trivial.  The issue lies in the shortcut I took, that I reuse compile-time/runtime structures in place of fully abstracted identifiers; it happens that such structure for the toplevel bindings and local bindings are incompatible.

Maybe you can algorithmically rename the identifiers so that you don't
need necessarily need another table?

> (Gauche can handle the b case, where lexical bindings is introduced again "skipping" other shadowing bindings, for they're both local bindings.  Though I don't provide such means in Scheme layer (datum->syntax equivalent).)

Having datum->syntax (or some equivalent) is important, of course, if
one needs to bend hygiene in a controlled way. Generally, it has to
handle the (a) case as well, of course.

>
>
>
> On Wed, Oct 14, 2020 at 12:01 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am Mi., 14. Okt. 2020 um 11:38 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> >
>> >
>> > On Tue, Oct 13, 2020 at 11:19 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>> >>
>> >> Am Mi., 14. Okt. 2020 um 11:11 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >> >
>> >> > What I'm thinking is that define-auxiliary-syntax creates a binding in the srfi.207 module and then imports it to the current module (with the same mechanism as renaming import).
>> >>
>> >> If Gauche allows importing modules lexically locally (e.g. in place of
>> >> other definitions at the beginning of a body) that sounds like a very
>> >> good approach. If it works out, I can mention it in the implementation
>> >> section.
>> >>
>> >
>> > Oops, I haven't thought about local bindings.  Ah, it is indeed tricky.  Currently the aforementioned binding object is only for toplevel bindings, and local bindings are checked using the compiler's transient data structure.  The assumption now is that a toplevel binding and a non-toplevel binding can't be free-identifier=?.
>>
>> That's a restrictive assumption as it makes implementing other
>> syntactic extensions like the SRFI 212 aliases problematic as well.
>>
>> What is generally needed for a complete alias functionality is that
>> (a) top-level bindings can be introduced lexically and (b) outer
>> lexical bindings can be introduced again in an inner lexical scope.