Dylan, guys, Dylan. 
Author Message
 Dylan, guys, Dylan.

So nobody wants to acknowledge the possibility of Dylan being used as
GUILE (formerly GEL).  Now I realize GNU is boycotting Apple.

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



Wed, 30 Apr 1997 07:43:58 GMT  
 Dylan, guys, Dylan.

        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



Thu, 01 May 1997 03:29:57 GMT  
 Dylan, guys, Dylan.

Quote:

>    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.

This is a good point.  It's  reasonable conservative path.  Also, Dylan's
syntax is a bit verbose, which is unlikely to play well with the scripting
crowd.  I think it would be wisest to try to keep open a path to Dylan
compatibility, with maybe a (tersified) Dylan subset front end added later.

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

I think you're mistaken here.  A Dylan-style object system doesn't cost
much at all, either in code size, or in performance for code that doesn't
use generic functions.  And it's a big win for object-oriented code if
every Scheme data type is a class in the object system.  It makes it possible
to have a faster and more general generic function system.

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.

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

We don't have a fast, free implementation of Dylan, but RScheme has some
of the important features you care about.  The compiler doesn't currently
generate lightning-fast code, but that's got nothing to do with the
objects-all-the-way-down design.

Quote:
>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.

Please have a look at the RScheme design.  The main support for the object
system is just to ensure that each class is represented by a first-class
object.  Every heap-allocated object has a pointer to its class object
in a header field, and we fake the same thing for built-in types that
aren't actually allocated on the heap.  There is a primitive CLASS-OF that
can take any value and give back a pointer to its class.  For heap-allocated
objects, it just extracts the header field.  For immediate objects like
ints an characters, it looks aside into a table of class pointers.

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.)   |



Fri, 02 May 1997 00:31:31 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Dylan, guys, Dylan.

2. archives of info-dylan/comp.lang.dylan available

3. Dylan vs DyLan

4. (fwd) harlequin's dylan-corba mailing list switching to MIT's info-dylan

5. lazy.dylan 0.1 -- add ML/Scheme-style lazy evaluation to Dylan

6. Dylan and Java [was: Harlequin Dylan - Update]

7. Dylan Programming Book and Apple Dylan

8. Dylan is the Name was(Re: Dylan (Bob) eats rotten Apple (Computer))

9. Dylan alternative (was Dylan complexity)

10. Sudden interest in Dylan/Dylan should be open.

11. c.l.dylan overlap with Dylan mailing lists?

12. Dylan Barriers (was: Sudden interest in Dylan/Dylan should be open.)

 

 
Powered by phpBB® Forum Software