[Prev][Next][Index][Thread]
Re: [Q] Dylan to Java/JVM compiler?
Raffael Cavallaro <raffael@mediaone.net> writes:
> So CLOS built-in classes are a bit like primitive types, in that, there are
> things one can do with other classes and objects that one may not do with
> CLOS built-in classes or instances thereof. In this regard, CLOS is not OO
> from the ground up in the way Smalltalk,for example, is. Of course Smalltak
> lacks multiple inheritance and multiple dispatch, so...
I don't know enough about Smalltalk to be sure about this, but is it
really supported to derive from the built in integers and redefine
addition? In general, a lot of languages I would consider OO from the
ground up like Eiffel have restrictions on some of the basic
classes. It's the only way to be able to compile some basic stuff
efficiently into machine primitives.
I see in the drm at gwydiondylan.org that <integer> is a sealed class,
so Dylan is as OO as CLOS in this respect.
> > Is there at this moment a Dylan compiler that beats a good CL compiler
> > on equivalent code? Theoretically, the Dylan compiler can potentially
> > do better by the sealing constructs, but that's about the only
> > difference I see between CL and Dylan w.r.t. possible optimisation.
>
> You may recall that I referred to the "Holy Grail of Dylan..." I didn't
> claim that it had been achieved.
A pity. I look at Dylan as an experiment in the efficiency of sealing
constructs but from a negative result no conclusions can be drawn,
since there has been invested a lot more effort in CL compilers than
in Dylan compilers. It would have been nice if Dylan got a factor 10
improvement out of it.
> Personally I prefer Common Lisp, because I think that Dylan, as
> implemented to date, has more the feel of a statically compiled
> language, despite its name (DYnamic LANguage).
It is dynamic in comparison to mainstream languages like C++ and
Java. One of the design goals from the beginning was to be less
dynamic than CL to avoid including a signifant part of the compiler in
applications to support things like EVAL and COMPILE.
I wonder why they kept dispatching on instances. It's a feature I'd
remove from CLOS since it doesn't add much to the expressiveness of
the language and interferes with optimizing GF dispatch.
--
Lieven Marchand <mal@wyrd.be>
Glaðr ok reifr skyli gumna hverr, unz sinn bíðr bana.
Follow-Ups:
References: