Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail
From: Matthew Danish <mdan...@andrew.cmu.edu>
Newsgroups: comp.lang.lisp
Subject: Re: LISP - The Challenge of Nested Macros
Date: Mon, 2 Sep 2002 01:14:26 -0400
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 60
Message-ID: <20020902011426.Y320@meddle.res.cmu.edu>
References: <3D72EAA1.1090100@pontos.net>
NNTP-Posting-Host: mx2.andrew.cmu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: bb3.andrew.cmu.edu 1030943643 1117 128.2.10.112 (2 Sep 2002 05:14:03 GMT)
X-Complaints-To: advisor@andrew.cmu.edu
NNTP-Posting-Date: 2 Sep 2002 05:14:03 GMT
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <3D72EAA1.1090100@pontos.net>; from at_news@pontos.net on Mon, Sep 02, 2002 at 07:35:45AM +0300

On Mon, Sep 02, 2002 at 07:35:45AM +0300, ilias wrote:
> ;;; ------------------------------------------------------------
> ;;; The Challenge of Nested Macros
> ;;; ------------------------------------------------------------
> (set-syntax-from-char #\[ #\,)
> (set-syntax-from-char #\] #\Space)
> ;;; ------------------------------------------------------------
> 
> ;;; this enables the following writing-style, which clarifies
> ;;; optically the level of the macro-variables.
> ;;;  [s1-a] [s1-b]   =  ,symbol = evaluate in first pass
> ;;; [[s2-a] [s2-b] ] = ,,symbol = evaluate in second pass
> 
> (defmacro alias (short long)
>    `(defmacro [short] (&rest args)
>       `( [ '[long] [@args] ] )))
> 
[...]
> 
> any questions / corrections?
> 
> lets discuss!

Well, what I dislike about this is the usage of the ] characters.  As
you said, they can be dangerous, and I think you tripped yourself up
here.  [ '[long] [@args] ] seems to indicate that both LONG and ARGS are
coming from the same level, when in fact they aren't.  ['[long]] [@args] 
seems to indicate what you wanted better.  But I don't find this a great
advantage because it is, so to speak, a misnomer.  The , operator is
supposed to act on only one s-expression, but a syntax such as [ ... ]
would indicate that it operates on a list of s-expressions.  Defining ]
as a Space gives it a "comment-like" characteristic, but comments are
supposed to give information, not mislead (and not be superfluous, one
would hope).

Not to mention the troubles this will cause when used in conjunction
with the SQL reader syntax of the UncommonSQL package; which also uses
[]s.  That is why I think most library packages don't use fancy
reader-macro syntax---they don't want to pre-empt the user or conflict
with other libraries.  (Obviously there are exceptions to this, where
you specifically obtain the library for the syntax it provides).

I rarely write macros-defining-macros and when I do, I generally
consider it worth my while to devote extra thought to it; most certainly
enough to handle parsing ,',.  Whereas in an UncommonSQL-using program I
will often use the SQL syntax, where it saves time and offers a great
deal of additional clarity (to someone already familiar with SQL anyway).

It's fun to experiment with the reader, but overuse/abuse of it in
actual programs can lead to difficult to maintain code; particularly if
involving new developers or new libraries.  There are better places to
extend the language than the first-level syntax.

This is all just my opinion, anyway.  YMMV.

-- 
; Matthew Danish <mdan...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."