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 23 Oct 2020 08:27 UTC

Alright. I think if we delay the finalization of SRFI 206 until then,
not much harm is done.

In fact, I would add a last-minute change, namely to amend the
`define-auxiliary-syntax` special form so that it gets a one argument
version. In that case, the second argument will be just the symbolic
name of the first argument. This is then consistent with the helper
syntax `define-auxiliary-syntax` of the poor man's solution.

Am Fr., 23. Okt. 2020 um 09:59 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> To fix the issue in Gauche, what I have now will have quite an impact on compilation speed so it may not be soon to support it on the master branch.  But I can push ahead the working branch at least to make sure my plan works.  Give me a couple of days.
>
> And yes, I'm writing a reply on the syntax system, too.
>
> --shiro
>
>
> On Thu, Oct 22, 2020 at 1:17 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Shiro, Arthur asked me whether we could finalize the specification of
>> the SRFI. I would like to ask you whether you found any issue with the
>> spec itself while you were thinking about how to implement in Gauche?
>>
>> PS Have you received my latest private mail about breaking down the
>> syntax system?
>>
>> Am Mi., 14. Okt. 2020 um 13:46 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> >
>> >
>> > On Wed, Oct 14, 2020 at 1:23 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>> >>
>> >> 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's design is restricted to avoid allocation during compilation as much as possible, for it counts as a scripting engine.  That's the reason I avoided naive "renaming" implementation.  Now that I see the issue, though, I think I can make it work.
>> >