[A86] Re: What about LISP?

To: assembly-86@lists.ticalc.org
Subject: [A86] Re: What about LISP?
From: "David West" <bdaddy_mit@hotmail.com>
Date: Tue, 18 Dec 2001 15:43:51 +0000
Reply-To: assembly-86@lists.ticalc.org

----Original Message Follows----
>To: assembly-86@lists.ticalc.org Subject: [A86] Re: What about LISP? From: 
>"Andreas Finne" <a_finne@hotmail.com> Date: Tue, 18 Dec 2001 13:29:34 +0200 
>Reply-To: assembly-86@lists.ticalc.org
>
>----------------------------------------------------------------------> How 
>would it be with a SCHEME interpreter? As far as I know, SCHEME is used in 
>many schools as the first language in computer science. I > just mean that 
>there (probably) is a lot more people that would find a scheme interpreter 
>useful than a pure lisp interpreter.
>
>Andreas Finne

That's a good point.  But what I'm suggesting isn't neccessarily a "pure" 
LISP interpreter.  What I'm getting at hear is a LISP/SCHEME-like 
interpreter.  I'm not suggesting that we attempt to hold to either the LISP 
or SCHEME specs.  My suggesting transends the particular details of any one 
of the LISP variants.  What I'm suggesting is that we take a look at the 
LISP concepts/sytax/methodologies and see if we can come up with a language 
suitable as a simple, but suffeciently powerful, high level glue that has 
been one of the holy grails of TI calculator programming.

A few examples of what I'm talking about are: (1) A LISP style grammer is 
easy to parse and at the same time arguably capable. So lets try to capture 
this aspect of the language.  (2) Sharing common code among LISP-like 
programs running on the same LISP machine appears to be straight foward.  So 
again, lets try to capture this quality.  (3) By running user programs on 
top of an interpreter it would be feasible to build in generic 
multithreading/processing support.  This is harder for the Z80 because we 
can't change its "wireing", and therefore if someone tries to create a 
simple multi-threading OS, any Z80 asm programming can write a program to 
comprimise it.(either by mistake or on purpose.  No Z80-based protection.).

A possible risk to this sort of scheme(no pun pretended...) would of course 
be effeciency.  But if enough "primitive" operations are made in pure 
assembly, it might be possible to overcome this.  Maybe an 
expandable/reasonable mechanism can be built into the language to allow for 
dynamic installation/management of these raw assembly primitives, while the 
interpreter itself is used only for the high level glue.

An example of what I'm not so concerned about with this interpreter is 
suporting unbounded numbers.  I'm just not concerned about this aspect of 
the language, I would say gut it.

I hope this helps to give a flavor of where I'm trying to go with this idea. 
  What do people think?

later,

David E. West

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx