From: Christopher C. Stacy
Subject: Re: Relationship of Lisp and Dylan
Date:
Message-ID: <uislgullo.fsf@dtpq.com>
>>>>> On Wed, 19 Nov 2003 17:59:56 GMT, NFish ("NFish") writes:
NFish> What relationship is there between Lisp and Dylan? I have
NFish> heard some people characterize Dylan as a dialect of Lisp.
NFish> Is this true in some formal sense, or is it just acknowledging
NFish> the heavy Lisp influences in Dylan?
It's similar to the argument about whether Scheme is
a dialect of Lisp. Originally, Dylan used s-expression
syntax, not C-style syntax. (It was changed for marketing reasons.)
Christopher C. Stacy wrote:
> Originally, Dylan used s-expression
> syntax, not C-style syntax. (It was changed for marketing reasons.)
Another "brilliant" marketing idea that worked so well. IMHO, had they kept
the sexpr syntax, they might have taken mind- (and educational market-)
share from Scheme (Why teach Scheme when you can have Scheme on steroids?).
As it is, they now have neither educational nor commercial mind- or
marketshare. It is a language destined for the scrap heap of computational
history - which is too bad because it had a few really good ideas in it.
The sealing concept was pretty interesting and the object system was fairly
cleanly designed. In overreaching, they lost everything. So it goes...
faa
"Frank A. Adrian" <·······@ancar.org> wrote in message
························@news.uswest.net...
> Christopher C. Stacy wrote:
>
> > Originally, Dylan used s-expression
> > syntax, not C-style syntax. (It was changed for marketing reasons.)
>
> Another "brilliant" marketing idea that worked so well. IMHO, had they
kept
> the sexpr syntax, they might have taken mind- (and educational market-)
> share from Scheme (Why teach Scheme when you can have Scheme on
steroids?).
> As it is, they now have neither educational nor commercial mind- or
> marketshare. It is a language destined for the scrap heap of
computational
> history - which is too bad because it had a few really good ideas in it.
> The sealing concept was pretty interesting and the object system was
fairly
> cleanly designed. In overreaching, they lost everything. So it goes...
Hmm...no...I don't think so.
This implies that the motivation for adopting Scheme in the first place was
the syntax, and that s-expr Dylan as "Scheme++" would have swept the field.
I think the motivation towards Scheme is its simplicity. Even if one must
heap gobs of libraries and what not, as a teaching language, Scheme has
"everything" for the basic algorithms and what not that students really
need. It's even "easy" to write "interesting" implementations for students.
Dylan is really the medium through which its object system can be brought to
life, and it's most attractive feature. But that alone wasn't compelling
enough for it to get wide adoption. Add to the fact that there are really
only, what, two implementations available, and they are non-trivial
implementations, which keeps its porting and availability down.
Marketing is very important, and Dylan failed simply because what marketing
it could bring to bear was shoved out by the roar of Java on the
applications side as well as the firestorm of scripting languages turned
application languages. Then, MS came out with .NET to introduce the "new
world order" to the plethora of language developers on its platform, and
Dylan won't port well to that architecture (just as CL doesn't). That
doesn't help either.
Finally, Dylan didn't attract any following at all during the .COM bubble
when the IT industry was hungry, flush with cash and looking for advantages.
Even CL can consider the .COM era as a bit of a rebirth.
So, while its hip to blame the syntax shift of Dylan for its demise, I think
that's mostly irrelevant, and if anything it DID help it garner some support
by those lured by its familiarity.
Regards,
Will Hartung
(·····@msoft.com)
Frank A. Adrian wrote:
> Christopher C. Stacy wrote:
>
>
>>Originally, Dylan used s-expression
>>syntax, not C-style syntax. (It was changed for marketing reasons.)
>
>
> Another "brilliant" marketing idea that worked so well. IMHO, had they kept
> the sexpr syntax, ...
How hard would it be to switch back? CL is gaining traction sexprs and
all, maybe switching back to the sexpr horse is in order. They sure as
hell have nothing to lose.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> How hard would it be to switch back? CL is gaining traction sexprs and
> all, maybe switching back to the sexpr horse is in order. They sure as
> hell have nothing to lose.
How many of Dylan's features could be coopted as extensions to CL?
For example, adding a metaclass with Dylan's monotonic CPLs.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Kenny Tilton wrote:
>
> > How hard would it be to switch back? CL is gaining traction sexprs and
> > all, maybe switching back to the sexpr horse is in order. They sure as
> > hell have nothing to lose.
>
> How many of Dylan's features could be coopted as extensions to CL?
> For example, adding a metaclass with Dylan's monotonic CPLs.
Of course, only the most perverse CLOS code runs into that problem. I
think the other things the language had to offer was sealing, and
everything-is-a-generic. As for sealing, everyone[*] seems to agree
that CLOS can and should be extended (at the implementation level) to
include sealing and unsealing, which is not so much coopting Dylan's
feature as it is learning from it, and doing it better.
Having all function s be generic, on the other hand, is a bad idea,
unless you're going to design a new language. It's probably a good
idea, I know I've loved using Smalltalk, and Dylan sounds similar in
that regard. But it's an exclusive choice between that and
compatability with more traditional Lisp, and ... well, I've made my
choice. I wouldn't object one bit however, to Dietz Here Lisp[**]
that provided both CL, and another interoperable dialect where
everything was a generic.
[*] Where "everyone" is defined as at least Gerd Moellman and Duanne
Rettig -- not quite the usual definition, but not a bad one, given the
context :-)
[**] Sorry, Kent made me do it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> Of course, only the most perverse CLOS code runs into that problem. I
> think the other things the language had to offer was sealing, and
> everything-is-a-generic.
I think the reason for using a good linearization (C3, which is one
step up from Dylan's, has been adopted by Goo and Python) is that it
lets you do dispatch using optimized dispatch tables. I don't know how
CMUCL/SBCL's CLOS does dispatch, but there are several good algorithms
that depend on something like a C3 linearization.
Paul F. Dietz wrote:
> How many of Dylan's features could be coopted as extensions to CL?
>
Most of them, except for the single namespace and the very clean
pre-defeined object structure :-). Most of the other items were compiler
related. In general, you could build a Dylan compiler that compiled into a
CL runtime very easily. The first Dylan was implemented on top of Scheme
(and I believe that the code for the Thomas implementation built on top of
MIT Scheme is still around).
faa
Frank A. Adrian wrote:
> Paul F. Dietz wrote:
>
>
>>How many of Dylan's features could be coopted as extensions to CL?
>>
>
>
> Most of them, except for the single namespace and the very clean
> pre-defeined object structure :-). Most of the other items were compiler
> related. In general, you could build a Dylan compiler that compiled into a
> CL runtime very easily. The first Dylan was implemented on top of Scheme
> (and I believe that the code for the Thomas implementation built on top of
> MIT Scheme is still around).
I'm not sure what you mean by "the first implementation of Dylan," and
I'm not sure what you mean by "on top of Scheme," but Leibniz, the Ralph
compiler implemented by Apple Cambridge (which is what Coral Software
turned into after Apple bought it), was written in Common Lisp and
delivered (internally, to the Newton Group) as MCL with an image that
included the Ralph cross-compiler targeting the ARM chip and a bunch of
development and debugging tools.
It is true that Jeff Piazza wrote a CPS compiler that that compiled a
language very like Scheme hybridized with CLOS, and that was Ralph.
There were parallel listeners; you could open a Common Lisp listener
running code on the Mac's 68K, and a Ralph listener running code on the
Newton's ARM.
In those days, while the language was still called Ralph, before the
Great Renaming to Dylan, a Newton was a circuit board and LCD attached
to the Nubus by a ribbon cable.
> How many of Dylan's features could be coopted as extensions to CL?
> For example, adding a metaclass with Dylan's monotonic CPLs.
A lot of Dylan's niceness comes from the fact that it is a refactoring
of CL and Scheme. Its objects all the way down, it ditches some CLOS
features that make efficient compilation difficult, it regularizes the
naming of functions, etc. You can't get those things back without
making big changes to the core of CL. Some of the other stuff that you
could adopt (hygenic macros) wouldn't fly in the CL community anyway.
"Paul F. Dietz" <·····@dls.net> writes:
> Kenny Tilton wrote:
>
>> How hard would it be to switch back? CL is gaining traction sexprs
>> and all, maybe switching back to the sexpr horse is in order. They
>> sure as hell have nothing to lose.
>
> How many of Dylan's features could be coopted as extensions to CL?
> For example, adding a metaclass with Dylan's monotonic CPLs.
One interesting one I have seen mentioned on c.l.l before is the fact
that sequence operators are generic functions. So if you write a
red-black tree, and want to iterate over it using the standard
operators, you can do it.
-russ
Russell McManus wrote:
> One interesting one I have seen mentioned on c.l.l before is the fact
> that sequence operators are generic functions. So if you write a
> red-black tree, and want to iterate over it using the standard
> operators, you can do it.
AFAICT, the sequence operators in ANSI CL *can* be compliantly implemented
as generic functions. An interesting idea.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Russell McManus wrote:
>
> > One interesting one I have seen mentioned on c.l.l before is the fact
> > that sequence operators are generic functions. So if you write a
> > red-black tree, and want to iterate over it using the standard
> > operators, you can do it.
>
> AFAICT, the sequence operators in ANSI CL *can* be compliantly implemented
> as generic functions. An interesting idea.
This is true, and was even done intentionally, but I personally
definitely don't recommend it. IMO, it's not a good idea to make
anything generic that you don't have a good reason for. There are
numerous kinds of practical problems that can result.
CL leaves it for vendors to experiment with, but I think it was a smart
decision that CL made to not require it. (There were some people who were
pushing for making all things generic, and we at the time decided it was
premature given our experience with genericity. In retrospect, having seen
some of the things people claim they'd have used this for, I'm personally
sure this was a wise decision.)
Note that even though Dylan allows it, there is a subtle difference:
Dylan is not nearly as 'dynamic' a language as its name implies. It
really makes its best work out of its static nature. In most cases,
their "redefinition" and "extra methods" are statically done at
startup, not dynamically during a program session, and so some (not
all) of the potential ill effects of excess dynamicity are not as
visible as they might be. They actively encourage, for example, that
a certain common equality predicate (I can't remember which) be
user-customized. And, I assume, this equality predicate can be used
in hash tables. Yet if one didn't seal that branch of the predicate,
and one could really were to dynamically at runtime, rather than
dynamically at startup (i.e., statically), customize a subclass of an
already known class to hash differently, already stored data in the
hash table might suddenly be in the wrong hash bucket. This would
seem to me to be a mess. Probably this doesn't happen much since
probably those equality predicates are mostly not changed dynamically
during program execution. But CL is optimized for real dynamism--much
more Dylan than, IMO, and making CL leave these things hanging open
for people to abuse would be a problem.
(There are other reasons for not overgenerifying as well.)
In article <··············@thelonious.dyndns.org>,
Russell McManus <···············@yahoo.com> wrote:
> One interesting one I have seen mentioned on c.l.l before is the fact
> that sequence operators are generic functions. So if you write a
> red-black tree, and want to iterate over it using the standard
> operators, you can do it.
True on the idea, but not quite right on the technical detail.
The "for" loop and the various mapping functions are not generic. They
*call* one generic function (forward-iteration-protocol) on the class of
the collection, and that returns a couple of objects and some functions
for stepping through the collection, testing for the end, getting and
setting the current element etc.
With the "for" macro (or a mapping function, if open-coded) and a
statically known collection type, the generic function goes away and the
test and stepping functions are often simple enough to be inlined as
well -- at least in d2c. So not only can you type "for (elt in myCol)
... end" regardless of the type of the collection, if that type is
statically known then the generated code for simple cases such as lists
and strings and vectors is exactly the same as you would hand-code in C.
-- Bruce
> How hard would it be to switch back? CL is gaining traction sexprs and
> all, maybe switching back to the sexpr horse is in order. They sure as
> hell have nothing to lose.
Moderately difficult. At one point I think there was a provision for
supporting both syntaxes in projects, but that was internal to Apple
and commercial versions (as far as I can tell) never had that support.
However, there is one implementation (the Marlais Dylan interpreter)
that supports both the prefix and infix syntax. So switching back to
prefix would involve taking that front-end (if its in decent shape),
getting it up to date with the current spec (its severely out of date)
and getting it to generate d2c's front-end representation (which is
pretty well documented). Some people (on the mailing list) have
expressed interest in a prefix Dylan, but nobody really thinks its
worth it while there are more important things that need to be done.
Kenny Tilton <·······@nyc.rr.com> writes:
>> Another "brilliant" marketing idea that worked so well. IMHO, had
>> they kept
>> the sexpr syntax, ...
> How hard would it be to switch back? CL is gaining traction sexprs and
Switching back completely is out of question: there's quite some Dylan
code out there that won't be changed to another syntax.
> all, maybe switching back to the sexpr horse is in order. They sure as
> hell have nothing to lose.
Well, if somebody came a long and wrote a sexpr parser frontend for
the compiler, we wouldn't mind shipping it with Gwydion. It's not too
hard either, and we can give guidance if wanted.
It's just that the current maintainers of Gwydion are happy enough
with the new syntax, so we focus on more urgent issues, like making
the editor, GUI framework, web server etc. work.
Andreas
P.S.: News about the death of Dylan are greatly exaggerated. Work on
Gwydion Dylan never stopped, and user numbers are growing.
--
"The Board views the endemic use of PowerPoint briefing slides instead
of technical papers as an illustration of the problematic methods of
technical communication at NASA."
-- Official report on the Columbia shuttle disaster.
Andreas Bogk wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>>Another "brilliant" marketing idea that worked so well. IMHO, had
>>>they kept
>>>the sexpr syntax, ...
>>
>>How hard would it be to switch back? CL is gaining traction sexprs and
>
>
> Switching back completely is out of question: there's quite some Dylan
> code out there that won't be changed to another syntax.
>
>
>>all, maybe switching back to the sexpr horse is in order. They sure as
>>hell have nothing to lose.
>
>
> Well, if somebody came a long and wrote a sexpr parser frontend for
> the compiler, ...
yeah, that's what I had in mind.
we wouldn't mind shipping it with Gwydion. It's not too
> hard either, and we can give guidance if wanted.
>
> It's just that the current maintainers of Gwydion are happy enough
> with the new syntax, so we focus on more urgent issues, like making
> the editor, GUI framework, web server etc. work.
those probably matter more to real-world first-users. otoh, a sexpr
syntax option opens a wormhole to a smaller but extremely like-minded
audience: Lispniks.
The danger for Dylan is if folks discover thru Lisp's growing share that
sexprs are preferable to C-style syntax. Then they suffer the horror of
being passed over because they do /not/ have parentheses.
kt
>
> Andreas
>
> P.S.: News about the death of Dylan are greatly exaggerated. Work on
> Gwydion Dylan never stopped, and user numbers are growing.
Great! Time for a Road to Dylan Survey?
k
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
In article <··············@meo-dipt.andreas.org>,
Andreas Bogk <·······@andreas.org> wrote:
> P.S.: News about the death of Dylan are greatly exaggerated. Work on
> Gwydion Dylan never stopped, and user numbers are growing.
Slowly, but yes the trend in page hits, downloads of new releases, and
people turning up on the IRC channel do all seem to be in the positive
direction.
-- Bruce
>Christopher C. Stacy wrote:
>Another "brilliant" marketing idea that worked so well. IMHO, had they kept
>the sexpr syntax, they might have taken mind- (and educational market-)
>share from Scheme (Why teach Scheme when you can have Scheme on steroids?).
>As it is, they now have neither educational nor commercial mind- or
>marketshare. It is a language destined for the scrap heap of computational
I attended Apple Developer Conferences regularly during the early 90s,
and I remember a couple years going to the Dylan presentation. With a
bunch of R&D and marketing behind it, Apple was showing Dylan off like
the "next big thing" for programmers. They gave these great demos,
showing all the dynamism and flexibility of Dylan apps. Of course the
product was never done, it was always only being demonstrated, as
Apple seemed to take a long time to actually finish things in those
days. I remember thinking that none of the things they demonstrated
couldn't be as easily done with MCL (Mac Common Lisp) which was quite
feature rich, mature, fast and stable. And it was an Apple-owned
product that they were selling! If those marketing and R&D dollars had
been spent on that, rather than a new language, they might have
convinced a lot of people to use it, and still be reaping some
benefits. I couldn't understand why Common Lisp was missing from the
presentations. They had this great product, already available, that
could do all those things, and yet ignored it and hyped something that
was years away from being ready.
At the time, the only thing I saw in the demos that Dylan might have
over MCL was being able to deliver smaller executables, and perhaps
some performance improvements (theoretical, since I think it was
always slower, in reality). At that time MCL could deliver a complete
executable that was about 1 meg in size, which seemed pretty big then.
However, I assumed at the time, and it turned out to be the case, that
within a couple years, and before Dylan was ready, improvements in
processor speed and memory size made those pretty much non-issues. The
emegence of Java and VB as highly popular languages pretty much showed
that there are more important language considerations than small and
fast.
I am not commenting on Dylan as a language, whether it would be better
to program in than Lisp (I don't know and never used it). I just
didn't and don't see the point: when you can more easily modify an
existing language to do the things you want to do, and then leverage
all the technology, compilers, development environments, programmer
expertise, existing code base that has already been developed.
Roger Corman
<·····@corman.net> wrote:
>I am not commenting on Dylan as a language, whether it would be better
>to program in than Lisp (I don't know and never used it). I just
>didn't and don't see the point: when you can more easily modify an
>existing language to do the things you want to do, and then leverage
>all the technology, compilers, development environments, programmer
>expertise, existing code base that has already been developed.
I've been under the impression that Apple intended to deploy
applications written in Dylan on the Newton, not just on Macs. (It
might even have been the NewtonOS itself, not just applications.) The
design space for any implementation targeting an early-90s PDA is
going to be pretty constrained... It seems a bit doubtful (I'd love to
be corrected on this) that they could've fit a full CL in there.
--
Juho Snellman
Juho Snellman wrote:
> <·····@corman.net> wrote:
>
>>I am not commenting on Dylan as a language, whether it would be better
>>to program in than Lisp (I don't know and never used it). I just
>>didn't and don't see the point: when you can more easily modify an
>>existing language to do the things you want to do, and then leverage
>>all the technology, compilers, development environments, programmer
>>expertise, existing code base that has already been developed.
>
>
> I've been under the impression that Apple intended to deploy
> applications written in Dylan on the Newton, not just on Macs. (It
> might even have been the NewtonOS itself, not just applications.) The
> design space for any implementation targeting an early-90s PDA is
> going to be pretty constrained... It seems a bit doubtful (I'd love to
> be corrected on this) that they could've fit a full CL in there.
Two versions of NewtonOS were developed in which everything above the
kernel was written in Dylan, except for the graphics primitives. The
first version used Skia (which later evolved into the now-abandoned
graphics libraries called QuickDraw GX), but there were two problems
with Skia: one, it was way too big and complicated, and two, it used its
own GC scheme that interacted in unfriendly ways with the Dylan GC.
That original OS was scrapped for office-political reasons that sound
stupid when repeated, but that's the way things happen sometimes. The
second one was written by a small group of Lisp programmers to see what
Dylan could do on Newton. Turned out it could do a lot--there were some
very cool ideas in there--but it wanted about 640K versus the 200 or
300K the C++ version wanted, and Apple was really trying to keep costs
down every way it could, including by limiting the required memory.
In article <·····················@melkinpaasi.cs.Helsinki.FI>,
······@iki.fi (Juho Snellman) wrote:
> I've been under the impression that Apple intended to deploy
> applications written in Dylan on the Newton, not just on Macs. (It
> might even have been the NewtonOS itself, not just applications.) The
> design space for any implementation targeting an early-90s PDA is
> going to be pretty constrained... It seems a bit doubtful (I'd love to
> be corrected on this) that they could've fit a full CL in there.
An ex-Apple employee who worked on it told me that they did the ARM code
generator, but they didn't manage to get the generated code small enough
to fit in time.
-- Bruce
Roger Corman wrote:
>>Christopher C. Stacy wrote:
>>Another "brilliant" marketing idea that worked so well. IMHO, had they kept
>>the sexpr syntax, they might have taken mind- (and educational market-)
>>share from Scheme (Why teach Scheme when you can have Scheme on steroids?).
>>As it is, they now have neither educational nor commercial mind- or
>>marketshare. It is a language destined for the scrap heap of computational
>
>
> I attended Apple Developer Conferences regularly during the early 90s,
> and I remember a couple years going to the Dylan presentation. With a
> bunch of R&D and marketing behind it, Apple was showing Dylan off like
> the "next big thing" for programmers. They gave these great demos,
> showing all the dynamism and flexibility of Dylan apps. Of course the
> product was never done, it was always only being demonstrated, as
> Apple seemed to take a long time to actually finish things in those
> days. I remember thinking that none of the things they demonstrated
> couldn't be as easily done with MCL (Mac Common Lisp) which was quite
> feature rich, mature, fast and stable. And it was an Apple-owned
> product that they were selling! If those marketing and R&D dollars had
> been spent on that, rather than a new language, they might have
> convinced a lot of people to use it, and still be reaping some
> benefits. I couldn't understand why Common Lisp was missing from the
> presentations. They had this great product, already available, that
> could do all those things, and yet ignored it and hyped something that
> was years away from being ready.
A bunch of people in Apple's ATG used Coral Common Lisp for a lot of
their work. There was some concern that Coral was not strong enough as a
company, and that ATG really wanted Macintosh Common Lisp to stay
around, and so at a certain point those folks decided they had a big
enough budget to make the owners of Coral an offer, and those owners
accepted, and so Coral became Apple Cambridge.
So now ATG has this team of pretty smart language implementors in house,
and had to decide what to do with it. They conceived this idea that they
could design a new programming language that would make all the Lisp
partisans happy, but that would not make the non-Lisp partisans unhappy.
There are allso the perception that Common Lisp andd Smalltalk (the
other popular-in-ATG dynamic language) made it too hard to separate the
development environment from the application, with various real or
imagined bad ramifications, and that the new language would fix that
problem.
And so it did. Dylan distinguished the development environment from the
delivered application more definitely than either Lisp or Smalltalk.
> At the time, the only thing I saw in the demos that Dylan might have
> over MCL was being able to deliver smaller executables, and perhaps
> some performance improvements (theoretical, since I think it was
> always slower, in reality). At that time MCL could deliver a complete
> executable that was about 1 meg in size, which seemed pretty big then.
> However, I assumed at the time, and it turned out to be the case, that
> within a couple years, and before Dylan was ready, improvements in
> processor speed and memory size made those pretty much non-issues. The
> emegence of Java and VB as highly popular languages pretty much showed
> that there are more important language considerations than small and
> fast.
>
> I am not commenting on Dylan as a language, whether it would be better
> to program in than Lisp (I don't know and never used it). I just
> didn't and don't see the point: when you can more easily modify an
> existing language to do the things you want to do, and then leverage
> all the technology, compilers, development environments, programmer
> expertise, existing code base that has already been developed.
I worked on Newton software written in Dylan; the team I was on wrote
everything in prefix Dylan (back when it looked like lisp). It was
great. For a while after that I maintained a macro package called
Pseudodylan that provided in Common Lisp a bunch of things I liked about
Dylan.
mikel <·····@evins.net> wrote:
> And so it did. Dylan distinguished the development environment from the
> delivered application more definitely than either Lisp or Smalltalk.
What were the pros and cons of doing this?
Was this was a more fundamental difference than just shaking the
unused bits out of the tree?
> great. For a while after that I maintained a macro package called
> Pseudodylan that provided in Common Lisp a bunch of things I liked about
Just curious: what became of Pseudodylan? Is it still around somewhere?
Cheers,
-- Nikodemus
Nikodemus Siivola wrote:
> Was this was a more fundamental difference than just shaking the
> unused bits out of the tree?
>
Plain tree-shaking doesn't even do it in a real dynamic language. Remember
that you can construct symbols from user input (and other places) and
invoke the functions on the fly. A static analysis of the code doesn't
work in these cases. You can start with a static analysis and then monitor
the run-time call chain over a set of tests to accumulate dynamic functions
to include, but if your test cases don't happen to impinge on all of the
functions you will ultimately use, you'll get an exception on the deployed
system. In addition, static analysis often grabs too much, getting
functions from code paths that are never executed. Image trimming is still
more a black art than a science.
faa
Nikodemus Siivola wrote:
> mikel <·····@evins.net> wrote:
>
>
>>And so it did. Dylan distinguished the development environment from the
>>delivered application more definitely than either Lisp or Smalltalk.
>
>
> What were the pros and cons of doing this?
At that time one of the things people complained about a lot was that
applications built in Lisp and Smalltalk had the whole development
evnironment rolled up in them. Nobody seems to complain about that
anymore, but in 1990 it seemed to many people a terrible thing,
presumably because at that time a 1MB application seemed overlarge, and
because people were trying to cram many applications onto 40MB hard
disks and 1MB of RAM. There were other arguments about why it was a bad
idea at the time, but all of the arguments seem to have vanished now
that applications are commonly 100MB in size and you can still build
Lisp and Smalltalk apps that are 1MB.
One pro of the design effort the Ralph/Dylan guys did was that they
invented sealing, which enabled application designers to specify both
optimizations and invariants by saying that cetain things weren't
allowed to be redefined dynamically.
One con was that, unlike a Common Lisp environment, you couldn't
blithely assume that any expression you evaluated in the Dylan listener
could be part of your application. Some stuff was Part of the
Development Environment (i.e. not present in a packaged and delivered
application).
> Was this was a more fundamental difference than just shaking the
> unused bits out of the tree?
Back when 1MB seemed large, there was a lot of interest in Lisp and
Smalltalk tree-shakers, and various vendors did a lot of sometimes
clever work on it, but you can't really do it. Lisp and Smaltalk both
allow user code to dynamically construct and compile expressions, and if
your code does that then tree-shaking becomes impossible because you
have no idea what might get constructed and compiled. Since you don't
know what that code does until runtime, you don't know what other code
it does or does not use.
>>great. For a while after that I maintained a macro package called
>>Pseudodylan that provided in Common Lisp a bunch of things I liked about
>
>
> Just curious: what became of Pseudodylan? Is it still around somewhere?
For about five years I didn't write any Lisp code, so Pseudodylan
developed bit rot. The sources are probably lying around in one of my
archives, but I haven't looked at it since about 1995.