Sorry Tony, but I disagree with you.
[I was going to write about free versions of UNIX, but erased it]
The real issue in this group is versions of Scheme. There have to be
many different approaches to Scheme so that many research ideas can be
tried out. Here are some examples of things that have to be explored
by different Scheme implementations:
* several garbage collectors: I want to run Scheme on a satellite,
doing real time data acquisition, so we need to see Scheme
interpreters with real-time GC.
* approaches to graphics: STk is great in that sense, because we all
tend to like Tk these days. Guile had (and will have again) an OpenGL
API. MzScheme also has a GUI framework.
* Object Systems and Module systems: these are not a standard part of
Scheme, and different people are proposing different ones. If we can
try them all out, we will know which is best.
* Foreign function interfaces: many Scheme systems have these, and
some are nicer than others.
If you want to avoid duplicated effort, one way is to convince the
implementors to agree on standards that allow these research
directions to be quickly incorporated in other Scheme interpreters.
Paul Wilson has proposed an Object system for Scheme, and he is paying
careful attention to the cross-platform issue.
I have had success in getting many Scheme implementors (MzScheme,
RScheme, STk, Guile) to be interested in using Guile's high level
interface (the gh_ interface) as an available foreign function
interface for their systems. Once gh_ is ready for Guile, people will
be able to use it on other Scheme systems.
I don't know of any effort in making garbage collectors modular and
selectable among Scheme implementations.
So to sum it up, in a genetic algorithm language, if you want to give
good mutations in GCs, FFIs and OOPs for Scheme, you must encourage
diversity.
Received on Sat Jan 11 1997 - 19:04:18 CET
This archive was generated by hypermail 2.3.0
: Mon Jul 21 2014 - 19:38:59 CEST