Just wondering. I do a lot of work with data collection
devices (i.e. PDA's) with limited amounts of memory.
I'm curious as to how small a footprint Lisp can have
and still provide enough functionality to continue to
justify a decision for choosing it over C. Or Forth, for
that matter.
OS's include: DrDOS, MSDOS, PalmOS, and maybe WinCE.
I'm aware that there is a Scheme available for the Palm,
but I'm a newbie, I'll wait till I have a better grasp
of CL.
Cheers,
Geoff
It's not what you can do with it, it's the size that counts!
-- Canada is Big - The Arrogant Worms
In article <··············@corp.supernews.com>, "Geoff Summerhayes"
<·············@hnootsmpaaiml.com> wrote:
> Just wondering. I do a lot of work with data collection devices (i.e. PDA's)
> with limited amounts of memory. I'm curious as to how small a footprint Lisp
> can have and still provide enough functionality to continue to justify a
> decision for choosing it over C. Or Forth, for that matter. OS's include:
> DrDOS, MSDOS, PalmOS, and maybe WinCE. I'm aware that there is a Scheme
> available for the Palm, but I'm a newbie, I'll wait till I have a better
> grasp of CL.
>
> Cheers, Geoff
>
You might want to check out LispMe for the Palm Pilot:
http://www.lispme.de/lispme/
--
David Allen
http://opop.nols.com/
----------------------------------------
A chubby man with a white beard and a red suit will approach you soon.
Avoid him. He's a Commie.
"David Allen" <········@titan.vcu.edu> wrote in message
························@typhoon2.ba-dsg.net...
>
> You might want to check out LispMe for the Palm Pilot:
>
> http://www.lispme.de/lispme/
>
That's the Scheme I was talking about.
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Just wondering. I do a lot of work with data collection
> devices (i.e. PDA's) with limited amounts of memory.
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
> OS's include: DrDOS, MSDOS, PalmOS, and maybe WinCE.
> I'm aware that there is a Scheme available for the Palm,
> but I'm a newbie, I'll wait till I have a better grasp
> of CL.
It can be as big as the available memory. What kind of functionality
you pack in it is a different story :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
On Wed, 28 Feb 2001 16:34:38 -0500, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
>Just wondering. I do a lot of work with data collection
>devices (i.e. PDA's) with limited amounts of memory.
>I'm curious as to how small a footprint Lisp can have
>and still provide enough functionality to continue to
>justify a decision for choosing it over C. Or Forth, for
>that matter.
Scientia used to deliver a Common Lisp program for school timetabling
(Syllabus) on a 4Mb Mac Classic (1991?)
The program was developed using Procyon Common Lisp.
Mark
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
You mean theoretically? Well, at least vintage 1990 MCL (which had
Object Lisp and not CLOS as its OO-addon) was fully usable for
development work on a 8MHz Macintosh SE with 2,5MB RAM (and could
do useful things even with less RAM than that). Note that MCL
ran on non-MMU-machines like this 68000 machine (maybe even
the newest 68k version does). So porting MCL to the Palm OS should
be possible...
--
(espen)
In article <··············@corp.supernews.com>,
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Just wondering. I do a lot of work with data collection
> devices (i.e. PDA's) with limited amounts of memory.
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
Since you are asking how small a functional LISP can be, I just
cannot resist pointing at the ->LISP interpreter at my home page:
http://www.t3x.org/LISP/
<plug>
->LISP is a purely symbolic, single name space LISP interpreter which
runs fine in 80KB of RAM (under DOS). It is properly tail recursive
and features a constant space garbage collector. Source code and lots
of example programs are available.
</plug>
I have no problem justifying its choice over C, but of course, that's
my very very personal decision. ;-)
Bye,
nmh.
--
Nils M Holm <···@t3x.org> -- http://www.t3x.org/
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> ... I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, ...
This question seems to me not to be adequately well specified.
At Symbolics, I worked for a while with the MACSYMA group. It was not just
a symbolic alegbra/calculusz system, but in particular it was also a
programming language. Once, though, we got a customer who wanted to write
programs but not using the whole language, and the customr talked us into
a discount for that. I'm only using 10% of the operators you provide, they
said, so I should only pay 10% of the price. I don't know who sold that
deal but I was very angry. We ended up doig EXTRA work for this customer
to mask out the 90% they didn't want and creating an elaborate scheme for
being able to sell them, on a demand basis, extra symbols if they realized
they needed others "a la carte".
I mention this because it is my feeling that all programs necessarily
use only a subset of the available language. This post uses only a subset
of English. An entire language is often huge, but a deliverable takes
size determined by the use. This post is not as big as the English
dictioray.
The theoretical answer to the question asked above is dependent on
whether you count OS libraries. The C community has been skilled for
years in getting their I/O system pushed back into the operating
system so they don't pay for it in size. It's there pre-loaded and
the individual applications can count on it. Lisps were slow to pick
up on this kind of trick but have been responding finally in the last
decade.
The other issue is whether you're willing to let your development environment
be big and you're only worried about the size of the cross-compiled or
tree-shaken delivery image.
Surely the theoretical answer to "how small a footprint" for a "hello world"
program has to approach 20 or so bytes--a few bytes of setup for a call
to a system-defined write-string, and 12 bytes of string (allowing for a
null or a byte count on the string). Whether any Lisp can deliver that,
I'm not sure, but they ought to be.
Or are you instead asking what the size of a fully loaded and programmable
Lisp with garbage collection is? That's a fair thing to want, but it's not
fair to compare it to a language like C, which hasn't even got the capability.
Or are you instead asking not about the Lisp language but about the specific
available set of implementations at a specific point in time, which is not
a question about languages at all. Languages and implementatios are
commonly confused terminologically in discussios like this. And the result
is that people decide that "Lisp" is deficient (and remember that "lemma"
for later use at an inappropriate time) rather than that "Lisp" has no
available implementations or that "FooLisp 3.7" doesn't yet handle a
particular situation to your particular satisfaction.
Making sure to make clear which of these unrelated questions you're asking
will help to get you the answers that serve both you and the community best.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
>
> This question seems to me not to be adequately well specified.
-----
Part of the problem is the handhelds aren't particularly well specified
either, I have 2 sitting in front of me, both use an 8086 processor,
programs run in a 640K space (16-bit small/medium memory model) with
ram, eeprom and/or flash memory simulating disk space for file and
program storage. I also have a Palm Vx sitting here, just picked it
up last week, haven't had a chance to look at program requirements
under PalmOS yet. PHB's are making noises about WinCE, and, of course,
now there are Linux PDAs coming out.
-----
> At Symbolics, I worked for a while with the MACSYMA group. It was not
just
> a symbolic alegbra/calculusz system, but in particular it was also a
> programming language. Once, though, we got a customer who wanted to write
> programs but not using the whole language, and the customr talked us into
> a discount for that. I'm only using 10% of the operators you provide, they
> said, so I should only pay 10% of the price. I don't know who sold that
> deal but I was very angry. We ended up doig EXTRA work for this customer
> to mask out the 90% they didn't want and creating an elaborate scheme for
> being able to sell them, on a demand basis, extra symbols if they realized
> they needed others "a la carte".
-----
I work at a demand-driven firm, specs are usually dust before the new code
has finished testing. Luckily, we charge the customer for specialization,
but it would be nice to decrease my turnaround time. Right now, I'm caught
in a compile-link-generate-upload-reboot-test cycle and debug versions don't
fit, they're too large. Memory errors are an unbelievable bitch, there was a
rash of C programmer's disease rampant in the shop. The original code is
full of system dependant calls, and is bloated (lots of cut-and-paste
hacks).
I've talked them into a rewrite that will allow me to develop-test on the PC
and then link to a home-grown generalized library tuned to the specific
handheld.
-----
> I mention this because it is my feeling that all programs necessarily
> use only a subset of the available language. This post uses only a subset
> of English. An entire language is often huge, but a deliverable takes
> size determined by the use. This post is not as big as the English
> dictioray.
>
> The theoretical answer to the question asked above is dependent on
> whether you count OS libraries. The C community has been skilled for
> years in getting their I/O system pushed back into the operating
> system so they don't pay for it in size. It's there pre-loaded and
> the individual applications can count on it. Lisps were slow to pick
> up on this kind of trick but have been responding finally in the last
> decade.
>
> The other issue is whether you're willing to let your development
environment
> be big and you're only worried about the size of the cross-compiled or
> tree-shaken delivery image.
>
> Surely the theoretical answer to "how small a footprint" for a "hello
world"
> program has to approach 20 or so bytes--a few bytes of setup for a call
> to a system-defined write-string, and 12 bytes of string (allowing for a
> null or a byte count on the string). Whether any Lisp can deliver that,
> I'm not sure, but they ought to be.
-----
Given the enviroment, tree-shaken would be the obvious way to go. OTOH,
I wouldn't mind having a 'lispier' Lisp than 'LispMe'(Scheme) to use on the
Palm, and I've been thinking about cobbling one together as a home project,
however ugly, slow, and brain-damaged it may be, but as a newbie to
the language, I don't know where to even start. Fun way to learn more
about the language, though. :-)
Off on a tangent, has anyone considered a Lisp-based OS for the PC?
I've read a little about Lisp Machines, just wondering: if it would
be possible, how to handle hardware, etc.
-----
> Or are you instead asking what the size of a fully loaded and programmable
> Lisp with garbage collection is? That's a fair thing to want, but it's
not
> fair to compare it to a language like C, which hasn't even got the
capability.
>
> Or are you instead asking not about the Lisp language but about the
specific
> available set of implementations at a specific point in time, which is not
> a question about languages at all. Languages and implementatios are
> commonly confused terminologically in discussios like this. And the
result
> is that people decide that "Lisp" is deficient (and remember that "lemma"
> for later use at an inappropriate time) rather than that "Lisp" has no
> available implementations or that "FooLisp 3.7" doesn't yet handle a
> particular situation to your particular satisfaction.
>
> Making sure to make clear which of these unrelated questions you're asking
> will help to get you the answers that serve both you and the community
best.
-----
Well, it's very nebulous right now, I find myself shooting off on a lot of
'wouldn't it be nice' and 'what if' tangents. I'm trying to get a clearer
idea of what to expect, before I start thinking about how to achieve it.
I still dream though, compared to the batch-processing, card-deck days,
we've gotten pretty 'trekkish', to coin a phrase.
Geoff
Geoff Summerhayes wrote:
>
> Off on a tangent, has anyone considered a Lisp-based OS for the PC?
> I've read a little about Lisp Machines, just wondering: if it would
> be possible, how to handle hardware, etc.
There was plenty of talk about it a few years ago, with limited success.
Try your favorite search engine on "LispOS".
--
"Martti Halminen" <···············@solibri.com> wrote in message
······················@solibri.com...
> Geoff Summerhayes wrote:
> >
> > Off on a tangent, has anyone considered a Lisp-based OS for the PC?
> > I've read a little about Lisp Machines, just wondering: if it would
> > be possible, how to handle hardware, etc.
>
> There was plenty of talk about it a few years ago, with limited success.
> Try your favorite search engine on "LispOS".
Got it, thanks. Sheesh! A passing thought, and there are websites on it.
Rod Serling must be nearby. ;-)
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> "Martti Halminen" <···············@solibri.com> wrote in message
> ······················@solibri.com...
> ...
> > There was plenty of talk about it a few years ago, with limited success.
> > Try your favorite search engine on "LispOS".
>
> Got it, thanks. Sheesh! A passing thought, and there are websites on it.
> Rod Serling must be nearby. ;-)
It's virtually a theorem on the web:
The likelihood of a topic's being already present on the web in
excruciating detail is directly proportional to how obscure the
topic is.
On Thu, 1 Mar 2001 11:56:35 -0500, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
> Given the enviroment, tree-shaken would be the obvious way to go. OTOH,
> I wouldn't mind having a 'lispier' Lisp than 'LispMe'(Scheme) to use on the
> Palm, and I've been thinking about cobbling one together as a home project,
If you come up with anything usable, please let us know. By the way, if you
are looking for a powerful editor to use with LispMe, you might check the
`pedit' family of shareware text editors (pedit provides some useful
features for editing Lisp code such as text block shifting, automatic--not
syntax-directed--indentation and a monospaced font for easier code
alignment):
http://www.paulcomputing.com/
Disclosure: I am the founder of the Peditors Forum
http://groups.yahoo.com/group/peditors.
> however ugly, slow, and brain-damaged it may be, but as a newbie to
> the language, I don't know where to even start. Fun way to learn more
> about the language, though. :-)
The comp.lang.lisp FAQ, which is no longer being maintained, lists some
still useful resources on implementation issues. You should be able to get
the FAQ at http://www.faqs.org. This should be a good starting point. Of
course, this group is also a good resource if you have specific questions
or problems.
> Off on a tangent, has anyone considered a Lisp-based OS for the PC?
You must be kidding: this is the Holy Grail of Lispers :) You may check
this page:
Lisp Based OSes
http://www.hex.net/~cbbrowne/lisposes.html
> I've read a little about Lisp Machines, just wondering: if it would
Be sure to visit this site:
A few things I know about LISP Machines
http://fare.tunes.org/LispM.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> ha scritto nel
messaggio ···················@corp.supernews.com...
> Part of the problem is the handhelds aren't particularly well specified
> either, I have 2 sitting in front of me, both use an 8086 processor,
> programs run in a 640K space (16-bit small/medium memory model) with
FWIW, muLisp79 could run in a 48KB machine.
And there was even a Lisp for the Commodore64.
For 640KB PCs with msdos existed several implementation of Lisp. Of these,
muLisp probably is still being sold; Texas Instruments PCScheme has been
released for free. With both of these you can accomplish a lot on a small
machine.
Pierpaolo
On Thu, 1 Mar 2001 13:04:54 GMT, Kent M Pitman <······@world.std.com>
wrote:
> At Symbolics, I worked for a while with the MACSYMA group. It was not just
> a symbolic alegbra/calculusz system, but in particular it was also a
> programming language. Once, though, we got a customer who wanted to write
> programs but not using the whole language, and the customr talked us into
> a discount for that. I'm only using 10% of the operators you provide, they
> said, so I should only pay 10% of the price. I don't know who sold that
> deal but I was very angry. We ended up doig EXTRA work for this customer
> to mask out the 90% they didn't want and creating an elaborate scheme for
> being able to sell them, on a demand basis, extra symbols if they realized
> they needed others "a la carte".
:D :D Couldn't resist :)
$ lisp
Dream Machine Lisp 2.4.1 - (C) 2001 Dream Machines Incorporated. All rights
reserved.
Type (help) for info, (quit) to exit. Both symbols are included with the
base product.
Lisp> (sin 0)
Error: The symbol CL:SIN is not currently included in your Lisp image.
To continue, type :CONTINUE followed by an option number:
1: Purchase symbol CL:SIN at 1.95$ (20% off if you also get package
ALGEBRA at 49.95$; you will receive CL:PI with 100 digits for FREE). Be
sure to have your credit card handy.
2: Let a marketing person call you and explain the advantages of using
CL:SIN.
3: Receive by email valuable product information from us.
4: Switch to bignum arithmetic.
5: Specify a value of (SIN 0) to use this time.
6: Return to Lisp Toplevel.
Debug> :continue 6
Returned to Lisp Toplevel.
Lisp> (handler-case (sin 0)
(unlicensed-symbol (condition)
(purchase-symbol (unlicensed-symbol-sym condition)
:credit-card 1234567890123456
:exp-date (encode-universal-time
0 0 0 30 6 2001))))
0.0
Lisp>
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
>
> :D :D Couldn't resist :)
>
> $ lisp
> Dream Machine Lisp 2.4.1 - (C) 2001 Dream Machines Incorporated. All rights
> reserved.
>
> Type (help) for info, (quit) to exit. Both symbols are included with the
> base product.
>
> Lisp> (sin 0)
> Error: The symbol CL:SIN is not currently included in your Lisp image.
> To continue, type :CONTINUE followed by an option number:
> 1: Purchase symbol CL:SIN at 1.95$ (20% off if you also get package
> ALGEBRA at 49.95$; you will receive CL:PI with 100 digits for FREE). Be
> sure to have your credit card handy.
> 2: Let a marketing person call you and explain the advantages of using
> CL:SIN.
> 3: Receive by email valuable product information from us.
> 4: Switch to bignum arithmetic.
> 5: Specify a value of (SIN 0) to use this time.
> 6: Return to Lisp Toplevel.
> Debug> :continue 6
> Returned to Lisp Toplevel.
> Lisp> (handler-case (sin 0)
> (unlicensed-symbol (condition)
> (purchase-symbol (unlicensed-symbol-sym condition)
> :credit-card 1234567890123456
> :exp-date (encode-universal-time
> 0 0 0 30 6 2001))))
> 0.0
> Lisp>
ROTFLMAO!!
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Just wondering. I do a lot of work with data collection
> devices (i.e. PDA's) with limited amounts of memory.
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
I've done a bit of data collection work using the PalmOS platform.
Given that most data collection applications are very regular in their
structure, I probably wouldn't use CL on the device, but rather on the
host and development machines:
a) Use CL to create a domain-specific language for writing data-entry
applications that generates the code of whatever language you let
run on the device, regardless of whether that be C, Scheme, Forth,
or assembly language. If you are careful in designing this, you
can switch between target languages and devices fairly easily.
b) As usual put most of intelligence inside the host, and not the
collection device. Using CL here can be pretty useful, especially
if you can auto-generate the interfacing stuff using the information
contained in the DCL (data-collection language) defined in a).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> wrote in message
···················@orion.bln.pmsf.de...
>
> I've done a bit of data collection work using the PalmOS platform.
> Given that most data collection applications are very regular in their
> structure, I probably wouldn't use CL on the device, but rather on the
> host and development machines:
>
> a) Use CL to create a domain-specific language for writing data-entry
> applications that generates the code of whatever language you let
> run on the device, regardless of whether that be C, Scheme, Forth,
> or assembly language. If you are careful in designing this, you
> can switch between target languages and devices fairly easily.
Nice idea. I'll give this some serious thought.
> b) As usual put most of intelligence inside the host, and not the
> collection device. Using CL here can be pretty useful, especially
> if you can auto-generate the interfacing stuff using the information
> contained in the DCL (data-collection language) defined in a).
Unfortunately, in some cases, they buy the handheld but not the main app,
so it has to support report generation, etc. Still, it would be nice to
auto-generate the report code, hand-tooled C reports are a pain. Looks
like a reasonable weekend project.
Geoff
From: Tim Bradshaw
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <nkjwva92yls.fsf@tfeb.org>
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Just wondering. I do a lot of work with data collection
> devices (i.e. PDA's) with limited amounts of memory.
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
I agree with everything Kent said about the lack of meaning to this
question.
But...
In 1987 I had mulisp on a MSDOS machine with 512k of memory. I ported
LAm -- an algebra package for general relativity -- to this platformm
and used it to compute some non-trivial things. It took a while --
many hours -- but it worked. Mulisp still exists -- I think it is
free now -- and probably still runs happily in machines with 256k or
less. It includes an object suytem based on flavors, and an editor,
and (witness the above), you can run reasonably non-trivial programs
in it.
Things related to mulisp run in TI calculators.
--tim
"Tim Bradshaw" <···@tfeb.org> wrote in message ····················@tfeb.org...
>
> I agree with everything Kent said about the lack of meaning to this
> question.
>
> But...
>
> In 1987 I had mulisp on a MSDOS machine with 512k of memory. I ported
> LAm -- an algebra package for general relativity -- to this platformm
> and used it to compute some non-trivial things. It took a while --
> many hours -- but it worked. Mulisp still exists -- I think it is
> free now -- and probably still runs happily in machines with 256k or
> less. It includes an object suytem based on flavors, and an editor,
> and (witness the above), you can run reasonably non-trivial programs
> in it.
>
> Things related to mulisp run in TI calculators.
>
I'll look for it, thanks.
Geoff
From: Jeff Sandys
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <3A9ED8CF.F5B325E1@asme.org>
> > I'm curious as to how small a footprint Lisp can have
LispMe (a version of Scheme) runs on a Palm in 55k
> In 1987 I had mulisp on a MSDOS machine with 512k of memory.
Softwarehouse also made muSimp, a symbolic algebra package,
that ran on an Apple II with 64k. KeyLisp also ran on
the Apple II.
> Things related to mulisp run in TI calculators.
The HP48sx (that I refer to as "Macsyma on a stick")
does symbolic math with it's 4bit data, 24bit address
Saturn processor. These calculators also have data
logging capabilities, with accessories.
The Ti calculators that run CAS (Computer Algebra
System) use a variant of the 68000 microprocessor,
and so do Palm Pilots.
From: Tim Bradshaw
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <nkjpug0gyif.fsf@tfeb.org>
Jeff Sandys <·······@asme.org> writes:
>
> The Ti calculators that run CAS (Computer Algebra
> System) use a variant of the 68000 microprocessor,
> and so do Palm Pilots.
yes, I think CAS is actually musimp or somehow related to it --
certainly TI bought soft warehouse I think.
--tim
On Thu, 1 Mar 2001 23:18:39 GMT, Jeff Sandys <·······@asme.org> wrote:
> LispMe (a version of Scheme) runs on a Palm in 55k
How do you get that figure? The latest LispMe executable is about 97K, and
it also needs a heap (you can't do much with the smallest 1K heap option).
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Jeff Sandys
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <3AA03495.38059AD1@asme.org>
Paolo Amoroso wrote:
>
> On Thu, 1 Mar 2001 23:18:39 GMT, Jeff Sandys <·······@asme.org> wrote:
>
> > LispMe (a version of Scheme) runs on a Palm in 55k
>
> How do you get that figure? The latest LispMe executable is about 97K, and
> it also needs a heap (you can't do much with the smallest 1K heap option).
Older version 1.something, size listed in info, heap size was fixed back
then.
97k is still a small footprint considering the features in the latest
version.
In article <·················@asme.org>, Jeff Sandys <·······@asme.org> wrote:
>> > I'm curious as to how small a footprint Lisp can have
>
>LispMe (a version of Scheme) runs on a Palm in 55k
>
A long time ago, I was running CP/M on my TRS-80 Model 4 with 64K
of memory, and bought a Lisp that ran on it. Unfortunately, I don't
remember its name or minimum system requirements, so I don't know
if it was smaller.
I *might* still have my old copy of Dr. Dobb's Journal that has a
Lisp written in 6502 machine language (for those who wanted to type
it in) that IIRC ran on the author's machine with (IIRC) 32K or 40K
of memory (and likely on nobody else's machine). I'd have to find
the article to see its capabilities.
Obviously, neither of these conformed to the Common Lisp specification.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
In article <····················@ruti.visi.com>, ········@visi.com (David
Thornley) wrote:
>In article <·················@asme.org>, Jeff Sandys <·······@asme.org> wrote:
>>> > I'm curious as to how small a footprint Lisp can have
>>
>>LispMe (a version of Scheme) runs on a Palm in 55k
>>
>A long time ago, I was running CP/M on my TRS-80 Model 4 with 64K
>of memory, and bought a Lisp that ran on it. Unfortunately, I don't
>remember its name or minimum system requirements, so I don't know
>if it was smaller.
The Lisp I ran on my Kaypro was called Waltz Lisp; I think it said it
could run in 48, but it probably lied if so. It was very sweet, and you
could do anything you could do with a few thousand cons cells...
I wrote a print formatter/spooler to emulate the local mainframe
system (example of Lisp as a convenient system-level language)
I miss Waltz in some ways
paul
In article <···················@192.168.1.100>,
Paul Wallich <··@panix.com> wrote:
>In article <····················@ruti.visi.com>, ········@visi.com (David
>Thornley) wrote:
>
>The Lisp I ran on my Kaypro was called Waltz Lisp;
Thank you! I just couldn't remember the name.
I think it said it
>could run in 48, but it probably lied if so. It was very sweet, and you
>could do anything you could do with a few thousand cons cells...
>I wrote a print formatter/spooler to emulate the local mainframe
>system (example of Lisp as a convenient system-level language)
>
The big problem I ran into was the editor: I didn't have a paren-matching
editor and I found out that the structure editor really didn't work well
if you lost count and just added close parens on the end of your
expression.
>I miss Waltz in some ways
>
It was fun, but I don't know that I miss it, given that I have a copy
of MCL.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
In article <··················@ruti.visi.com>, ········@visi.com (David
Thornley) wrote:
>In article <···················@192.168.1.100>,
>Paul Wallich <··@panix.com> wrote:
>>In article <····················@ruti.visi.com>, ········@visi.com (David
>>Thornley) wrote:
>>
>>The Lisp I ran on my Kaypro was called Waltz Lisp;
>
>Thank you! I just couldn't remember the name.
>
> I think it said it
>>could run in 48, but it probably lied if so. It was very sweet, and you
>>could do anything you could do with a few thousand cons cells...
>>I wrote a print formatter/spooler to emulate the local mainframe
>>system (example of Lisp as a convenient system-level language)
>>
>The big problem I ran into was the editor: I didn't have a paren-matching
>editor and I found out that the structure editor really didn't work well
>if you lost count and just added close parens on the end of your
>expression.
>
>>I miss Waltz in some ways
>>
>It was fun, but I don't know that I miss it, given that I have a copy
>of MCL.
Ha! What I miss, now that I think about it, is not so much Waltz
itself as the relatively clean (because spartan) interface between
it and the CP/M OS. If I wanted to redirect input or output, for
example there wasn't nearly the twiddling that a Mac
requires when you want to send something to a printer or accept
data from the serial port. (There wasn't the power either, but for
some purposes that was OK.)
paul
> A long time ago, I was running CP/M on my TRS-80 Model 4 with 64K
> of memory, and bought a Lisp that ran on it. Unfortunately, I don't
> remember its name or minimum system requirements, so I don't know
> if it was smaller.
The Atari 400/800 had a port of Interlisp, by Datasoft if I recall.
It was moderately stripped, notably missing format, hashes and a few
other goodies. I <think> it didn't implement much beyond defun and
defmacro. On the other hand it did expose the Atari ROM graphics and
I/O subsystems as primitives. I believe it also implemented a couple
routines for interfacing to assembly routines.
Nevertheless it did work, and ran as an Atari DOS executable, meaning
the executable size was on the order of 32k- likely a bit less. I
booted it a couple months back, from the ~18 yr old floppy...
Gregm
From: Tim Bradshaw
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <ey3elwao3iz.fsf@cley.com>
* David Thornley wrote:
> I *might* still have my old copy of Dr. Dobb's Journal that has a
> Lisp written in 6502 machine language (for those who wanted to type
> it in) that IIRC ran on the author's machine with (IIRC) 32K or 40K
> of memory (and likely on nobody else's machine). I'd have to find
> the article to see its capabilities.
There was a Lisp for the BBC Micro, which I guess was a 32K ROM and
can't have used more than 32k of memory because it didn't have more
than that.
--tim
"David Thornley" <········@visi.com> wrote in message
·························@ruti.visi.com...
> In article <·················@asme.org>, Jeff Sandys <·······@asme.org>
wrote:
> >> > I'm curious as to how small a footprint Lisp can have
> >
> >LispMe (a version of Scheme) runs on a Palm in 55k
> >
> A long time ago, I was running CP/M on my TRS-80 Model 4 with 64K
> of memory, and bought a Lisp that ran on it. Unfortunately, I don't
> remember its name or minimum system requirements, so I don't know
> if it was smaller.
I learned Lisp with LeLisp on a TRS80 Model 1 (1.77MHz 8 bit Z80 processor)
with 48K of RAM.
No CLOS for sure but I played with actor and flavors on it.
Marc
On Wed, 28 Feb 2001 16:34:38 -0500, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
> OS's include: DrDOS, MSDOS, PalmOS, and maybe WinCE.
There has been a recent thread (subject "Computer Algebra System for Palm",
message ID ·················@my-deja.com) in newsgroup:
news://news.massena.com/pilot.programmer
that raised the issue of how difficult would it be to port CLISP
http://clisp.sourceforge.net to Palm OS. There is no advanced computer
algebra system running on Palm OS, so the original poster hoped of porting
CLISP to the Palm environment in order to run DOE-Macsyma on top of CLISP.
The original poster finally decided not to pursue the project because it
would have been too much work for him to port CLISP, and having DOE-Macsyma
on the Palm would not be worth the effort given the availability of cheap
CAS calculators such as the TI-89.
Among the technical challenges mentioned by the poster is the need for
splitting the Lisp runtime into a few tens of shared libraries, each of
which containing a chunk of at most 32K of code. This is a Palm OS
limitation, and there are others that make it tricky to develop large
applications despite the availability of devices with 8M of RAM or more.
But this may not be a problem for you because you are interested in the
lower bound on application footprint. In the context of the above mentioned
thread, Ralf Kleberhoff, the author of the Jump Java compiler for Palm OS,
said that more than a dozen years ago he ported Kyoto Common Lisp to
OS-9/68000, whose restrictions were similar to Palm OS's.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
>
> There has been a recent thread (subject "Computer Algebra System for Palm",
> message ID ·················@my-deja.com) in newsgroup:
>
> news://news.massena.com/pilot.programmer
>
> that raised the issue of how difficult would it be to port CLISP
> http://clisp.sourceforge.net to Palm OS. There is no advanced computer
> algebra system running on Palm OS, so the original poster hoped of porting
> CLISP to the Palm environment in order to run DOE-Macsyma on top of CLISP.
>
> The original poster finally decided not to pursue the project because it
> would have been too much work for him to port CLISP, and having DOE-Macsyma
> on the Palm would not be worth the effort given the availability of cheap
> CAS calculators such as the TI-89.
>
> Among the technical challenges mentioned by the poster is the need for
> splitting the Lisp runtime into a few tens of shared libraries, each of
> which containing a chunk of at most 32K of code. This is a Palm OS
> limitation, and there are others that make it tricky to develop large
> applications despite the availability of devices with 8M of RAM or more.
>
> But this may not be a problem for you because you are interested in the
> lower bound on application footprint. In the context of the above mentioned
> thread, Ralf Kleberhoff, the author of the Jump Java compiler for Palm OS,
> said that more than a dozen years ago he ported Kyoto Common Lisp to
> OS-9/68000, whose restrictions were similar to Palm OS's.
>
Gives me some places to look, thanks.
Geoff
It might also be worth to check up on some of the C based (as in
compiling lisp to C and then compiling the C to object code) systems.
One is ECL, which stands for Embedded Common Lisp. The original
project seemed to have died out, but as reported in another thread, has
been revived in Spain. Cliki gives the following URL:
http://matematicas.uclm.es/~jjgarcia/ecls.html
Another contender would be GCL (Gnu Common Lisp).
http://www.gnu.org/software/gcl/gcl.html
And there is the Eclipse compiler which does the same, and claims to
produce readable C, but whos commercial fate seems very uncertain.
http://www.elwoodcorp.com/eclipse-info/index.htm
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: Dorai Sitaram
Subject: Re: How small can a functional Lisp be?
Date:
Message-ID: <97o6v7$l0r$1@news.gte.com>
Kenneth Forbus (coauthor, _Building Problem Solvers_)
was recently asking around in comp.lang.scheme if
anybody had written a compatibility package or other
sort of jury-riggery for a Win CE Scheme implementation
that would help run the Common Lisp code in his book.
The CL used by BPS could be characterized as (- CLtL2
CLOS packages), or even (- CLtL1 packages). Even so, I
don't think he's had any luck yet in his quest, but you
could scan for his post in c.l.scheme or check
with him at forbus at nwu.edu.
--d
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
> Just wondering. I do a lot of work with data collection
> devices (i.e. PDA's) with limited amounts of memory.
> I'm curious as to how small a footprint Lisp can have
> and still provide enough functionality to continue to
> justify a decision for choosing it over C. Or Forth, for
> that matter.
> OS's include: DrDOS, MSDOS, PalmOS, and maybe WinCE.
> I'm aware that there is a Scheme available for the Palm,
> but I'm a newbie, I'll wait till I have a better grasp
> of CL.
[Note: here I talk about a version of ECLS not yet released. I am
currently working out the debugger and all of the toplevel, since
the introduction of the bytecode compiler breaks it all.]
With the latest bytecode interpreter and compiler, ECLS gets the bare
Lisp at 1.9Mb when fully interpreted --that is, only bytecodes and no
native code--. With CLOS this rises up to 2.5Mb fully interpreted.
In any case, I suspect there is a big overhead because of the x86
platform and because of statically linking the C library, which should
cut it down to 1.5Mb. Then again, some other parts can be removed,
such as the inspector, but I do not think you'll gain much.
Probably the biggest improvement would come with more packed byte
codes (current implementation uses one word per instruction) and with
a better garbage collector. The default one is a simple mark & sweep
gc, with no relocation, and it seems to leave more holes than I would
like. Using Boehm's one is even worse, since it turns a 2Mb image into
a 6Mb one.
Regards
Juanjo
--
Juan Jose Garcia Ripoll www: http://matematicas.uclm.es/~jjgarcia/
Dpto. de Matematicas job: ········@ind-cr.uclm.es
E.T.S.I. Industriales home: ····@arrakis.es
Univ. de Castilla-La Mancha, Ciudad Real E-13071 (Spain)
Juan Jose Garcia Ripoll <········@ind-cr.uclm.es> writes:
> "Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> writes:
>
> > Just wondering. I do a lot of work with data collection
> > devices (i.e. PDA's) with limited amounts of memory.
> > I'm curious as to how small a footprint Lisp can have
> > and still provide enough functionality to continue to
> > justify a decision for choosing it over C. Or Forth, for
> > that matter.
> > OS's include: DrDOS, MSDOS, PalmOS, and maybe WinCE.
> > I'm aware that there is a Scheme available for the Palm,
> > but I'm a newbie, I'll wait till I have a better grasp
> > of CL.
>
> [Note: here I talk about a version of ECLS not yet released. I am
> currently working out the debugger and all of the toplevel, since
> the introduction of the bytecode compiler breaks it all.]
>
> With the latest bytecode interpreter and compiler, ECLS gets the bare
> Lisp at 1.9Mb when fully interpreted --that is, only bytecodes and no
> native code--. With CLOS this rises up to 2.5Mb fully interpreted.
>
> In any case, I suspect there is a big overhead because of the x86
> platform and because of statically linking the C library, which should
> cut it down to 1.5Mb. Then again, some other parts can be removed,
> such as the inspector, but I do not think you'll gain much.
>
> Probably the biggest improvement would come with more packed byte
> codes (current implementation uses one word per instruction) and with
> a better garbage collector. The default one is a simple mark & sweep
> gc, with no relocation, and it seems to leave more holes than I would
> like. Using Boehm's one is even worse, since it turns a 2Mb image into
> a 6Mb one.
>
EcoLisp (and all the KCL lineage) have not been up to speed as far ans
ANSI compliance goes.
What progress in that respect do you report?
Also. IMHO you shouldn't even think to make CLOS optional.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Juan Jose Garcia Ripoll <········@ind-cr.uclm.es> writes:
>
> > [Note: here I talk about a version of ECLS not yet released. I am
> > currently working out the debugger and all of the toplevel, since
> > the introduction of the bytecode compiler breaks it all.]
[...]
> EcoLisp (and all the KCL lineage) have not been up to speed as far ans
> ANSI compliance goes.
>
> What progress in that respect do you report?
As far as I'm aware Juan has made quite a number of improvements in
this area, and is actively working on bringing ECLS towards ANSI
compliance.
ECLS is a much more capable and compliant CL implementation than AKCL
and GCL!
Even if I only take a look at the 0.0g version from early 2000, ecls
handles defpackage, complex loop, CLOS, modern eval-when, etc.,
whereas e.g. GCL handles none of these out of the box.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein