From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Matthias Koeppe Newsgroups: gmane.lisp.guile.devel Subject: Re: Bug in eval-string? Date: Mon, 12 Aug 2002 20:20:30 +0200 Sender: guile-devel-admin@gnu.org Message-ID: 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1029176421 21293 127.0.0.1 (12 Aug 2002 18:20:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 12 Aug 2002 18:20:21 +0000 (UTC) Cc: rm@fabula.de, 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 17eJne-0005XC-00 for ; Mon, 12 Aug 2002 20:20:18 +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 17eJoS-0007px-00; Mon, 12 Aug 2002 14:21:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17eJo3-0007p2-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 14:20:43 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17eJnv-0007oX-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 14:20:43 -0400 Original-Received: from saturn.math.uni-magdeburg.de ([141.44.75.38]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17eJnv-0007nn-00 for guile-devel@gnu.org; Mon, 12 Aug 2002 14:20:35 -0400 Original-Received: from beta.math.uni-magdeburg.de (beta [141.44.75.78]) by saturn.math.uni-magdeburg.de (8.11.6/8.11.6) with ESMTP id g7CIKVX19694; Mon, 12 Aug 2002 20:20:31 +0200 (MET DST) Original-Received: (from mkoeppe@localhost) by beta.math.uni-magdeburg.de (8.10.2+Sun/8.10.2) id g7CIKUu13717; Mon, 12 Aug 2002 20:20:30 +0200 (MEST) X-Authentication-Warning: beta.math.uni-magdeburg.de: mkoeppe set sender to mkoeppe@mail.math.uni-magdeburg.de using -f Original-To: Marius Vollmer In-Reply-To: <873ctm7q6r.fsf@zagadka.ping.de> (Marius Vollmer's message of "10 Aug 2002 16:18:20 +0200") Original-Lines: 131 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.80 (sparc-sun-solaris2.7) 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:1065 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1065 Marius Vollmer writes: > Matthias Koeppe writes: > >> > But "with" is such a nice name compared to "fluid-let"! ;)=20 >>=20 >> The name is *too nice* for something like FLUID-LET. Remember, it >> uses DYNAMIC-WIND and lots of SET!s. It is inefficient if CALL/CC >> is used. > > Hmm, what is wrong with 'dynamic-wind' and 'set!'? I would like to refer you to the discussion archive of SRFI-15. http://srfi.schemers.org/srfi-15/mail-archive/maillist.html >> It won't work in a threaded environment. > > Really? Whether or not the dynamic context established by "with" or > "fluid-let" is local to the current thread or gloabal to all depends > on the nature of the 'variable' that you are setting. It could be a > fluid, or it could be an ordinray global variable. 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. All this code will not be re-usable in a threaded environment. 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...) >> > I'd say that fluid-let should be in the core. Opinions? >>=20 >> I'd say, we should rather make SLIB integration smoother, and/or >> provide a SRFI-15 implementation (despite its withdrawn status).=20=20 >> >> Putting it in the core won't be a good idea IMHO. >>=20 >> 1) It creates confusion because Guile knows real fluid variables. >> FLUID-LET has "fluid" in its name but has no connection to >> fluids. > > That's actually one reason why I like "with". I will comment on the name "WITH" at the end of this message. >> 2) WITH-FLUIDS is much cleaner than FLUID-LET. People should use >> WITH-FLUIDS if they want (threadsafe) dynamic scoping. > > But with-fluids is only for fluids, not for general dynamic scoping of > settable things. I don't think it is a good idea to introduce core syntax for a dynamic-scoping hack for general "settable things".=20=20 I certainly don't want to see code like this: (fluid-let (((caddr l) (...)) ((list-ref l 17) (...))) ...) What "general settable things" did you have in mind? The application that the original poster had (setting the current-module for eval-string) certainly is not an example of typical use. > [...] > So I don't see how offering "fluid-let" or "with" is dangerous. It > might not be 'pure', but it offers something that people want to use. > having to use dynamic-wind explicitely is cumbersome and error prone > compared to fluid-let, in my view. It's not mainly about "purity", it's about code re-usability for a threaded environment.=20=20 Guile already offers something that people want to use, and it is called WITH-FLUIDS.=20=20 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.) 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. * * * Users who really want to use the FLUID-LET hack can use SLIB. (Does SLIB integration work well in Guile?) Adding FLUID-LET to the core would create confusion because of Guile's fluid variables, as I mentioned. 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".=20 B. "WITH" is a far too generic name for something like FLUID-LET.=20 C. It does not fit at all into the Scheme naming scheme. We have WITH-INPUT-FROM-FILE, WITH-OUTPUT-TO-FILE, and some other WITH-... procedures, but their name always says with "what" the passed thunk (or body) is called. If you wanted "WITH..." syntax for FLUID-LET, it would be something like WITH-DYNAMICALLY-WOUND-VALUES. D. Because of reason 1 above. 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". (Having it in the core certainly won't help in any way to make Emacs switch to Guile, BTW.) Regards, --=20 Matthias K=F6ppe -- http://www.math.uni-magdeburg.de/~mkoeppe _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel