[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in eval-string?
From: |
Marius Vollmer |
Subject: |
Re: Bug in eval-string? |
Date: |
13 Aug 2002 02:39:36 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Matthias Koeppe <address@hidden> writes:
> I would like to refer you to the discussion archive of SRFI-15.
Ahh, thanks. I quickly skimmed the discussion and I think I have a
slightly different view of fluid-let re concurrent execution.
I doesn't really make sense to me to say that fluid-let works/works
not with concurrent execution. It is global lexical variables that
don't work with threads, and they don't work with threads regardless
of whether they are set by fluid-let or by some other construct.
If using global variables is wrong, then using them together with
fluid-let can't make them right. If all fluid-let can affect is
lexical variables, then it is not very useful in a threaded system.
You could use it to set global variables that should not be
thread-local, or non-global lexical variables that are per-se
thread-local. These are rather untypical things, I agree, and we
should not lure people into doing them only because they are more
convenient than the correct thing.
But our fluid-let would be able to affect more than just variables.
The extended (set! (accessor ...) ...) syntax can also used with
fluid-let and with it, you can affect abstract storage locations.
When you use storage locations that are themselves thread-local, then
fluid-let will also work in a threaded environment.
The decision that must be taken correctly is how to implement your
global state, not whether to use fluid-let to twiddle it.
For us, the correct way to store thread-local data is with a fluid.
Thus, you might reason that one would use fluid-let mostly with
fluids, but we already have a device for them, which is with-fluids.
So fluid-let would be superfluous again.
But fluids are by far not the only thread-local things that one might
want to bind dynamically. You could also have some data structure
that is pointed to by some thread-local global variable and you might
want to dynamically bind a slot of this structure. Or this structure
might be shared by a group of cooperating threads and setting a field
in it would thus affect all of them.
Also, fluids are the basis for thread-local storage, but they might
not be enough. You might want to layer some notification protocol on
top of them. Say the GUI thread should be signalled when you set a
'busy' flag. You could have a 'settable funtion' "busy" that knows
where the GUI thread is and (set! (busy) #t) would signal it so that
it can change the display. Being able to say
(fluid-let (((busy) #t))
...)
looks very attractive to me (and is entirely correct because "busy" is
correct, not because fluid-let is somehow thread-safe).
> 1. If you provide an overly convenient construct named "WITH", people
> will write code (and libraries) using it for dynamic scoping,
> rather than using fluid variables with the right dynamic-scoping
> construct, WITH-FLUIDS.
I have more faith, it seems. I do think that they will see the light,
given proper documentation.
> 2. As a side note, let us see how FLUID-LET looks if you want to
> use it with real fluids:
>
> (fluid-let (((fluid-ref my-fluid) value))
> ...code...)
>
> Using WITH-FLUIDS would certainly be prettier here:
>
> (with-fluids ((my-fluid value))
> ...code...)
We can improve the former to
(fluid-let (((my-fluid) value))
...code...)
when fluids are settable directly.
> I don't think it is a good idea to introduce core syntax for a
> dynamic-scoping hack for general "settable things".
>
> I certainly don't want to see code like this:
>
> (fluid-let (((caddr l) (...))
> ((list-ref l 17) (...)))
> ...)
But when that is what it takes? I would be ware of code like that
myself, but do you think that people will start writing things like
that just because they suddenly have fluid-let? Wouldn't they rather
use eval anyway? ;)
> What "general settable things" did you have in mind?
Structure slots, for example. See above.
> The application that the original poster had (setting the
> current-module for eval-string) certainly is not an example of
> typical use.
No? The current module is a fluid, but it is not globally visible.
You have to go thru current-module and set-current-module. Would it
be better to expose the fluid or would it be better to make
current-module settable and then allow people to write
(fluid-let (((current-module) ...))
...)
I like the latter option better.
> Guile already offers something that people want to use, and it is
> called WITH-FLUIDS.
>
> I guess it should simply be advertised better. In fact, in the
> current Guile manual, fluids currently only appear in the esoteric
> chapter "Threads, Mutexes, Asyncs and Dynamic Roots", which is also
> marked as a "FIXME" chapter. (BTW, the syntax WITH-FLUIDS is missing
> there, only the procedure WITH-FLUIDS* is explained.)
Yep, good point. I'll make me a note to look into this.
> I believe we should move the discussion of fluids to a more prominent
> place of the Guile manual. They should be advertised as _the_
> construct in Guile for dealing with dynamical scope.
They are _the_ basic construct for thread-local storage. The
simulation of dynamic scoping in Scheme is the job of dynamic-wind, or
one of the syntactic-sugars for it.
> Users who really want to use the FLUID-LET hack can use SLIB. (Does
> SLIB integration work well in Guile?)
It should.
> Adding it to the core under the name WITH is a bad idea because:
>
> A. Nobody else in the Scheme community seems to call FLUID-LET
> "WITH".
To boldy go where Norman has gone before ...
> B. "WITH" is a far too generic name for something like FLUID-LET.
Hmm, but it _is_ is a very generic construct. The most generic one
that I can imagine, actually. So it should get the most unspecific
name.
> My conclusion: Adding "FLUID-LET" to the Guile core only creates
> problems, no matter whether it is added under its traditional name or
> as "WITH".
I still like it, tho...
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
- Bug in eval-string?, rm, 2002/08/08
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/08
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/09
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/09
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/09
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/10
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/12
- Re: Bug in eval-string?,
Marius Vollmer <=
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/14
- Re: Bug in eval-string?, Neil Jerram, 2002/08/19
- Re: Bug in eval-string?, Matthias Koeppe, 2002/08/20
- Re: Bug in eval-string?, Marius Vollmer, 2002/08/21
- Emacs variables (was: Bug in eval-string?), Matthias Koeppe, 2002/08/27
- Re: Emacs variables (was: Bug in eval-string?), Marius Vollmer, 2002/08/31
Re: Bug in eval-string?, Neil Jerram, 2002/08/08