From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Daniel Skarda <0rfelyus@ucw.cz> Newsgroups: gmane.lisp.guile.devel Subject: Re: memoization and error messages Date: Mon, 02 Dec 2002 21:45:16 +0100 Sender: guile-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1038861953 28153 80.91.224.249 (2 Dec 2002 20:45:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Dec 2002 20:45:53 +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 18IxRq-0007JA-00 for ; Mon, 02 Dec 2002 21:45:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18IxTB-00055u-00; Mon, 02 Dec 2002 15:47:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18IxSz-0004ha-00 for guile-devel@gnu.org; Mon, 02 Dec 2002 15:46:57 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18IxSw-0004eu-00 for guile-devel@gnu.org; Mon, 02 Dec 2002 15:46:56 -0500 Original-Received: from stateless2.tiscali.cz ([213.235.135.71] helo=mail.tiscali.cz) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18IxSr-0004Ta-00 for guile-devel@gnu.org; Mon, 02 Dec 2002 15:46:54 -0500 Original-Received: from hobitin.ucw.cz (212.90.239.123) by mail.tiscali.cz (6.0.044) id 3DDE8B9E001872DA; Mon, 2 Dec 2002 21:36:26 +0100 Original-Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 18IxRM-0000ID-00; Mon, 02 Dec 2002 21:45:16 +0100 Original-To: Dirk Herrmann In-Reply-To: (Dirk Herrmann's message of "Thu, 28 Nov 2002 19:02:49 +0100 (CET)") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) 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:1774 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1774 > R5RS does allow macro and variable of the same name - in a sense. For > example: First I must say I have to add "read R5RS more carefully" to my TODO list :) As my quick survey revealed, this macro part of R5RS is not consistently implemented in most scheme implementations - in my opinion it shows that there is something bad in R5RS. > (defmacro foo <...>) ;; after this line, foo is a syntactic keyword > (foo some-args ...) ;; foo will be expanded. > (define foo ) ;; after this line, foo is bound to a location > (foo some-args ...) ;; foo will not be expanded. > (define (bar) foo) ;; bar will refer to foo's binding > (defmacro foo <...>) ;; after this line, foo is a syntactic keyword, but: > ;; bar will still refer to foo's _variable_ binding And what would do (define (bar) foo) here (after second defmacro foo)? Return variable binding or macro? I rather would vote for simplicity, than for adhering to obscure feature we find in standard (feature that most people do not care to implement in "standard" way). >> (if (macro? foo) ; not possible with your modification >> ....) > > True, but if you would quote foo, this could still be checked. No! If you quote foo, it is symbol. Current Guile: (cond ((symbol? x) ...) ((procedure? x) ...) ((macro? x) ....) this code after your proposal would be: (cond ((procedure? x) ...) ((and (symbol? x) (macro? x module)) ... ((symbol? x) ...) ; now users has to remember that this line must be written ; after macro? line..... What an obscure feature... do you feel that you simplified programming in Guile? >> (define old-foo foo) ; also not possible > > But > (defmacro old-foo args `(foo ,@args)) > does the trick. The only problem that we currently have, is that defmacro > is not able to keep track of the module the definition of foo came from. > For a temporary workaround, see my email about preparation for hygienic > macro expansion. > >> (defmacro foo args >> (do something clever with 'old-foo args)) > > As long as you don't mix up definitions of foo from different modules, > this would also work with my example above. No, it would not. (defmacro foo args blah blah ,,,) (defmacro old-foo args `(foo ,@args)) (defmacro foo args (blah blah `(old-foo ,@args))) ... would cause infinite expansion. >> (module-ref (resolve-module '(guile-user)) 'define) >> >> ; returns the same value as simple "define" - but one line is correct >> ; another would be error. Why? > > Who says that one line is correct and one is an error? sure: > guile> define > _would_be_ an error if my local version of eval became official. Today's > guile still accepts such a line, as it also accepts the module-ref code. > If my changes became official, the behaviour of module-ref with respect to > syntactic keywords might also change. Well, IMHO (module-ref foo bar) should NOT be an error because "bar" is defined in "foo" module (no matter if it is macro or not....). I like about Guile (or scheme) that it lets you to touch everything in one simple way. The "simple way" I understand as the way without many rule exceptions one has to handle. I think something like: less exceptions in code => shorter code => few bugs => shorter debugging time => faster development. "One way" - in guile all values can be "stored in variables" and all variables are "equal" - why macros should be different? Why do you want to invent new way for storing values? >> (defmacro dynamic-expansion code >> `(local-eval '(begin ,@code) (the-environment))) >> >> so it would be easy to identify the code with dynamic macro expansion. (I >> do not know why people use dynamic macro expansion, but I guess it is handy >> during macro debugging...) > > Yes, this could be done, although I recommend that we get rid of > local-eval. I do not care about how "dynamic-expansion" would be implemented. My implementation with "local-eval" was just an example - such "dynamic-expansion" works even with current guile eval and it clearly marks "odd" code. > Maybe we are just discussing the wrong examples here: The major issue > about first class macros is that you can define them at run-time. That > is, you could at run time change the set of syntactic keywords and have > the same code code expanded in different ways depending on the set of > macro definitions defined at run-time. Do you have any situations like > this in mind? No. I do not defend dynamic macro expansion, rather I was speaking for "the right to touch everything" (including macros - that's what I understand as "macro is first class"). I understand that non-dynamical macro evaluation is vital for Guile speed. But I can not understand why it is impossible to achieve non-dynamical macro expansion without loosing "first class macros". How "(is-a? define )" or "(class-of let)" lowers the performance and why you want to prohibit it? Is there any other advantage than guile> define signals an error? In my oppinion it is easy to catch such errors - but what would our tax? We would complicate other code and make it less immune to possible bugs. 0. ps: My small wish for Guile: macrolet (or let-macro - something like let-syntax). How hard it would be to write macrolet with your eval? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel