Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson
From: wilson@uicbert.eecs.uic.edu
Newsgroups: comp.lang.scheme
Subject: Re: R4RS changes?  Code?
Message-ID: <82000005@uicbert.eecs.uic.edu>
Date: 12 Dec 88 20:31:00 GMT
Lines: 31
Nf-ID: #R:<8812072227.AA00515@uicbert.eecs:-41:uicbert.eecs.uic.edu:82000005:000:1580
Nf-From: uicbert.eecs.uic.edu!wilson    Dec 12 14:31:00 1988


    With regard to standardization, I would think it would be possible
to standardize a rather underspecified version of a macro facility,
without specifying things like scope rules.  In that way, careful
programmers could use basic macros in a portable way, so that their
programs could run in varying Schemes, and be compatible with an
eventual more detailed specification;  e.g., if all of your macros
have unique names, you don't have to worry about name collision
resolution details.

    (This would be akin to programmers who write programs
that don't rely on dynamic or static scoping, so that
they run the same way with a dynamically-scoped interpreter and a
lexically-scoped compiler.  While it's not the best situation, it's
better than not being able to use a macros (or a compiler).)

    Or is this considered a path to perdition, with people writing
code that they think is portable but isn't, because of accidental
implementation dependencies?  Standardization of noncontroversial
aspects of features is just one step down the slippery slope from
fully specified standard features, but it seems a particularly
attractive step to me.  A small commitment to a core functionality
of macros and dynamic/fluid variables could come in very handy in
the short run, and still allow a fuller, more righteous specification
the next time around.

    -- Paul

Paul R. Wilson                         
Electronic Mind Control* Laboratory
U. of Illin. at C. EECS Dept. (M/C 154)   wilson%uicbert@uxc.cso.uiuc.edu
Box 4348   Chicago,IL 60680   *a.k.a. Human-Computer Interaction