P. Srinivas (srini@skorpio3.usask.ca) wrote:
> Is there any real reason other than egos that prevents all Schemer's
> rally behind Guile?
There are very different purposes and environments for using Scheme,
and Guile - or any other current implementation I know about - simply
doesn't support each of those sufficiently well. It may even be very
hard to have a single implementation support the variety of reasonable
requirements well at all, though technically one can surely provide
much more flexibility than existing implementations. However, even a
great programmer wouldn't program that over a weekend; several months,
if not years, would be a more realistic time frame for a very broad
spectrum including e.g. _both_ excellent optimization and an excellent
interactive development environment, and interoperability with other
systems. Strong preferences for only some subset of the reasonable
requirements can simplify this considerably, but this will make the
result a poor choice for some different preferences.
Without the alluded giant effort, the best one might hope for is a good
consensus on interfaces for desirable facilities/properties, which should
be supported by any implementation which is supposed to provide such a
facility at all, and doesn't narrow the implementation choices more than
necessary (e.g. allow a _gradual_ movement from simple static translation
to almost arbitrary run-time modification, by providing layers which can
stand well on their own). Crafting such interfaces isn't something which
most people I know would do well by just throwing together some ideas
and implementing them in a single system. Careful design requires study
of existing approaches and their problems, and the will to question both
what one learned and what appears "intuitively" appealing. I'm afraid you
won't get that by making propaganda for "the one and only true system".
Of course, if you just want to attract the masses without fulfilling any
advanced requirements, hacking something together might work - just don't
expect that everyone puts forgets their interests and follows you.
Just to tell with my personal preferences: I want full compilation to
machine code (reasonably efficient C code generation is fine), and
a module model with static semantics, which allows separately compiled
modules to be linked just like one would do with compiled C files,
integrating an excellent macro system (something like syntax-case). I
like the complete numerical tower (including exact/inexact variants)
to be available, with decent efficiency, and a means to declare cases
where fixnum or flonum arithmetic is sufficient and expected for good
performance. Interfaces to system libraries - including those with more
complicated C types than the predefined ones - should be sufficiently
simple to implement, such that one doesn't have to hesitate if one's
pet library isn't supported, but can easily add interface declarations
as one discovers a need for them. Dynamic loading should be available,
but not necessary for system operation. Debugging the generated code
with a standard system debugger should be acceptable for someone who's
somewhat familiar with the implementation strategies. A system which
doesn't use EVAL, LOAD etc. shouldn't need to link in much more beyond
its actual requirements. The interface between the Scheme libraries
and the operating system should be exchangable, such that one could
merely link with another interface library e.g. to provide a fully
checked safe environment for untrusted code (obviously, this implies
control over the foreign function interface, too), or support the
low-level requirements of something like scsh. The system should be
a conforming superset of R4RS, with the changes agreed upon for R5RS.
It should be object-oriented from the ground up (with a MOP similar
in style to CLOS or EuLisp's, though clarity and efficiency are
preferable over run-time changes; e.g. allowing redefinitions only
in "development mode" may reduce quite a few optimizations compared
to "delivery mode"). I guess it will take more than a weekend ;-)
-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>
|