Author Topic: Lisp in Basic  (Read 208006 times)

0 Members and 2 Guests are viewing this topic.

RobbeK

  • Guest
Re: Lisp in Basic
« Reply #15 on: July 31, 2014, 01:26:08 AM »
Hi all,

I'm afraid my knowledge about the deeper architecture of Basic, C , etc .. is rather poor. 
But in Lisp uses the pointer as building block ( just something known "As Any Pointer" , no "pitch" etc.. declared -- it is hidden anyway and completely controled by the system).
This makes that if you say    a=b   ( a := b ;  not a==b ) then it just means a and b share the same pointer whatever the object it points to may be.  This already needs some care (when dynamical scoping is used) and the reason you need several mechanism (as an example) to test equality --  do they point at a same object , or is if not is the outcome of the function they point to the same ..    (eql a b) versus (= a b)  ..  (NewLisp uses lexical scoping and here in both cases "=" can be used ).
Working with ponters make it easy to nest objects of any type, size, depth and manipulate them .. the objects do not move in memory, just the pointers are manipulated - it consequently needs frequent and intensive garbage collection (once again NewLisp uses ORO memory management    .............     http://www.newlisp.org/MemoryManagement.html

other tech. info   (web quotes ) :

"In Lisp, functions are first class objects-- they're a data type just like integers, strings, etc, and have a literal representation, can be stored in variables, can be passed as arguments, and so on."

" In Lisp, all variables are effectively pointers. Values are what have types, not variables, and assigning or binding variables means copying pointers, not what they point to."

" Lisp programs are trees of expressions, each of which returns a value. (In some Lisps expressions can return multiple values.) This is in contrast to Fortran and most succeeding languages, which distinguish between expressions and statements.

It was natural to have this distinction in Fortran because (not surprisingly in a language where the input format was punched cards) the language was line-oriented. You could not nest statements. And so while you needed expressions for math to work, there was no point in making anything else return a value, because there could not be anything waiting for it.

This limitation went away with the arrival of block-structured languages, but by then it was too late. The distinction between expressions and statements was entrenched. It spread from Fortran into Algol and thence to both their descendants.

When a language is made entirely of expressions, you can compose expressions however you want."

"There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

Running code at read-time lets users reprogram Lisp's syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML. "

Basic and Lisp -- The Two Kings' Children ??  -- the water between them may be very deep  ?

from the link John gave :  http://www.paulgraham.com/rootsoflisp.html

I think I prefer a full strength Basic and a full strength Lisp working together over one of these simulating the other ...

4 fun (from the people of Viaweb)
"During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried."   8)

best Rob -- as said, my knowledge about the lower architecture of imperative languages is probably too low to make a fair compare .... 

Charles Pegge

  • Guest
Re: Lisp in Basic
« Reply #16 on: July 31, 2014, 03:49:30 AM »
My LispishUtil requires about 32 core function to operate as an interpreted language. Throw in some string, maths, console and GUI, with the underlying support of static Basic, and we have a new light and fluffy :) layer for highly flexible programming.



This particular implementation, unlike classical Lisp, does not use chains of pointers, but instead uses a single elastic buffer for all records. This makes scoping and  garbage collection very simple. All values are returned in strings.

In this bare-bones system, there are no macros, and no distinction between defining a variable and defining a function.




It also has a few functional-programming constraints:

A user-defined function can only return 1 thing (which can be be a list or another function). It will not alter the values of any variable passed (unlike C pointered, or BASIC byref params)

There are no static variables, so a function cannot retain state between calls - all the variables are dis-allocated when the function returns.



 
« Last Edit: July 31, 2014, 04:02:57 AM by Charles Pegge »

JRS

  • Guest
Re: Lisp in Basic
« Reply #17 on: July 31, 2014, 07:57:00 AM »
Thanks Mike !!!

Last night I discovered that the symbols$[] array isn't being populated. (only a couple symbols were present) That seems to be the major issue. I was using a base 0 for arrays so that may be another issue I didn't realize.

After fixing the symbols$[] array I will go down your list.


Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #18 on: July 31, 2014, 09:26:55 AM »
No problem John,

Here's the SB Lisp listing with these bugs fixed and array population corrected. However, it must still be having a few bugs dormant as it fails to do eval correctly (numbers still aren't recognized as type NUMBER/3 but rather type SYMBOL/4 somehow). Nonetheless it's way ahead of your original submission.

P.S. print statements that appear in lower case immediately on the left of the listing are my debugging aids and may be safely deleted.

.
« Last Edit: July 31, 2014, 09:51:24 AM by Mike Lobanovsky »

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #19 on: July 31, 2014, 09:41:14 AM »
Charles, Rob,

Thanks a lot for your input. It seems like Lisp has been almost as popular for indie development as BASIC.

And Charles is looking so happy with this mouth-watering summertime cake. I guess he's a little tired of BASIC and needs some other tchotchke to play with for a change. :)

Isn't it cool to see another language built on top of what one already has done with one's own hands? 8)

JRS

  • Guest
Re: Lisp in Basic
« Reply #20 on: July 31, 2014, 09:54:58 AM »
Quote
Here's the SB Lisp listing with these bugs fixed and array population corrected. However, it must still be having a few bugs dormant as it fails to do eval correctly (numbers still aren't recognized as type NUMBER/3 but rather type SYMBOL/4 somehow). Nonetheless it's way ahead of your original submission.

P.S. print statements that appear in low case immediately on the left of the listing are my debugging aids and may be safely deleted.

That is so cool that you would help the SB project out and resolve these QB to SB issues. You are a true friend!

Quote
Isn't it cool to see another language built on top of what one already has done with one's own hands?

It just validates that BASIC is the foundation of all languages going forward.

Quote
If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.

Life is more interesting under the covers.
« Last Edit: July 31, 2014, 11:21:21 AM by John »

JRS

  • Guest
Re: Lisp in Basic
« Reply #21 on: July 31, 2014, 01:32:50 PM »
(quit)  works!

That wasn't happening before. I think you are close. It seems you used my first post on the O2 forum rather than the current one I had on the SB forum. I did some cleanup on that version.

1. All variables to lower case.
2. Labels (functions ?) mixed case
3. KEYWORDS capitalized.


Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #22 on: July 31, 2014, 01:46:27 PM »
Yes, (quit) and (gc) do work. The parser seems to work OK. I think the other keywords and primitives should work as well, but evaluation is still failing somewhere. That's where I left off.

Of course I had a look at your sources. I downloaded them from the SB site. But since those weren't working and were showing arguable approaches, I copied the original right off the Lisp in Basic site and reformatted it staying as close to the original as SB would only permit. Then I fixed up the array population problem and checked the parser for general operability.

There may still be some hidden visibility scope problem that spoils data type evaluation. The lack of DoLss (the < function) is probably due to the author's carelessness when copying the source to the site. This function might well be the last one in the listing.

JRS

  • Guest
Re: Lisp in Basic
« Reply #23 on: July 31, 2014, 02:12:47 PM »
The DoLss routine missing also made the QB program error. I just added a stub to deal with it. I should e-mail to author and ask about it.

You seem very close and if you have time to take it home, that would be outstanding. I'll wait to do my format cleanup on your version when it looks like it's working.

What are your thoughts about allow extension module access from SBLisp? I have seen a few different approaches to this.

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #24 on: July 31, 2014, 02:42:24 PM »
I don't think a letter is really necessary. DoLss should be an exact replica of DoGtr (whatever) barring the sign of comparison. I think it can be reconstructed from the existing code.

I left all the former uppercase intact to distinguish it from my deliberate lowercase that I'm adding at debug time. Probably it should stay that way till it starts to function in full.

I'll come back to this code this weekend. It's absolutely terribly, oppressively hot in my whereabouts these days so I'm getting my naps more often than usual. They help me to live on. Will you do me a favor and have a look at your Alaska backyard? You probably forgot to switch off that bloody HAARP oven thing again. :)

JRS

  • Guest
Re: Lisp in Basic
« Reply #25 on: July 31, 2014, 02:54:56 PM »
I don't think a letter is really necessary. DoLss should be an exact replica of DoGtr (whatever) barring the sign of comparison. I think it can be reconstructed from the existing code.

Timing was perfect. I was just ready to press send.

Quote
I left all the former uppercase intact to distinguish it from my deliberate lowercase that I'm adding at debug time. Probably it should stay that way till it starts to function in full.

Okay, I'll follow your lead.

Quote
I'll come back to this code this weekend. It's absolutely terribly, oppressively hot in my whereabouts these days so I'm getting my naps more often than usual. They help me to live on. Will you do me a favor and have a look at your Alaska backyard? You probably forgot to switch off that bloody HAARP oven thing again. :)

I'm really looking forward to seeing this work. I have all kinds of ideas (like Charles) how Lisp and BASIC can complement each other.

Everything seems pleasant HERE.
 

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #26 on: July 31, 2014, 03:09:08 PM »
Everything seems pleasant HERE.

D'oh, but that's only 26 Centigrade! We're having 36 Centigrade in the shade here and 26 has been and still is our usual nightly reading for over a week.

JRS

  • Guest
Re: Lisp in Basic
« Reply #27 on: July 31, 2014, 03:32:04 PM »
THIS might be of interest to Lisp users/developers.

Lisp Intro
« Last Edit: July 31, 2014, 09:46:21 PM by John »

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #28 on: July 31, 2014, 08:31:34 PM »
That's what everyone wanted to know but was too shy to ask... :D

JRS

  • Guest
Re: Lisp in Basic
« Reply #29 on: July 31, 2014, 08:42:38 PM »
Once this is working, what do you think about eliminating the stack limit check? SB will dynamically allocate the stack. UNDEF will delete it.