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: Sun, 24 Nov 2002 23:25:03 +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 1038176847 23205 80.91.224.249 (24 Nov 2002 22:27:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 24 Nov 2002 22:27:27 +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 18G5Do-00061r-00 for ; Sun, 24 Nov 2002 23:27:24 +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 18G5EX-00014h-00; Sun, 24 Nov 2002 17:28:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18G5EI-0000vJ-00 for guile-devel@gnu.org; Sun, 24 Nov 2002 17:27:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18G5EG-0000v8-00 for guile-devel@gnu.org; Sun, 24 Nov 2002 17:27:54 -0500 Original-Received: from stateless1.tiscali.cz ([213.235.135.70] helo=mail.tiscali.cz) by monty-python.gnu.org with esmtp (Exim 4.10) id 18G5EG-0000uN-00 for guile-devel@gnu.org; Sun, 24 Nov 2002 17:27:52 -0500 Original-Received: from hobitin.ucw.cz (212.11.98.17) by mail.tiscali.cz (6.0.044) id 3DC10A63004EE78B; Sun, 24 Nov 2002 23:18:17 +0100 Original-Received: from 0rfelyus by hobitin.ucw.cz with local (Exim 3.36 #1 (Debian)) id 18G5BX-0000DL-00; Sun, 24 Nov 2002 23:25:03 +0100 Original-To: Dirk Herrmann In-Reply-To: (Dirk Herrmann's message of "Sun, 24 Nov 2002 17:49:27 +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:1756 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1756 >> 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. I am sorry I have not followed all threads about mnemoization, so it is possible that my notes are a little bit irrelevant. Why I think it is good for macros to be "first class objects": > guile> define > ERROR: In procedure memoization: > ERROR: Misplaced syntactic keyword define. > ABORT: (syntax-error) Does it mean that `define' is unbound? (*) I do not think so - I guess R5RS does not allow to have macro and variable of the same name. Macros should be in the same namespace as variables are. This is what I dislike about Common Lisp - it has one namespace for functions and another for variables. Maybe this is just a programmer's taste - but in my opinion programming languages should not be designed with "what is easy to implement" idea in the mind, but rather "programming should be fun". And I do not think it is fun to add new cases users have to handle. These things I would like to be able to write in guile: (if (defined? 'my-macro) ....) (if (macro? foo) ; not possible with your modification ....) (define old-foo foo) ; also not possible (defmacro foo args (do something clever with 'old-foo args)) (module-ref (resolve-module '(guile-user)) 'define) ; returns the same value as simple "define" - but one line is correct ; another would be error. Why? Another important question - if macros were not first class, what consequences this change would have on module system and its implementation? From my point of view macros as "first class objects" and non-dynamic code expansion are two different things. If you clearly define when macros are expanded, there is no need to forbid macros to be first class objects. My advice: 1) Preserve macros as "first class objects". When somebody writes "define" or (define foo define), maybe he knows what he is doing :-) 2) Clearly define the non-dynamic macro expansion. 3) Provide macro `dynamic-expansion' - maybe something like this: (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...) 0. (*) Quick survey: STklos - define is unbound, variable `define' is possible and it is different from macro (macro and variable can coexist) SCM - same as in guile RScheme - special form, can not be referenced, can be redefined MzScheme - same as RScheme elk - same as guile mit-scheme - same as (R|Mz)Scheme bigloo - same as STklos. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel