Newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.cis.ohio-state.edu!math.ohio-state.edu!howland.erols.net!cam-news-hub1.bbnplanet.com!news.mathworks.com!newsfeed.internetmci.com!in3.uu.net!EU.net!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Common LISP: The Next Generation
Message-ID: <DxGs7J.Gz.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <841391580snz@wildcard.demon.co.uk> <Dx50Mu.2uo.0.macbeth@cogsci.ed.ac.uk> <841846372snz@wildcard.demon.co.uk>
Date: Mon, 9 Sep 1996 12:04:30 GMT
Lines: 65
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:22620 comp.lang.dylan:7179 comp.lang.scheme:16782

In article <841846372snz@wildcard.demon.co.uk> cyber_surfer@wildcard.demon.co.uk writes:
>In article <Dx50Mu.2uo.0.macbeth@cogsci.ed.ac.uk>
>           jeff@cogsci.ed.ac.uk "Jeff Dalton" writes:

>> In any case, while the dice may well _be_ loaded, Lisp systems
>> could preduce much smaller executables than they usually do.
>
>> Indeed, a Lisp could fairly easily produce a "Hello, world!"
>> program that's as small as a C one.  Suppose the source code
>> was:
>> 
>>    (format t "Hello, World!~%")
>> 
>> It doesn't need to alloc anything at run-time, so no GC is needed.
>
>It doesn't need to statically link, either. However, all the
>compiled Lisps I've used have delivered code in a statically
>linked image file.

How about WCL?  It packages Cl itself as a shared library and
presumably allows you to construct shared libraries too.

Anyway, statically linked executables can be small.

>> Ah, soemone will say, what if you write slightly larger
>> programs.  Then you'll have the GC and all that other Lisp
>> stuff.  Probably you will.  But such things can be pretty
>> small.  Most Lisp implementatinos are pretty big these
>> days, but they can be very small.  (N.B. Lisp does not =
>> Common Lisp; but even Common Lisps could produce vastly
>> smaller executables than they typically do.)
>
>Yes, just avoid static linking.

I'm not quite sure just what you have in mind here, but for most
Lisps it's not a simple change.  These Lisps don't use the ordinary
linker/loader.  Instead, code is loaded into a running Lisp and
then an image of the thus modified Lisp is saved.  If, instead,
the compiler could turn Lisp source files into .o files that could
be statically linked with code from various libraries, you could
get much smaller executables despite using static linking.

"Tree shaking" and the like can also help, but work by discarding
rather than by never including in the 1st place.

 I don't know about Unix, but
>a programming language for Win16/Win32 that uses static linking
>only will be seen as a very poor tool. Never mind issues like
>GC performance. Even a _C compiler_ for Win16/Win32 has to
>support dynamic linking in order to be accepted as a serious
>development tool. This isn't a language issue - it's a delivery
>issue. Maybe this is different for Unix, but for Windows, a
>"larger than necessary" binary is considered to be unforgivable.

Humm.  Some of them sure _look_ larger than necessary.

>It's subjective, of course, but both users and developers are
>very sensitive to the code size, and yes, all those enourmous
>Windows apps _are_ heavily criticised for being _too big_. If
>it wasn't for all those features, nobody would put up with it.
>In fact, some people _don't_. That's part of the problem...

ok.

-- jd
