Composable continuations and reset/shift Shiro Kawai (18 Nov 2022 19:07 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (18 Nov 2022 19:27 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (18 Nov 2022 19:29 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (18 Nov 2022 19:51 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (18 Nov 2022 19:57 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (18 Nov 2022 21:12 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (18 Nov 2022 21:28 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Nov 2022 00:04 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (19 Nov 2022 06:47 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Nov 2022 07:04 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (19 Nov 2022 07:07 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Nov 2022 07:15 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (19 Nov 2022 07:48 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Nov 2022 09:00 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (19 Nov 2022 10:51 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Nov 2022 23:00 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (20 Nov 2022 07:24 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (20 Nov 2022 12:17 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (02 Feb 2023 20:02 UTC)
Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen (18 Feb 2023 14:34 UTC)
Re: Composable continuations and reset/shift Shiro Kawai (19 Feb 2023 01:10 UTC)

Re: Composable continuations and reset/shift Marc Nieper-Wißkirchen 18 Feb 2023 14:34 UTC

As no one has complained so far, I have decided to go with `temporarily'.

Am Do., 2. Feb. 2023 um 21:02 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> What about "temporarily" instead of the quite general "with"?
>
> So, for example:
>
> (temporarily
>     ((current-directory "/home/marc/scheme"))
>   <some code>)
>
> Marc
>
> Am So., 20. Nov. 2022 um 13:17 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
> >
> > Ah, OK.  Gauche's original parameterize works like 'with' in the sense that it can also accep a procedure with zero or one arguments.  It still behaves differently if a parameter object has a non-idempotent converter, but such usage is rare, and for Gauche users it can be said that 'with' works mostly like the original 'parameterize'.  However, thinking of RnRS parameterize, 'with' is certainly a different construct.
> >
> > Now I see 'with' as a generalization of 'with-*' style procedures that temporarily alter dynamic state.  It encapsulates the typical pattern of using dynamic-wind to manage the dynamic states.  If I frame it that way, the name 'with' fits well.
> >
> > The way srfi-226 currently worded looks like 'with' is another variation of 'parameterize', with a bonus of allowing parameter-like objects.  How about introducting 'with' with the statement like this: Sometimes dynamic state can be managed by a procedure that works like a parameter; when it is called with no arguments it returns the current value, and wien it is called with one argument, val, it makes val as the current value.  Combined with dynamic-wind, the state can be changed in a certain dynmaic scope.  The 'with' form codifies that pattern. [...] Unlike parameterize, restoration of value is always done by calling parameter-like objects, allowing parameter-like objects to manipulate external state as well as the associated value.'
> >
> >
> >
> >
> >
> > On Sat, Nov 19, 2022 at 9:24 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >>
> >> "with" is not meant as a legacy mechanism because parameterize
> >> changed.  As the small language has no delimited continuations, SRFI
> >> 226's parameterize is backward-compatible to the small language's.
> >>
> >> "With", on the other hand, is not a form of parameterize because it
> >> behaves differently when the converter procedure of parameter objects
> >> is not idempotent.  Use cases for "with" are when parameter-like
> >> objects need to do something non-trivial when the dynamic extent of
> >> the "with" form is left.  For example, there could be a parameter-like
> >> object "current-directory", which changes the current directory on the
> >> OS level in parallel.  This cannot be done with parameterize and
> >> ordinary parameter objects.
> >>
> >> In some sense, "with" is more general, but has no tail context
> >> guarantee (and behaves differently wrt delimited continuations).
> >>
> >> Am So., 20. Nov. 2022 um 00:00 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
> >> >
> >> >
> >> >
> >> > On Sat, Nov 19, 2022 at 12:51 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >> >>
> >> >>
> >> >> Chez Scheme's "with" is only used in a deprecated macro facility
> >> >> ("extend-syntax").  I think, at least for the purpose of Chez, it is
> >> >> safe to reuse the identifier.
> >> >>
> >> >> The identifier "with" is undoubtedly quite general, but so are "let"
> >> >> or "receive".  I would be glad if "parameterize" had a shorter or less
> >> >> complicated name.
> >> >
> >> >
> >> > I see.  Actually, if 'with' is used for dynamic binding (current srfi-226's parameterize), it is a reasonable name compared with let.
> >> > In srfi-226, however, I got an impression that 'parameterize' is given to the true dynamic bindings, while 'with' is a kind of pseudo mechanism, mostly to accommodate the existing code that uses parameter-like objects in place of parameters.  Yet, it has a shorter name and encourages users to use it over 'parameterize'.
> >> >
> >> > I thought it'd be ok before I noticed the subtle difference regarding shift/reset.  I'm for providing a dynamic-wind based mechanism for the backward compatibility of legacy 'parameterize', but I'm afraid that naming it 'with' gives an impression that it is a more general, higher-level construct.  (It is more general in a sense that it accepts parameter-like objets, but the semantics differ.)
> >> >
> >> > In other words: I'm going to tell Gauche users that the new 'parameterize' is not compatible with legacy 'parameterize', it will work most of the time but may behave differently in complicated cases; if you need a full compatibility you have to replace 'parameterize' for  'with'.  I'm afraid that the users then think "ok, then I'm going to use 'with' for all dynamic bindings without worrying about compatibility, and it has a shorter name so it's even better."  It's not desirable situation.
> >> >
> >> >
> >> >
> >> >