Xref: utzoo comp.lang.lisp:3683 comp.lang.scheme:1696
Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!mike
From: mike@ists.ists.ca (Mike Clarkson)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: Virtues of Lisp syntax (a tangent on macros and Scheme)
Message-ID: <12812@ists.ists.ca>
Date: 20 Sep 90 02:46:13 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>
Reply-To: mike@ists.ists.ca.ists.ca (Mike Clarkson)
Followup-To: comp.lang.lisp
Organization: Institute for Space and Terrestrial Science
Lines: 74

In article <1990Sep18.180829.8801@hellgate.utah.edu> moore%cdr.utah.edu@cs.utah.edu (Tim Moore) writes:
>>Nor can I buy the "MACROS" argument.  Most applications programmers(as
>>opposed to "language implementors"), make very little use of macros.  Nor
>>do they have much reason to do source level debugging of macros supplied
>>with their particular implementation.  IOW, *most* of their debugging is
>>done on functions, not macros.  And if they do use macros, they are usually
>>fairly simple and straightforward.
>>
>
>It's not the macros that the application programmers write themselves
>that cause problems; at least the programmer knows what the expansions
>of those macros look like. Rather, it's the macros that are a part of
>the language that cause trouble. Consider how often Common Lisp
>programmers use cond, setf, dotimes, dolist, do, and do*. The
>expansions of these macros can be pretty hairy. Maintaining the
>correspondence between the internal representation of a function and
>the form that produced it is not trivial.

A bit of a tangent on macros and Scheme:

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.
The large packages hid many of the bookkeeping details from the applications
programmer, and assuming they work as described, s/he is able to write
much denser and compact code.  Look at programming in Picasso as an example.

This is "a good thing" in the Abselson and Sussman sense, and each or
these packages I mentioned is becoming a standard of sorts, getting
incorporated back into the evolving Common Lisp standard.  Contrast this
with the case in Scheme: there is no standard definition of macros or
structures or advanced loops or any of the things neccessary to build
these abstracting packages.  As a result, they are difficult to build
and by definition, ex-standard. 

The lack of these parts of the Scheme standard is intentional.  In the
current Scheme point of view is that, "The ability to alter the syntax
of the language creates numerous problems.  All current implementations
of Scheme have macro facilities that solve those problems to one degree
or another, but the solutions are quite different and it isn't clear at
this time which solution is best, or indeed whether any of the solutions
are truly adequate.  Rather than standardize, we are encouraging
implementations to continue to experiment with different solutions." But
in the interim, time marches on, and it is crippling the language from
development into areas that are also very important. 

I dearly love Scheme as a language, but because of the lack of
standardization 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. 


Mike.



-- 
Mike Clarkson					mike@ists.ists.ca
Institute for Space and Terrestrial Science	uunet!attcan!ists!mike
York University, North York, Ontario,		FORTRAN - just say no. 
CANADA M3J 1P3					+1 (416) 736-5611