Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 17:13 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 20:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 20:53 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (22 Apr 2020 21:29 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (22 Apr 2020 23:58 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:36 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (22 Apr 2020 21:43 UTC)
Re: Review of SRFI 170 through 3.2 I/O John Cowan (23 Apr 2020 03:38 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:02 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 07:05 UTC)
Re: Review of SRFI 170 through 3.2 I/O Göran Weinholt (23 Apr 2020 10:54 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:09 UTC)
Per-thread umask Lassi Kortela (23 Apr 2020 11:30 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:44 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 11:47 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 11:59 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 15:03 UTC)
Re: Per-thread umask Marc Feeley (23 Apr 2020 15:20 UTC)
Re: Per-thread umask Lassi Kortela (23 Apr 2020 16:02 UTC)
Re: Per-thread umask John Cowan (23 Apr 2020 16:03 UTC)
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 11:14 UTC)
current directory and openat() et al Lassi Kortela (23 Apr 2020 11:27 UTC)
Re: current directory and openat() et al Marc Feeley (23 Apr 2020 13:56 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley (23 Apr 2020 11:33 UTC)
Normalizing the current directory Lassi Kortela (23 Apr 2020 11:39 UTC)
Re: Normalizing the current directory Marc Feeley (23 Apr 2020 11:55 UTC)
Re: Normalizing the current directory Lassi Kortela (23 Apr 2020 12:10 UTC)
Per-thread working directory and umask proposal John Cowan (23 Apr 2020 14:13 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 14:16 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 16:07 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 16:14 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 16:25 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 17:26 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (23 Apr 2020 17:55 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (23 Apr 2020 18:55 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 20:12 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (23 Apr 2020 22:17 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 08:43 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 11:27 UTC)
Re: Per-thread working directory and umask proposal Lassi Kortela (24 Apr 2020 11:37 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (24 Apr 2020 12:22 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (24 Apr 2020 12:28 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (26 Apr 2020 09:19 UTC)
Re: Per-thread working directory and umask proposal John Cowan (27 Apr 2020 22:46 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (27 Apr 2020 23:42 UTC)
Re: Per-thread working directory and umask proposal John Cowan (28 Apr 2020 00:42 UTC)
Re: Per-thread working directory and umask proposal Shiro Kawai (28 Apr 2020 00:56 UTC)
os-working-directory Lassi Kortela (29 Apr 2020 09:23 UTC)
Re: os-working-directory Duy Nguyen (29 Apr 2020 09:28 UTC)
current-umask Lassi Kortela (29 Apr 2020 09:43 UTC)
Windows Lassi Kortela (29 Apr 2020 09:47 UTC)
Re: Windows Lassi Kortela (29 Apr 2020 09:49 UTC)
Re: Windows John Cowan (29 Apr 2020 14:53 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 13:14 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 13:25 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:31 UTC)
Re: current-umask Marc Feeley (29 Apr 2020 13:45 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 14:12 UTC)
Re: current-umask hga@xxxxxx (29 Apr 2020 16:21 UTC)
Re: current-umask Lassi Kortela (29 Apr 2020 16:44 UTC)
Re: current-umask John Cowan (30 Apr 2020 04:02 UTC)
Re: os-working-directory John Cowan (30 Apr 2020 02:49 UTC)
Re: os-working-directory Lassi Kortela (30 Apr 2020 06:12 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:19 UTC)
Re: os-working-directory Sebastien Marie (30 Apr 2020 07:53 UTC)
Should the SRFI mandate current-directory per thread? Lassi Kortela (30 Apr 2020 12:14 UTC)
Re: Should the SRFI mandate current-directory per thread? Sebastien Marie (30 Apr 2020 17:00 UTC)
Re: Per-thread working directory and umask proposal hga@xxxxxx (28 Apr 2020 01:03 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (28 Apr 2020 01:42 UTC)
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen (30 Apr 2020 07:11 UTC)
Re: Per-thread working directory and umask proposal Marc Feeley (30 Apr 2020 11:33 UTC)
Re: Per-thread working directory and umask proposal John Cowan (23 Apr 2020 18:38 UTC)
Re: Review of SRFI 170 through 3.2 I/O Sebastien Marie (23 Apr 2020 13:32 UTC)
Definition of working directory Lassi Kortela (23 Apr 2020 13:51 UTC)
Re: Definition of working directory Marc Feeley (23 Apr 2020 14:07 UTC)
Re: Definition of working directory Sebastien Marie (23 Apr 2020 15:31 UTC)
Re: Review of SRFI 170 through 3.2 I/O Marc Nieper-Wißkirchen (23 Apr 2020 15:24 UTC)
Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:38 UTC)
Re: Separate high-level and low-level APIs Marc Nieper-Wißkirchen (23 Apr 2020 15:44 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 15:48 UTC)
Re: Separate high-level and low-level APIs hga@xxxxxx (23 Apr 2020 16:19 UTC)
Re: Separate high-level and low-level APIs Lassi Kortela (23 Apr 2020 16:42 UTC)
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx (23 Apr 2020 15:41 UTC)

Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 23 Apr 2020 18:55 UTC

Am Do., 23. Apr. 2020 um 19:55 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:

[...]

> You could simply add a (dynamic-env-copy thunk) procedure that runs thunk with all the dynamic environment bindings copied, which could be useful anyway as a general purpose operation.

Indeed, this would provide a way from (c) to (b); I'm wondering
whether this can be implemented in O(1) (or at least not in O(n) where
n is the size of the dynamic environment).

> Your argument is similar to saying that we could get rid of “set!” altogether by just doing (define var (box val)) whenever we want a mutable variable.  Then get rid of set-car! similarly… to just have box and set-box!.  Very MLish!  I view that as taking something away from my language, not the other way around!

This is actually the situation with the parameter objects of
R7RS-small where mutation is not standardized; so all you can do is to
put boxes into the parameters. I would rather be able to set the
parameter objects directly. (Apart from this being more direct and
more Scheme-like, it would work on `current-input-port', etc., as
well.)

It probably depends on what would be used more, the (b) semantics or
the (c) semantics. If the (b) semantics are at least not incorrect for
most use cases, there's at least a way through the box thing to get to
the (c) type of semantics.

> In any case, mutation of parameter objects should not be viewed as good style, similarly to the use of “set!”.  But this does not mean I want to remove it from the language because in some cases it is the right thing to use.
>
> If parameter bindings are automatically copied when a thread is started it prevents that new thread from changing the parent’s parameter bindings easily, but it is still possible to do so with continuations in a contrived way…  by having the child call a continuation created in the parent (because the dynamic environment is captured by the continuation) and arranging for control to come back to the child (with another continuation).  So this means copying the dynamic bindings on thread creation makes a simple thing (parameter object mutation) very complex to achieve, but not impossible… so you don’t get a “reliable parameter independence” property.

A nice trick! Reliable parameter indepence wasn't my goal, though.
Just true thread locals when used in a standard way.

> > With respect to the performance issues, I have no simple answer yet.
> > It would suffice to spawn parameters on demand, which would just make
> > the mutation more costly, I think.
>
> I’m not sure I follow.  You mean a kind of “copy-on-write”?  I’d like to see the implementation of that and compare the performance to the case where there is no copy involved.

Yes, something like a "copy-on-write". But I have to be careful what I
say because I haven't yet thought about an implementation of that. It
could possibly be implemented with a continuation mark. If one tries
to modify a parameter across that mark, a copy could be modified
instead. If this is possible, one could take the (c) semantics and
instead of adding a potentially very costly `dynamic-env-copy' (whose
semantics are not at all clear to me), calling the thunk with the
continuation mark set would suffice.