Lisp in Basic

[Charles Pegge]

Thanks Mike,

We must find some interesting things to do with all this LISP. I am inclined to use it for high level tasks which are cumbersome in BASIC, but delegate all the hardcore graphics and API work to BASIC functions. Will your implementation work as part of such a hybrid?

PS: I think classical globals, gosub and goto are beneficial in the context of a compiler or interpreter. O2 uses some 250 global state variables, which is perfectly manageable. LeanLisp uses only 18 so far!

[Mike Lobanovsky]

Charles,

As long as OxyLISP and FBLisp (re-written in DynC) stay as include files for other projects, they can interact easily with other parts of the project programmatically as soon as we add a LISP command that would allow BL to run LISP code from memory rather than keyboard or file only, and provide the corresponding returns to the BASIC caller. I hope there is some such standard command in the Scheme vocabulary. Also, OxyLISP and FBLisp can enjoy in their engines whatever the respective BASIC's have to offer natively, for example, graphics.

This isn't however the case with SBLisp. It can't stay as is in this interpretative form as an include file because it will be too slow. So it must be re-written in C either directly or via CBASIC and compiled as a dynamic library extension. Then it will be able to communicate with its SB host via the same exec-from-memory mechanism but it will have to have its own intrinsic bindings to the other SB luxuries such as e.g. SB's IUP graphics.

Or SBLisp can stay as a CBASIC or C include file for C-based SB projects where SB is used as an embeddable engine. Then it could enjoy common resources, e.g. IUP graphics again, that have their bindings with such a C language based project as a whole.

I don't see any reason why it shouldn't or couldn't be done like that.

[JRS]

This isn't however the case with SBLisp. It can't stay as is in this interpretative form as an include file because it will be too slow. So it must be re-written in C either directly or via CBASIC and compiled as a dynamic library extension. Then it will be able to communicate with its SB host via the same exec-from-memory mechanism but it will have to have its own intrinsic bindings to the other SB luxuries such as e.g. SB's IUP graphics.

Or SBLisp can stay as a CBASIC or C include file for C-based SB projects where SB is used as an embeddable engine. Then it could enjoy common resources, e.g. IUP graphics again, that have their bindings with such a C language based project as a whole.

I don't see any reason why it shouldn't or couldn't be done like that.

Hi Mike,

Sounds like interesting and exciting stuff going on with the BASIC Lisp project. Just to be clear, the SBLisp version initially was done as an exercise to see how QB compatible SB might be. I would like to see the SBLisp version be used as a prototyping tool for Scheme and a teaching aid. As you said many times, this phase of the project is about functionality and stability. Speed would come later. If you have time to keep the SB version current with your efforts in BL, that would be great. I have no plans converting it to C BASIC or making an ext. module out of it. I'm very happy with TinyScheme as it was designed from the ground up as an embeddable small footprint Lisp scripting engine.

Let me know if there is anything I can do to help the BASIC Lisp project along.

John

[Mike Lobanovsky]

Hi John,

Thanks for making me aware of your decision. If it is definitive then I will confine myself exclusively to updating SBLisp to the current functionality of FBLisp proto and uploading it here. Then I will proceed with the development of FBLisp and OxyLISP only.

I am glad you have finally made your choice. There is nothing much left to do with the proto so I think I will be able to finalize it myself. Thanks for offering help though.

Mike

[Mike Lobanovsky]

Charles and Rob,

How would you comment on this flagrant contradiction between C, O2 and FBSL maths, on the one hand, and Scheme math, on the other? The second snapshot is taken from the r6rs standard of the Scheme language.

Please note that Scheme's remainder behaves exactly like our beloved mod whereas if I implement my own remainder for BL as I understand it should work, it will behave exactly like Scheme's modulo.

Please advise what I should do. I am totally confused and baffled...

.

[RobbeK]

Hi Mike ,

The showed results are exact for Lisp -- they are based on (floor ) which "truncates" towards negative infinity , while (truncate ) "truncates" towards zero.   I think you already made a comment on (floor ) and (ceiling ) pointing at this oddity (?)

best, Rob

[Mike Lobanovsky]

Rob,

Should I understand your answer as an indication that I should follow the r6rs standard and just make the BL users aware that Scheme's modulo is not the same as C/BASIC mod?

If so then I will be using BASIC mod as remainder in BL and I will add my own code as BL's Scheme-compatible modulo.

Is that correct?



P.S. And what concerns rounding modes floor, ceiling, round, truncate and abs: I made them behave exactly as per r5rs/r6rs standards. I'm currently following the r5rs standard which defines what is called Scheme's core language as opposed to everything else that's been added in r6rs as library extensions.

Luckily do, begin and named let do fall into the r5rs frame of core language vocabulary, whereas while and others aren't included in it.

[RobbeK]

Hi Mike,

Yes, that seems a sensible solution -- it should be clearly explained in the documentation , &  both Lisp & C/Basic users should be satisfied this way imho.

best Rob

[Mike Lobanovsky]

Understood. I will follow your advice.

[RobbeK]

Hi all,

Also posted under TinyScheme - Open Forum.
Smart solutions : to speed up things a memoizing table is made , the one posted on TinyScheme contained 1000 "anchor - points" , here 500 , but that's about the limit for the NewLisp stack. (i mean for double recursive calculations)

The memo table is set up in blocks of 200 using it previous memoized result.
A sample with n!  (writes easier , but it's the same)
p.e. 10! is memoized , and then 20! becomes 20*19*...*11*10!   etc...   calculations are done exactly the same way -- it calculates till a memoized value is encounterd (max 199 thus in this case).
It should also show the compactness and power of Lisp --  (memoize   ) is written as a macro and can be applied on any definition

best Rob  (one remaining problem : every entry will set up a new memo anchor --  needs unmemoize then I think 

.

[Mike Lobanovsky]

Hi Rob,

What you posted is a very nice example of using a table of cached values. I submitted another example here based on the C code that John had posted earlier.

We simply didn't know at that time that LISP's caching is called memoization.

[Mike Lobanovsky]

Hi all,

I'm here just to let you know that I'm safe and sound. I'm still working on the BL proto making it more Scheme-compliant. Much has been done but one major improvement is still pending.

Arthur's Lisp-in-Basic is a command line interpreter that re-parses and re-evaluates each line whenever it is entered via a keyboard or read from the program memory. It also re-computes its hash table indices for each token it finds in such a command or program line again and again. This is the simplest and the least efficient implementation of an interpreter. In this regard Lisp-in-Basic is much poorer even than Ed's Toy interpreter.

I'm currently adding a very basic bytecode compiler to it that I hope can make it up to an order of magnitude faster even in its prototype form. Regardless of my success of failure in that attempt, I'm planning to post the proto only after I'm through with my investigations.

See you again later. Just stay tuned.

[JRS]

I'm here just to let you know that I'm safe and sound.

Glad to see you're doing okay. Starting to wonder where you were. Thanks for the BASIC Lisp update. I'm looking forward to see the SB version of your efforts.

[RobbeK]

Hi Mike,

Nice to read you 

the Ackermann  --  yep, let's find a way to destroy it ...   

best Rob

[RobbeK]

Mission accomplished :


 

"I come to bury the Ackermann, not to praise him."     from Shakespeare's Julius Caesar (more or less 

.