Path: utzoo!attcan!uunet!snorkelwacker!ai-lab!ai.mit.edu!tmb
From: tmb@ai.mit.edu (Thomas M. Breuel)
Newsgroups: comp.lang.lisp
Subject: Re: Virtues of Lisp syntax (a tangent on macros and Scheme)
Message-ID: <1990Sep20.170311@ai.mit.edu>
Date: 20 Sep 90 21:03:11 GMT
References: <10466@life.ai.mit.edu> <6217@castle.ed.ac.uk> <10722@life.ai.mit.edu> <20501@well.sf.ca.us> <1990Sep18.180829.8801@hellgate.utah.edu> <12812@ists.ists.ca>
Sender: news@ai.mit.edu
Reply-To: tmb@ai.mit.edu
Organization: MIT Artificial Intelligence Lab
Lines: 73

In article <12812@ists.ists.ca>, mike@ists.ists.ca (Mike Clarkson) writes:
|> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:
|> >It's not the macros that the application programmers write themselves
|> >that cause problems [...], it's the macros that are a part of
|> >the language that cause trouble.
|> 
|> When I look at the kind of code environment I write Common Lisp code in
|> these days, I feel that most application programmers make very heavy use
|> of macro packages, some of which are getting very large.  How may files
|> that you have start with
|> 
|> (require 'pcl)
|> (require 'clx)
|> (require 'loop)
|> 
|> etc.  This doesn't invalidate Jeff Jacobs or Tim Moore's arguments, but it
|> leads me to an observation.  As we go on as lisp programmers (in
Common Lisp),
|> we are building higher and higher levels of abstraction, relying on
|> larger and larger programming bases above the underlying language.
|> [...]
|> I dearly love Scheme as a language, but because of the lack of
|> standardization [of macros] it's difficult to find the abstracting
packages 
|> on which we increasingly rely.  I feel that the approach of
encouraging
|> implementations to continue to experiment with different solutions
has
|> had its merits (first class continuations as an example), but the
time
|> has come to solidify the language and build upwards on the very real
|> accomplishments of the base language. 

The use of macros to implement PCL, CLX, and LOOP is
highly questionable:

* In a language like Scheme (as opposed to CommonLisp)
that provides efficient implementations of higher order
constructs with natural syntax, there is little need or
excuse for something as horrible as LOOP in the first
place.  

* I see no reason for an X interface to make heavy use of
macros (everything can be implemented nicely as functions
or integrable functions).  

* It's perhaps OK to prototype an object system as a macro
package, but for production use, an object system (or any
equally complex extension to the language) should be part
of the compiler, for reasons of efficiency and
debuggability.

Altogether, I think the decision not to standardise macros
in Scheme has had the beneficial side effect of
discouraging their use (maybe that was one of the intents
in the first place). On the other hand, I doubt that the
differences between DEFINE-MACRO in different implementations
of Scheme are so significant that it is a serious obstacle for
writing a portable X window system interface, portable
iteration constructs, or portable prototypes of something
like an object system (even PCL doesn't run out of the box
on every implementation of CommonLisp).

Much more important to my taste than a standard macro
facility (there exists a de-facto standard anyway), would
be guidelines for a standard foreign function interface
to Scheme (at least for numerical code), and guidelines
for optimization features such as MAKE-MONOTYPE-VECTOR.
I say "guidelines" because I realize that such extensions
should not really be part of the language (they may not
even be implementable on some systems), but that there
should be a common consensus about how extensions of
this kind should look.