Re: Bug in eval-string?

[Marius Vollmer]

Matthias Koeppe <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
>
> > 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.
> 
> I think it is already a very bad idea to think about temporarily
> mutating slots of data structures as "binding".  See also below.

Then you can't think about 'with-fluids' as performing 'bindings' as
well.  That is OK, and a better term would maybe be 'letting', or
'setting temporarily'.  We should'nt quarrel over names too much, tho.

> The good thing about fluids is that they are regular Scheme values.
> This means that we can put them not only in global variables but also
> in lexical variables and other data structures.  The WITH-FLUIDS
> syntax also deals with those fluids, not only with fluids stored in
> global variables.

Yes, this is a good point, one that can be used against using
variables in general.  fluid-let might be bad in the sense that it
allows people to work with things besides fluids and doesn't force
them to use fluids exclusively.  But that is a weak argument in my
view since I don't think that fluids are the only things that should
be temporarily set.  Especially things that are layered on top of
fluids.

> > [...]
> > 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).
> 
> It doesn't look attractive to me.  I am afraid people will simulate
> control structures via getters and setters.  BUSY is the first step
> into this direction.  This will lead to a C++-ish overloading mess,
> where you never know what an operation will do unless you know exactly
> the type of the objects involved.

I don't think it is that bad.  The behavior of fluid-let is not
changed by the things that are being 'let'.  Of course you need to
know what 'busy' does.

> The Scheme way would be to make a new control procedure
> 
>     (with-being-busy THUNK)
> 
> or/and a macro.

How would you implement with-being-busy?  Something like fluid-let
would sure come in handy.  Also, in addition to with-being-busy you
would still need a getter to be able to find out whether you are
currently busy.

Factoring this into an abstract state variable that can be read and
written, and a general construct that can temporarily set any abstract
variable looks good to me, still.  You only need to learn fluid-let
once.

> >> What "general settable things" did you have in mind?
> >
> > Structure slots, for example.  See above.
> 
> I was afraid you would say that.  I think it is very bad style to make
> temporary mutations on data structures.  It's not getting better if
> you mutate named slots rather than mutating the CADDR as in the
> example code I gave above. 

This depends entirely on what you want to do.  There are algorithms
that are most efficient when you modify data structures (as opposed to
coding them in a functional way).  Some modifications might be
temporarily (i.e., the 'dancing links' of Knuth).

> The only reason why I would be interested in a Guile-based
> implementation of Emacs is the hope for a clean, thread-safe Lisp
> engine, which would allow for a multi-threaded Emacs.  We can't reach
> this goal if we copy all the inherently single-threaded stuff
> (swapping in and out values, as with FLUID-LET) from the Emacs Lisp
> engine into Guile.

I still don't see how fluid-let ruins multi-threaded applications.
The current buffer needs to be thread-local, but code like

   (fluid-let ((case-fold-search #f))
      ...)

would still need to be used.  We can debate whether that should rather
be

   (fluid-let (((buffer-local-value case-fold-search) #f))
      ...)

or

   (fluid-let (((case-fold-search) #f))
      ...)

or something different, but the point to discuss is the exposition of
Emacs variables to Scheme, not whether we should be able to set them
temporarily.  A general fluid-let construct can only help with
experimenting.  Only allowing an unchanged with-fluids constrains the
options too much, too early, I'd say.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405