[A86] Re: What about LISP?
[Prev][Next][Index][Thread]
[A86] Re: What about LISP?
On Wed, Dec 19, 2001 at 05:43:35AM +0000, David West wrote:
> Well yeah sure. I realize that I used SCHEMEish keywords in that
> example. But once again, the idea that I'm trying to bring up is
> independent of any particular LISP dialect. I'm suggesting the
> creation of a LISP-like language that might server as some sort of
> high-level glue and maybe provide other usefull qualities.
Glue for what?
> Well, all programs have "garbage collection" in some form or another.
> That is, any intersting program contains dynamically allocated data,
> and as a result need to allocate and manage this data. In languages
> that don't have garbage collection, this functionality is built into
> the program, in languages like LISP, it is usually built into the
> interpreter in some easily recognizable form. The point of my argument
> is to say that formalized garbage collection isn't neccessarily a bad
> thing cause every intersting program does it either explicitly or
> implicitly anyway. What do you think?
It's simply not true that any interesting program contains dynamically
allocated data. I'd bet that 90% of programs written for the TI-86 use
only static and automatic (stack) storage. On the TI-89, that number
will certainly be lower, because the OS provides support for basic
dynamic memory management.
It's also not the case that all programs have 'garbage collection.' At
least the way the term is currently used in the computer science
community, manual memory management doesn't count as 'garbage
collection.' Of course, it's entirely possible to write a garbage
collector for Scheme on the 86. I was just pointing out that it has
nontrivial costs, both in terms of efficiency and complexity of the
project.
> I agree with the first part. As for the "and interpreted environment
> ... too slow for anything usefull". Once again this statement somehow
> assumes that interpretation adds unmanagable overhead.
Perhaps I was too harsh in my last message: the overhead of an on-calc
interpreter is not unmanagable and doesn't disqualify the project by any
means. But the origin of this thread, IIRC, was about a new language
that could produce code just about as fast as hand-written assembly. My
point was that no Scheme syetem (interpreter or compiled) would do that.
That's not to say it wouldn't be useful for things other than games,
like text-based programs, symbolic manipulators (as someone else pointed
out), etc.
> Every single program ever written is interpreted on some level. C
> programs eventually get "interpreted" by the target processor. Just
> because you build an interpreter on top of another interpreter doesn't
> mean you have to lose a lot (whatever "a lot" means) of computational
> capability. In fact a higher-level interpreter stands to lose even
> less because of the extra computational power that each interpreted
> "unit" is able to perform as compared to the smallest computational
> unit of the lower-level interpreter. The argument I'm attempting to
> make here is that the amount of computation per unit time that takes
> place in an interpreted assembly program "can be" comprable to that of
> an interpreted LISP (or any other higher-level) program run on the
> same platform.
The distinction I was trying to make is between these two scenarios,
both of which are, in theory, possible to implement on the 86:
An "interpreter" that would be a single 86 program variable that would
read Scheme text in 86 string variables and run it. This would allow
easy on-calc development.
A "compiler" that would run on a computer and translate Scheme text into
a 86 program variable that you would transfer to your calc and run
directly, without requring any other files. On-calc development would be
impossible with this system.
(Both of these would have access to a library of common routines
implemented in hand-tuned assembly. Whether they're statically or
dynamically linked won't make much difference.)
I predict something implementing the first option would run programs
about as fast as TI-Basic programs, which is fast enough for some
things, but not fast enough for a lot.
Something implementing the second could produce programs that run fast
enough for most things, but still probably not fast enough for action
games.
Of course, there are options in between the two extremes. Many modern
Scheme systems compile to bytecode, and then run the bytecode on a
mini-interpreter. That might be easier to implement than a true
compiler, and more importantly, it might take less memory too.
> The main goal that I hope to accomplish with the above arguments is to
> persuade my fellow colleges that a LISP system could be made that
> doesn't require us to sacrafise the computational ability of the
> calcs. At least I hope this is the case. (I'm still trying to convence
> myself that this is possible).
I'm not sure what you mean by 'computational ability.' Certainly
programs written in Scheme will be more expressive than those written in
assembly, and they will be able to do anything that assembly programs
can do (except crash the calculator :) ). They'll just do it some amount
slower.
--David
References: