let-fluid problem shivers@xxxxxx (14 Nov 1999 04:07 UTC)
Re: let-fluid problem Per Bothner (16 Nov 1999 07:13 UTC)
Re: let-fluid problem shivers@xxxxxx (19 Nov 1999 22:31 UTC)
Re: let-fluid problem Per Bothner (20 Nov 1999 06:26 UTC)
Re: let-fluid problem Lars Thomas Hansen (16 Nov 1999 17:13 UTC)
Re: let-fluid problem Per Bothner (16 Nov 1999 17:24 UTC)
Re: let-fluid problem Lars Thomas Hansen (16 Nov 1999 18:57 UTC)

Re: let-fluid problem Lars Thomas Hansen 16 Nov 1999 17:13 UTC

Olin Shivers writes:

>I would like to argue against any DYNAMIC-WIND + SET! sort of
>"fluid variable" system. The problem is threads.

Brad Lucier writes:

>To follow up on Olin's e-mail, I prefer dynamic-define, dynamic-ref,
>dynamic-set!, and dynamic-let as in Gambit-C, rather than fluid-let and
>friends.  In particular, I don't like having to
>have variables with dynamic scope visible lexically in the context where
>they're used.  Here is the relevant section from the gambit-c manual:

Per Bothner writes:

>A more fundamental problem with the fluid-let specification is that it
>does not support a thread model that may have true parallel threads.

All of these objections are reasonable, but they do not speak to the
purpose of this particular SRFI.  The purpose of the SRFI is only to
codify an already existing practice that has slight variations across
implementations (namely, some protect the bindings with DYNAMIC-WIND and
some don't).  I submitted it because I find myself using FLUID-LET in
some of my programs, because it is a convenient mechanism for
temporarily and reliably overriding the values of global variables.

I hope my FLUID-LET SRFI does not become the last word on dynamic
binding in Scheme.  Other implementers and programmers will have other
opinions and needs, and will adopt mechanisms suitable to those needs.
Some of those mechanism may even use the same syntax for a conflicting
purpose, and I don't see any great damage in that.  Some of those
mechanisms may even be submitted as SRFIs; I would certainly hope so.

(More generally, I do not think that the SRFI process is useful only for
designing new stuff; it is useful also for collecting old stuff that is
known to be useful, even in limited contexts.)

--lars