Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!bridge2!jarthur!uunet!mcsun!ukc!mucs!m1!bevan
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.scheme
Subject: Re: Macros
Message-ID: <BEVAN.91May29201204@orca.cs.man.ac.uk>
Date: 29 May 91 19:12:04 GMT
References: <1490@yoakum.cs.utexas.edu>
Sender: news@cs.man.ac.uk
Distribution: comp
Organization: Department of Computer Science, University of Manchester
Lines: 58
In-reply-to: wilson@cs.utexas.edu's message of 29 May 91 01:02:34 GMT

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 respectfully differ with your differing :-)
  I do think, however, that most people have their pet area that they
think _must_ be standardized for Scheme to survive.  For example, mine
is exceptions.

For what its worth, I'd like to see the following addressed in the
order given :-

  1. exceptions
  2. first class environments
  3. multiple value returns
  4. macros

Why in this order ?

  Without exceptions, some of the functions currently defined cannot be
used portably unless you don't care about possible errors. e.g. just
what do you do in your _portable_ Scheme program if open-input-file
can't open the file?

  First class environments (or some other packaging system) would allow
some of the later extension to be appropriately placed outside the
core language (possibly in a set of standard libraries as
robertj@autodesk.com suggests).  I really hope that this approach is
adopted as I would hate to see Scheme end up like CommonLisp with
hundreds of functions all in one name space.
  If any standard setters are listening, try taking a leaf out of
EuLisp's book.  This splits the whole language up across many modules.  For
example some of the EuLisp modules are :- characters, arithmetic,
list-operators, bit-vectors, vectors, tables, errors, streams ... etc.
Splitting the language like this means that you only have to pull in 
what you need.
  Granted, in a large application you will most probably pull them all
in in the end. However, it seems that Scheme is being increasingly
used as an extension language for applications (that's what I use it
for, amongst other things) and in these cases you only want a small
core.  (I'd actually like to prune the current Scheme standard to move
things like real/rational numbers into a separate module.  Why?
because I don't need them for an application :-)

Multiple values returns because I've recently noticed that a lot of
code that I've written containing success/fail continuations could be
rewritten as a function returning multiple values where the latter
would be the exceptional value.  I'm not saying this replaces all
instances of success/fail continuations, just some of them.

Macros because it would allow a uniform way to extend the language.
The reason this comes so low on my list is that I haven't wanted to do
it yet :-)

Yours dabbling with Scheme whilst looking for the one true language,

Stephen J. Bevan			bevan@cs.man.ac.uk