Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!linac!mp.cs.niu.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Newsgroups: comp.lang.scheme
Subject: Re: Macros
Keywords: macro, extend-syntax, lexical scope, standards
Message-ID: <1991May29.200957.27040@uicbert.eecs.uic.edu>
Date: 29 May 91 20:09:57 GMT
References: <1490@yoakum.cs.utexas.edu> <1991May29.182453.24864@jato.jpl.nasa.gov>
Organization: University of Illinois at Chicago
Lines: 94

brian@granite.jpl.nasa.gov (Brian of ASTD-CP) writes:

>In article <1490@yoakum.cs.utexas.edu> wilson@cs.utexas.edu (Paul Wilson) writes:
>>I respectfully differ with the "open letter" about Scheme.  In particular,
>>macros *must* be standardized if Scheme is to survive.  Of all the
>>barriers to using Scheme, this one's probably the easiest to fix.
>>
>    I think one of the main points of the letter was that
>    Scheme ought to have standardized, but optional bits.

       This point is well taken.  Much of my posting was in this vein,
       with a different slant.  Standardize a basic syntax for macros,
       but make it optional to implement fancy features.  (It's a
       different issue whether lexical scope is considered too fancy
       to require;  I happen not to think so.)

>    Suppose macros were one such "standardized, but optional"
>    facility.  Let us add the requirement that "standardized,
>    but optional" facilities should be implementable in
>    portable Scheme.  It so happens that facilities like
>    "extend-syntax" and "defmacro" can be so implemented, and
>    there are probably implementations available in the Scheme
>    repository (I'll check nexus.yorku.ca in a bit).  So, 
>    whatever the standards committee agrees on will end up
>    being easily implementable if not freely available.

       The problem here is that macros are used so commonly that they
       should be part of the core language, so that with a little
       bit of care, there will be a portable dialect of Scheme that
       people can actually use for useful programs, library code, etc.

       The core language has to be big enough to be useful.  Look what's
       happened to Pascal.  It wasn't big enough, so we're stuck with C.
       Similarly, if Scheme doesn't get big enough, soon, we'll be stuck
       with Common Lisp... or C++.   Maybe it's too late already.


       But I'll go ahead and take a position on lexical scope:
       If macros are to be lexically-scoped, the hooks should be built
       into the core compiler.  It's absurd to implement a whole compiler-
       like prepass to do the necessary scope analysis.  Just reify the
       compile-time environments and be done with it.  (This is analogous
       to reifying closures and continuations -- you could always implement
       a language that has them as a prepass, but that's missing the point.
       The basic language should provide enough power to make it *easy* to
       implement useful things as extensions.)

       You may argue that this is a reductio ad absurdam -- that if you
       have to change the essential compiler, you shouldn't add in
       lexically-scoped macros.  But that's a whole other religious
       issue, and I lean the other way -- lexically scoped macros are
       the Right Way, just as lexically scoped variables are.  Scheme
       should not leave them out.  If we're going to have Wrong Way
       macros, we might as well use Lisp :-).

>    So, by following the proscriptions of the letter, we get
>    to have our cake and eat it too.  Implementors of Scheme
>    can have a small job to do by implementing the "core"
>    essential language.  Then users can just download
>    implementations of the standard, but optional bits that the
>    implementor might not have provided.

       It does make sense to have standard but optional features.
       The important ones will become de facto core features, like
       standard io for C.  But then maybe it doesn't matter that they're
       not officially part of the core language.  I think macros are
       clearly so important that they may as well be required.

       Either way, we need macros ASAP, no matter how low the least-
       common denominator.  (Low *not* meaning Wrong -- it should
       be upwardly compatible with Truth, Beauty, and Righteousness :-)

       Next question:  can this approach be used to define a noncontroversial
       core of functionality to standardize fluid variables?  What's the
       current status of that controversy?  Could we standardize a syntax
       and basic functionality, but leave arguable things undefined?

         -- Paul

> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> . . Brian Beckman . . . . . . . . . . brian@granite.jpl.nasa.gov. . . .
> . . meta-disclaimer: every statement in this message is false . . . . .
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


| Paul R. Wilson, Interactive Computing Envts. Lab. lab ph.: (312) 996-9216   |
| U. of Illinois at Chicago EECS Dept. (M/C 154)    wilson@bert.eecs.uic.edu* |
| P.O. Box 4348   Chicago,IL 60680                  fax ph.: (312) 413-0024   |
| *Next yr, Asst Prof, UT Austin CS Dept-- after 8/1 use wilson@cs.utexas.edu |
-- 
| Paul R. Wilson, Interactive Computing Envts. Lab. lab ph.: (312) 996-9216   |
| U. of Illinois at Chicago EECS Dept. (M/C 154)    wilson@bert.eecs.uic.edu* |
| P.O. Box 4348   Chicago,IL 60680                  fax ph.: (312) 413-0024   |
| *Next yr, Asst Prof, UT Austin CS Dept-- after 8/1 use wilson@cs.utexas.edu |