Re: Bug in eval-string?

[Marius Vollmer <mvo@zagadka.ping.de>]

Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel