From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: tomas@fabula.de Newsgroups: gmane.lisp.guile.devel Subject: Re: memoization and error messages Date: Tue, 26 Nov 2002 11:42:38 +0100 Sender: guile-devel-admin@gnu.org Message-ID: <20021126104238.GA6739@www> References: <20021124125745.GA31397@www> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1038306003 19665 80.91.224.249 (26 Nov 2002 10:20:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 26 Nov 2002 10:20:03 +0000 (UTC) Cc: tomas@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 18Gcox-00056X-00 for ; Tue, 26 Nov 2002 11:19:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Gcq6-0002JF-00; Tue, 26 Nov 2002 05:21:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18GcpC-0001Qk-00 for guile-devel@gnu.org; Tue, 26 Nov 2002 05:20:14 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Gcp8-0001LO-00 for guile-devel@gnu.org; Tue, 26 Nov 2002 05:20:12 -0500 Original-Received: from [217.22.192.104] (helo=www.elogos.de) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Gcp7-0001LG-00 for guile-devel@gnu.org; Tue, 26 Nov 2002 05:20:09 -0500 Original-Received: by www.elogos.de (Postfix, from userid 5002) id 055F014054; Tue, 26 Nov 2002 11:42:38 +0100 (CET) Original-To: Dirk Herrmann Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i 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:1757 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1757 On Sun, Nov 24, 2002 at 05:49:27PM +0100, Dirk Herrmann wrote: > On Sun, 24 Nov 2002 tomas@fabula.de wrote: > > > That means that macros aren't anymore `first class objects'? What > > consequences does this have for meta-programming? > > I don't know. Can you be a little more specific about what you want to > accomplish that you can only accomplish with macros as first-class objects > (or rather said "accomplish cleanly")? If so, please provide code > examples that show your approaches. Sorry to be so unspecific. One could for example imagine doing code analysis by re-binding `interesting' symbols and then `running' the code. Or, rendering of SXML by evalling an S-expression: different stylesheets would correspond to different environments. In a more general setting: the environment is the `interpretation function' of a class of S-expressions. Consider this style of programming: (case keyword ((foo) (do-foo)) ((bar) (do-bar)) ((quux) (do-quux)) ...) versus (let ((foo do-foo) (bar do-bar) (quux do-quux) ...) (eval keyword)) (yes, I've used eval ;-) The nice art of the second approach is that you can carry around `canned' environments and decide last minute what interpretation so use. The point now is one of finer control. If the second approach means that *everything* is open (eval as a totally opaque ``memoization barrier''), then the second variant loses big time. The ideal (I gues a non-attainable one) would be to let the compiler to find out. Usually I won't rebind car or let, or define. But sometimes I might have a reason to (and then I'd be willing to pay the high price. I'd have to anyway). > [rambling on] > It may make sense to point out the following: Separate in-advance > memoization brings the possibility to speed up evaluation, it allows to > store pre-compiled code and thus speed up loading time, and it is a great > way to clean up guile's internals and achieve better R5RS conformance. Yes, you are right -- I'm just (weakly) arguing against a clear either-or, that's why I sometimes talk about partial evaluation (although I have the impression that the whole monster might be too fat for our purposes ;) > However, it does impose some restrictions: Guile will be stricter with > respect to certain R5RS demands. Further, macro expansion is no longer as > dynamic as it was before. That is, the point of time when expansion is > handled is known in advance - this was not the case before. The last one is one very important point, I think. Whatever the implementation is, macro-expansion time should be clear (at least so clear that the semantics of non-pathological programs is clear, or rather that it is possible to decide whan a program is non-pathological). > But, for those who depend on dynamic code expansion (i. e. re-expansion of > code whenever a macro changes) there is always eval. People say they > don't like eval. But, they like dynamic code expansion, huh? And, what > are their problems with eval? Performance considerations? Isn't it > better to improve speed and cleanliness for 99,9% of the cases, where > dynamic re-expansion is not necessary, instead of inhibiting performance > improvements in order to be able to avoid using eval? It's not to avoid it. It's just trying to give the compiler the possibility of being `smarter' than just to rely on the user's judgement (especially important when you face automatically generated code: the `user' might be especially dumb in those cases ;-) > IMO, instead of depending on dynamic code expansion (a, well, not-so-clean > and performance-inhibiting implementation detail of guile), the use of > eval is better, because it is standard and it makes parts of the code > obvious where you depend on dynamic re-expansion. > [rambling off] > > Well, don't feel angry for my ramblings above, I was a little bit carried > away when I wrote it :-) I actually very much appreciate all kinds of > comments with respect to separation of memoization and execution. I have > learned a lot from your and other people's comments. Hey, come on. I do learn a lot from your ramblings. Please *do* ramble on. > Friendly greetings > Dirk _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel