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: 13 Aug 2002 02:39:36 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87n0rrmw1j.fsf@zagadka.ping.de> References: <20020808125641.GA23831@www> <878z3hukoz.fsf@zagadka.ping.de> <87adnwpey3.fsf@zagadka.ping.de> <873ctm7q6r.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 1029199162 19938 127.0.0.1 (13 Aug 2002 00:39:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 Aug 2002 00:39:22 +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 17ePiS-0005BK-00 for ; Tue, 13 Aug 2002 02:39:20 +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 17ePjE-0000BF-00; Mon, 12 Aug 2002 20:40:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17ePik-00007s-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 20:39:38 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17ePih-00007U-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 20:39:37 -0400 Original-Received: from dialin.speedway42.dip105.dokom.de ([195.138.42.105] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17ePig-00006x-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 20:39:34 -0400 Original-Received: (qmail 3233 invoked by uid 1000); 13 Aug 2002 00:39:36 -0000 Original-To: Matthias Koeppe In-Reply-To: Original-Lines: 158 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:1067 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1067 Matthias Koeppe 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