Re: dylan-virtual-machine

["Jason Trenouth" <address@hidden>]

Hi Raffael,

Dylan was designed to bring (Common) Lisp to the masses and to address
several perceived problems of (Common) Lisp, including:

- execution speed
- application/component delivery/deployment (*)
- historical baggage / API idiosyncrasies (car/cdr)
- unfamiliar syntax

So although a VM implementation of Dylan might be slower it could still
address the other issues.

For the record, some original internal prototypes of Harlequin Dylan used a
VM to achieve tethering and interactive development.

__Jason

(*) One instance of a decision here was that for the COM interface we
decided to concentrate on being a component rather than using other
components because that was the antithesis of Lisp-as-harness approach.

----- Original Message -----
From: "Raffael Cavallaro" <raffael@attbi.com>
To: "marc" <schlichte_marc@yahoo.de>
Cc: <info-dylan@ai.mit.edu>
Sent: Saturday, April 06, 2002 6:14 AM
Subject: Re: dylan-virtual-machine


>
> On Friday, April 5, 2002, at 09:00  PM, marc wrote:
>
> > What is the current thinking about a dylan-virtual-machine in this
> > group?
>
> I think one has to see Dylan in the context out of which it arose - in
> particular, Common Lisp. There really aren't many features that Dylan
> has that Common Lisp doesn't have, *except* those which were
> specifically designed to allow compilation optimized for execution speed.
>
> See, the whole promise of Dylan was the speed of compiled C, with the
> dynamism and multiple dispatch of Common Lisp (insofar as the latter was
> not prevented by the first). The programmer would have the choice of
> whether to maintain full dynamism, at the expense of slower dispatch, or
> sacrifice some dynamism for more optimized compilation, through sealing.
> (The  ability to modify classes and existing instances in a running
> system, and a full MOP allowing changes to the object system itself,
> were also jettisoned in Dylan as keeping them would hamper optimization.
> Dylan also has Hygenic, Pattern Matching Macros, which some in the
> Common Lisp community see as a misfeature, at worst, or an easily solved
> problem at best - a with-gensyms macro does the trick for most people).
>
> Now, if one were to compile Dylan to run on a virtual machine
> (presumably significantly slower than compiled C or FunO compiled Dylan)
> why use Dylan? Why not just take a bit of a speed hit (factor of 2 at
> most, often just as fast as C) and use the full, unrestricted dynamism
> of Common Lisp?
>
> IOW, Dylan only exists so that people who like DOOLs can compile their
> code to run as fast as compiled C or Fortran. If you're willing to
> sacrifice some speed, just use Common Lisp  - the community is much
> larger, there are far more, and more mature implementations, more freely
> available code, etc. And while Dylan has largely languished, some Common
> Lisp compilers (CMUCL, Allegro, Xanalys) are now almost fully on par
> with good optimizing C compilers, farther reducing the need for Dylan...
>
>
> Raffael Cavallaro, Ph.D.
> raffael@attbi.com
>
>