From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Re: Bug in eval-string? Date: 21 Aug 2002 21:26:12 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <878z30t3mz.fsf@zagadka.ping.de> References: <20020808125641.GA23831@www> <878z3hukoz.fsf@zagadka.ping.de> <87adnwpey3.fsf@zagadka.ping.de> <873ctm7q6r.fsf@zagadka.ping.de> <87n0rrmw1j.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1029957971 5491 127.0.0.1 (21 Aug 2002 19:26:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2002 19:26:11 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17hb7H-0001Q4-00 for ; Wed, 21 Aug 2002 21:26:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hb8L-0004oj-00; Wed, 21 Aug 2002 15:27:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hb7R-0004mO-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:26:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hb7K-0004m3-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:26:16 -0400 Original-Received: from dialin.speedway43.dip252.dokom.de ([195.138.43.252] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17hb7K-0004lm-00 for guile-devel@gnu.org; Wed, 21 Aug 2002 15:26:10 -0400 Original-Received: (qmail 6803 invoked by uid 1000); 21 Aug 2002 19:26:12 -0000 Original-To: Matthias Koeppe In-Reply-To: Original-Lines: 113 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1132 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1132 Matthias Koeppe writes: > Marius Vollmer 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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel