In article <······················@sharebase.com>
····@airplane.sharebase.com (Scot Dyer) writes:
>I think the lack of exceptance of LISP as a language goes all the way back to
>the first LISPs, which _were_ pigs.
I don't get it. I love Common Lisp, but it seems like a pig
*now*. I work mostly in MS-DOS, where size is a bigger issue
than in some operating systems. My understanding is that it's
not possible to implement a Common Lisp within DOS's 640K limit,
so any CL running in vanilla DOS (without e.g. Windows or
Desqview) has to implement its own memory extender technology, of
one sort or another. Look, I know that that 640K is probably
only enough for a CPU cache for a lot of you. But as an example,
Turbo C++, which implements the entire C++ ANSI standard, or
something close to it runs in 640K without any swapfile or funny
memory tricks (I think).
(BTW, the fact that there are more MS-DOS systems in the world
than anything else is probably one factor pushing programmers
away from any language that doesn't run efficiently in MS-DOS.)
Further, it's my impression that a Lisp program which is compiled
into a stand-alone executable is kindof huge--on any system.
(Though I'd be happy to be corrected). In my book, if a "Hello
World" takes up more than 400K, you've got a hog language
(although it might be a beautiful and powerful hog, all the same
:).
So why can't CL be compiled like C, with unused functions left
out of the resulting executable? Or is this done already, and
the executables are still big?
I might mention also, that it strikes me that making *every*
variable include pointers to not just a value, but also to a
function value, a property list, and a documentation string,
seems handy but a hoggy way to store data. Describe this stuff a
run of the mill C programmer, and they'll never even think about
trying Lisp for real work.
OK, I've had my say. Now please correct my ignorance. I really
want to know more about this stuff.
Marshall Abrams
In article <······················@midway.uchicago.edu> ····@midway.uchicago.edu writes:
>So why can't CL be compiled like C, with unused functions left
>out of the resulting executable? Or is this done already, and
>the executables are still big?
Everyone has been talking all this time about how Lisp's ability to manipulate
Lisp code is such a wonderful thing. However, this complicates the removal of
unused functions no end, as you never know when the Lisp code is going to cons
up some Lisp code that contains functions you removed.
The combination of an immense standard library with the ability to use any of
those functions on the fly makes building small executables in Common Lisp
literally impossible. Of course, if you allow the creation of executables
which support a subset of Common Lisp, you'll offend some people who think
that Common Lisp is the Truth, the Light and the Way.
Don't get me wrong, I think that Common Lisp is a fine language. I just
happen to think that if you want small, efficient, stand-alone executables,
you want to be closer to the machine level than Lisp is inclined to let you
get.
Keith Steiger
(who is trying to avoid Scheme at the home of MacScheme)
"If there is a good all-around language, I haven't seen it yet."
In article <······················@cs.uoregon.edu> Keith Steiger,
·····@obelix.cs.uoregon.edu writes:
>Don't get me wrong, I think that Common Lisp is a fine language. I just
>happen to think that if you want small, efficient, stand-alone
executables,
>you want to be closer to the machine level than Lisp is inclined to let
you
>get.
I agree with your comment. However, as machines get faster and memory
gets
cheaper, the need to work close to the machine diminishes. For instance,
few program exclusively in assembly language. Why? Because no one wants
to
get *that* close to the machine :-) I happily and productively programmed
a
Lisp machine for many years before I discovered its "byte" size. Contrast
this with the problems generated by the unhappy fact that one C's int may
have a different size than another's. A programmer is better off the
further away he stays from the machine. The machine is a disease: avoid
it
whenever you can. Practise safe hex: program in Lisp.
Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
····@cornell.edu
607-255-7008
····@quads.uchicago.edu (Marshall Abrams) writes:
>In article <······················@sharebase.com>
>····@airplane.sharebase.com (Scot Dyer) writes:
>>I think the lack of exceptance of LISP as a language goes all the way back to
>>the first LISPs, which _were_ pigs.
>
>I don't get it. I love Common Lisp, but it seems like a pig
>*now*. I work mostly in MS-DOS, where size is a bigger issue
>than in some operating systems. My understanding is that it's
>not possible to implement a Common Lisp within DOS's 640K limit,
>so any CL running in vanilla DOS (without e.g. Windows or
>Desqview) has to implement its own memory extender technology, of
>one sort or another. Look, I know that that 640K is probably
>only enough for a CPU cache for a lot of you. But as an example,
>Turbo C++, which implements the entire C++ ANSI standard, or
>something close to it runs in 640K without any swapfile or funny
>memory tricks (I think).
I think I should correct a few misconceptions.
There is no such thing as a ANSI standard for C++. (There is one
in the works, but it is still a long way from completion.)
The closest thing to a standard is the C++ annotated reference manual.
Turbo C++ does not implement the entire C++ language (as defined by the
reference manual). It is missing a couple of key features, namely templates
and exceptions. (Maybe recent releases implement templates, I'm not sure.)
Turbo C++ does use "funny memory tricks": it uses Borland's so-called
'VROOMM' technology, which is basically an automatic overlay manager
which gives virtual memory for the code space, but not the data space.
Code that needs to be reloaded is loaded directly from the executable file,
so there is no need for a swapfile.
And worst of all, recent releases of Borland's C++ compilers REQUIRE
a 286 with at least 1M of expanded memory (in addition to the base 640k).
--
Fergus Henderson ···@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!