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 <shiro.ka...@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
> <marc.nie...@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
>> <shiro.ka...@gmail.com>:
>> >
>> >
>> >
>> > On Sat, Nov 19, 2022 at 12:51 AM Marc Nieper-Wißkirchen
>> > <marc.nie...@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.
>> >
>> >
>> >
>> >
