Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: greg@vis.UUCP
Newsgroups: comp.lang.scheme
Subject: Re: Non Chez Nous or Repository
Message-ID: <9103182135.AA23167@ifsrad>
Date: 18 Mar 91 21:35:41 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 84

There is a serious problem with hand translating popular scheme
programs into everyone's favorite dialects.  This splits the programs
into incompatible versions which develop separately and require
retranslation every time an interesting new version becomes available
(in the original dialect or in the derivative versions).  I have a
proposal for how the dialect problem can be handled which minimizes
this problem.  This is also a good opportunity to address at a
practical level the sufficiency of the Scheme standard.  Here is my
proposal:

(1) Non-standard scheme code should be kept in the repository in a
directory named for the dialect, e.g. chez-scheme, mit-scheme, etc.

(2) Dialect conversion software for all of the popular dialects should
be strongly solicited.  It should include:

(2a) Standard scheme implementations of as many features as possible.

(2b) Implementations of the features which need to be macros using
both the extend-syntax feature and (as soon as its ready) the R^4
macro mechanism.

(2c) A standardizing scheme preprocessor (SPP) which translates files
written in extended-scheme dialects into either the standard dialect
or a supported non-standard dialect.  The SPP needs to handle (i)
non-standard lexical notations, (ii) include files (a feature of some
scheme dialects), (iii) expand macros (if desired), and (iv) any
remaining features which cannot be implemented with procedures or
macros, e.g., include files.  One SPP program should be sufficient as
long as it is given the source and destination dialects as parameters.

(3) As soon as a piece of non-standard scheme can be standardized
using the methods in (2), it should be moved to the standard scheme
directory in the repository.  However, it is important that this not
be done if *any* hand massaging of the code is still required.  I
should be able to use code from the standard scheme repository as
follows:

(3a) Suppose that I'm using standard scheme and that the code I want
to use was written, for example, in Chez Scheme.  Then I should (i)
run SPP over the source file with the parameters ('chez-scheme
'standard-scheme) and (ii) load the new source file with the standard
version of the library functions called for (which need to be in the
repository).

(3b) Suppose that I'm using, e.g., R4-scheme and the code was written
for Chez Scheme.  Then I should (i) run the SPP over the source file
with the parameters ('chez-scheme 'r4-scheme), (ii) load it with
either the standard or the R4 library functions called for plus the R4
version of the Chez macros (in short, with the R4 version of the Chez
extensions).

An arrangement like the above has several benefits: (i) It allows
scheme programmers to maintain their local copy of any major program
in the original dialect, so they can share their fixes and
enhancements, and (ii) it allows for easier experimentation with new
language features, assisting in the evolution of the standard language
without losing portability or requiring the standard language to
implement features which may not maintain their popularity.

One of the important features of the lisp-based languages is that its
relatively easy to write programs which do processing on scheme
programs.  Doing this without losing comments and with minimal
disruption to the layout of the original code is a bit more difficult,
but not very difficult and should be a good challenge for scheme
programmers.  Scheme implementors should be discouraged from adding
extensions which can't be mechanically preprocessed into standard
Scheme.  Ideally experimental features would be put into the
preprocessor before integrating them into the
reader/compiler/interpreter of some Scheme dialect.  A simple
extension to any Scheme dialect would be to run the SPP automatically
when loading or compiling files, inferring the source dialect from the
file's extension.  That way, there is no need for most extensions to
ever be part of the local scheme implementation.

_Greg


J. Greg Davidson	Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA
 
greg@vis.com				ucbvax--| telesoft--|
vis!greg@nosc.mil			decvax--+---ucsd----+--vis
vis!greg@ucsd.edu		 	 ihnp4--|   nosc----|