Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.apocalypse.org!news.mathworks.com!uunet!in1.uu.net!franz.com!franz.com
From: kem@franz.com (Kelly Murray)
Subject: Re: A Dylan implemented on Common Lisp
Message-ID: <1995Mar9.061636.27652@franz.com>
Sender: kem@math.ufl.edu (Kelly Murray)
Nntp-Posting-Host: bell
Organization: Franz Inc.
References: <1995Mar6.221932.28468@franz.com> <2877609984@hoult.actrix.gen.nz>
Date: Thu, 9 Mar 1995 06:16:36 GMT
Lines: 25

[ just to comp.lang.dylan ]

In article <2877609984@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes:
>> kem@prl.ufl.edu (Kelly Murray) writes:
>> > If the CL->Dylan mapping isn't 100%, maybe we could
>> > push hard to get Dylan changed so it would be.  
>> 
>> Aren't there features that are in Lisps that will *never* be in Dylan,
>> because of the runtime overhead?  Isn't call/cc one such?

I can't speak to what will or will not be in Dylan -- looks like only Apple
Computer can do that!  But I think you've misunderstood the CL->Dylan mapping.
I'm referring to a syntactic transformation of a subset-CL into Dylan.
This CL-subset would not include any features that Dylan doesn't have.
For example, this CL-subset could not change class definitions at runtime.
Call/cc is a Scheme construct -- I think you might get some argument over
whether or not it's actually a feature :-)

[ BTW, I think I should mention that I now am working at Franz Inc.
  My new email address is kem@franz.com, though I still might post from
  my University of Florida account, kem@prl.ufl.edu. 
  As usual, my opinions are my own and I do not speak for my employer. ]

-Kelly Murray   kem@franz.com 

