Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!ariel.unm.edu!cs.umn.edu!boley
From: boley@cs.umn.edu (Daniel Boley)
Newsgroups: comp.lang.scheme
Subject: standards
Message-ID: <1991May30.013756.21021@cs.umn.edu>
Date: 30 May 91 01:37:56 GMT
Organization: University of Minnesota, Minneapolis, CSci dept.
Lines: 46

I respectfully agree with the spirit of the letter.  But as a practical
matter, if portability is desired, you will have to look at what is in the
actual implementations.  Many leave out certain "optional" constructs, like
reals, rationals, "case", bignums, ... (these are the ones I have run
across).  Almost all of these schemes make the claim that they adhere
strictly to the R?RS standard.  These optional constructs that are left out
can make it very difficult to port code.

The result is that I can develop code on my scheme that claims to be
"standard" using only "standard" constructs,  but then my friend can't run
the same code on his/her scheme.

One solution for all those optional things is that there be some scheme library
that can be loaded to add in the "optional" features.  Unfortunately,
adding many optional features via scheme source will require macros.  But if
portability is a real goal, there must be some **standard** way of adding
many of the optional features so that every scheme implementation can have a
common base, including most of the common optional features.  At the moment,
it is possible to leave out the most unexpected "optional" features, and
still "adhere" to the standard.

A related point: If you want the language to be used widely by many people
in many disciplines, you have no choice but to make the language big enough
to handle their needs.  The language does not have to be that big, but at a
minimum, it must have most (if not all) of the "optional" features
standard, and it must have the basic hooks that people really use.  From the
discussion here, those latter features include things like macros, multiple
return values, environments, etc.  For a vanilla standard, many of these
could be implemented with just a few additional hooks in the basic language,
together with a small scheme library of front-end functions.  Then compiler
writers would be free to "hardwire" some of those front-end functions.  But
the basic language could be kept small.

This follows the suggestion of a library.  There would be a basic standard
language, and there would be a standard set of loadable code to expand the
language to adhere to an agreed-upon wider standard, in case the
implementation does not have the corresponding features built in.

WIth the narrow standard that exists today (that is the standard with none
of the optional features), every implementor feels free to decide
how to expand the language to his/her own demands, and each one does it
differently.

- Dan Boley

Don't mind me, I'm just an intruder from the fortran world.