graphics for Scheme

[andy@ads.ARPA (Andy Cromarty)]

A good alternative to providing graphics capability is to solve the
more general problem of designing a clean foreign function interface
standard.  This would permit a variety of useful existing software
packages to be integrated into Scheme environments without requiring
that we deflect our attention from substantive language design issues
(and our plate is rather full already) to address ancillary and difficult
problems such as design of packages for graphics, window systems, etc.
This would also make Scheme much more attractive to people who actually
want to use Scheme as a programming language rather than as an object
of study.

Designing a good foreign function interface is nontrivial if we
wish to maintain a principled design approach.  I suspect that 
it would require us to revisit some of the thorny problems we've
brushed up against but not really solved in the past few months,
such as whether Scheme should be thought of as having a dynamic
binding environment vs. an essentially static one defined purely
by the lexical structure of our programs.  In the former case,
a relatively conventional dynamic loading scheme might work best;
for the latter case, a declaration-based system might be more
appropriate.  In either case, we would need a spec for translating
Scheme data structures into those of other languages.  (Perhaps
the SUN xdr might be a good spec to work from for this part of
the problem.)

A foreign function interface might also make Scheme a better
base language environment for studying some difficult contemporary
programming paradigm problems, such as techniques for distributed
and parallel processing.  Currently we achieve this locally at ADS by
extending our Scheme with functions written in C and linked in
statically by the linkage editor.  This has the disadvantage of 
requiring that the researcher know not only how to code the new
parallelism/distributed processing primitives, but also what the 
internal structure of the Scheme environment is in some detail.  
A foreign function interface would provide a sort of firewall that 
would prevent the designer of new constructs from having to know 
what the Scheme implementation's internals look like.

					asc