Is Dylan not being considered because it was initiated by Apple?  Would
using a non-Apple Dylan implementation, such as CMU's Mindy, as a starting
point for GUILE be a violation of this boycott?

RMS made some very good comments in his post regarding why people should
refrain from using TCL as an extension language.  However, he stopped just
short of noting that the ideal extension language would provide the
extender as much power as the original implementor had.  (I would go
further and claim the ideal extension language would be the original
language of implementation, if it was suitable.  But that's neither here
nor there.)

Now instead of starting with Scheme and mangling it so it is no longer
Scheme (as defined by either R4RS or IEEE), why not go with a language which
provides the small size of Scheme, objects all the way down like Smalltalk,
and compilation into efficient binary like C?

Neither of the latter two points has been raised in the discussions to date.

When GUILE was announced, I suggested a Meta Object Protocol, but the
prevailing opinion was that it was overkill.  However, the idea of an
integrated object system merits consideration, I believe.  An object-oriented
extension language would be a Good Thing.

Regarding compilation, it seems to be tacitly understood that byte-compilation
is sufficient.  One of RMS's points was that people use extension languages
to write far more complex code than the designer of the language had
envisioned.  Such large pieces of code would benefit greatly from running
compiled (as opposed to byte-compiled).

It would be unfortunate to pass over a language which could be a potentially
very interesting extension language for purely political reasons.  I have
higher regard than that for GNU.  If someone can tell me why a modified
Scheme would serve better than Dylan, or why Dylan would per se be
inappropriate as an extension language, I'd love to hear from you.  After
all, that's why I'm posting this here.

Kaveh

--
Kaveh Kardan

        So nobody wants to acknowledge the possibility of Dylan being used

I see two problems with Dylan, neither of which is fatal, but both of
which suggest that Dylan would be a bad choice for the project:

        - There are no free Dylan implementations that are competitive
          with the several free Scheme implementations from which we
          chose a starting point.  Competitive means rougly as small,
          rougly as fast, and with good prospects for becoming smaller
          and faster in the future.

        - Dylan has a ubiquitous object system that appears to me to be
          costly to implement and of dubious utility.

The first problem is easily solved by producing a fast, free implementation.

The second problem could easily be refuted if the fast, free
implementation managed to implement the object system without too
great a cost in code complexity or portability.

-t

--
----

If you would like to volunteer to help with the GNU extension language

If every function were a generic function, that WOULD be expensive, analogous
to Smalltalk's messaging-only paradigm.  But Dylan allows you to define
normal Scheme-like functions when you don't want to pay that freight.

That's essentially all the support the compiler has to give.  The rest
of the object system is implemented by macros and the generic function
dispatch procedure.  We intend to add a MOP, and don't expect it to
slow the system down.  (A well-designed and well-implemented MOP should
cost something at compile time, but little or nothing at runtime.)  Actually
our current object system is lame and slow, and we expect our eventual
mop-based system to be much faster.

Having objects all the way down is not slow for non-OO code.  We implement
dynamic type checks using the class pointers, and it is fast.  E.g., PAIR?
just extracts the class pointer from an object and compares it to a pointer
to class pair.  For OO code, this makes it trivial to support specializing
generic functions on built-in types as well as user-defined types.

I think it would be good for the GNU extension language to have every object
an instance of a class, in the basic implementation.  Then it's easy to layer
a decent object system, with or without a MOP, on top of that.

I also suggest that you have a simple least-common-denominator object system
from the start, maybe just using single inheritance and single dispatching.
This will get you most of the benefit of an object system and let you leave
other design decisions until later.

--
| Paul R. Wilson,   Computer Sciences Dept.,   University of Texas at Austin  |

| (Recent papers on garbage collection, memory hierarchies, and persistence   |
| are available via ftp from cs.utexas.edu (128.83.139.9), in pub/garbage.)   |