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:34 UTC

PS I created a pull request with this addition.

Am Fr., 23. Okt. 2020 um 10:27 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> 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.
> >> >