Portability

[kend%bloom.la.tek.com@RELAY.CS.NET]

POSITION:

One of Scheme's many strengths is its clear definition.  The use of
denotation semantics makes it possible to provably implement the same
semantics on very different CPU architectures.  By its nature, Scheme
should be the most portable of languages.  Indeed, standard Scheme
programs are typically ported between implementations with the same
source code and a small compaibility file.

The number of implementations is rapidly growing.  Not having a
standard library interface and not having a way to define a single
compaibility file across a large number of implementations will
shortly be a major impediment to portability.

For a moderately large and complex `program' to be portable, there
must be a baseline functionality.  Typically there will be a gap
between this baseline and the IEEE (minimalist) standard.  In order to
be able to use definitions provided by an implementation, there needs
to be a way to query implementations about environmental differences
(eg: implementation+version, OS, FS, CPU, ...) and a way to
non-intrusively add definitions--including commonly used syntactic
idioms (when, unless, ...) and optimizations (define-constant <->
define; define-integrable <-> define; herald <-> comment; error <->
cerror; ...). 

Let me give an example.  Here is a definition which maps a
machine/implementation specific function to an implementation independent
one.  Note that--as defined--all of this code gets compiled, although we
only need one of the lambda bindings.  We can get around this using
syntax/macros, but that is currently not portable!

  (define %draw-point  ; args: (x y color)
     (case <scheme-implementation>
       ((PCScheme)  (lambda (x y color) (%graphics 1 x y color 0 0 0)))
       ((MacScheme) (lambda (x y ignored) (draw-point x y)))
       ((T) ...)
       ((CScheme) ...)
       ((Skim) ...)
       ((XScheme) (case <OS> ...) ...)
       ((AmigaScheme) ...)
       ...
       (else (error "unrecognized scheme implementation" 
                    <scheme-implementation>))
  )  )
  
In addition, there is the problem of augmenting what is absent in a
non-intrusive way.  Something along the lines of:

   (define-if-needed (foo . args) body)
   ==> (unless (defined? foo)
               (define-in-enclosing-env (foo . args) body))
  

It would be nice to define an ERROR function for programatic recovery as
well as a special form (`CERROR' ?) which captures state for interactive
debugging.  It would be helpful to have a suggested interface for functions
which may be implemented but are not required (e.g. TIME should--if defined--
return the clock time in the same format for all implementations).

Anyway, it seems to me that a lot of work needs to be done here.  If done
well, we will get portable code.  If not done, we can have a real mess.

I will be happy to track proposals in this area.

Comments?  I'm sure there are comments!

-Ken			kend@mrloog.LA.TEK.COM