Author Topic: Lisp in Basic  (Read 208347 times)

0 Members and 2 Guests are viewing this topic.

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #615 on: August 21, 2014, 08:22:15 AM »
Rob,

Your s-mooooooo-th iterator is attractive but:

1. Is your order of operands in iterate+ LISP-specific? I think (iterate varname start stop step (command-to-execute)) would look more natural to me.

2. Is it possible to somehow "name" the iterator variable on the fly from the call? That is, can the following structure be implemented in XBLisp (note that the name of iterator variable i isn't predefined earlier and the name of your s-moo-th iterator here is for):

(for i 1 3 0.5 (println i)) ; I'd like to see this work if possible

If not, perhaps the following would be possible:

(define i 0) ; this would also look natural to me
(for i 1 3 0.5 (println i)) ; I'd like to see this work if possible
« Last Edit: August 21, 2014, 08:31:37 AM by Mike Lobanovsky »

JRS

  • Guest
Re: Lisp in Basic
« Reply #616 on: August 21, 2014, 08:28:04 AM »
A couple standards I would like to purpose.

1. SBLisp scripts use the .sbl attribute.

2. We address Rob going forward as MacRob8)

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #617 on: August 21, 2014, 08:43:44 AM »
Standards?!

One more mentioning of SBLisp here and I'll quit. >:( There will be no more updates to the lisp.sb from me and all my further activities will be focused on FBLisp only.

Have you seen me type FBLisp anywhere? Or FBSL and SB, for that matter?

No, it is always XBLisp and SB and FBSL despite my absolute conviction that FBSL is superior to SB in almost anything.

So where's your political correctness?

JRS

  • Guest
Re: Lisp in Basic
« Reply #618 on: August 21, 2014, 08:54:12 AM »
SBLisp = Scheme BASIC Lisp

.sbl = Scheme BASIC Lisp

@Mike - I thought we already cleared up this pissing contest about SB vs. FBSL and they are two BASIC interpreters with their own strengths and weaknesses. SBLisp is a collative project with 2 and hopefully 3 branches going on at the same time. If this is not your understanding then please clue me in.

I have no problem with you inserting comments into the SBLisp traditional BASIC code indicating SB specific syntax. It might help others porting the code to their preferred BASIC language.

I hope to have an official name for the Script BASIC version of SBLisp but to be honest it wasn't at the top of my bucket list. Please allow me to do my job as the project facilitator so others have the needed resources to do their part.
« Last Edit: August 21, 2014, 09:35:16 AM by John »

Charles Pegge

  • Guest
Re: Lisp in Basic
« Reply #619 on: August 21, 2014, 09:00:37 AM »
Mike,

With regard to return label, o2 is tolerant of limited stack accumulations within a function, since the stack pointer is restored from the ebp register on exit. This register is unaffected by gosubs

However, the stack may also be explicitly managed thus:

Oxygen
Code: [Select]

'RESTORE STACK POINTER AFTER RECURSIVE GOSUB

function f()
============
sys i
sys fsp=esp 'RECORD STACK POINTER VALUE HERE
gosub sa
return

sa:
while i<10
  i++
  call sa 'BUILD RECURSION
wend
esp=fsp 'RESTORE STACK POINTER (optional!)
goto sb

...

sb:
print "ok"
end function

f()
« Last Edit: August 21, 2014, 09:12:39 AM by Charles Pegge »

Aurel

  • Guest
Re: Lisp in Basic
« Reply #620 on: August 21, 2014, 11:44:45 AM »
wait ..wait a little...
this is really to much...
i think that Lisp users on lisp forums don't talk to much about lisp
like some of us here...right?

/oups ...my fault ,,i have started this topic  ::) /

.

JRS

  • Guest
Re: Lisp in Basic
« Reply #621 on: August 21, 2014, 12:03:02 PM »
And we will be right back after this short Aurel commercial.


Peter

  • Guest
Re: Lisp in Basic
« Reply #622 on: August 21, 2014, 12:05:28 PM »
Cool Aurel,  you have courage.  :)
I hope they do  not bite you!. You started a dangerous attempt.

RobbeK

  • Guest
Re: Lisp in Basic
« Reply #623 on: August 21, 2014, 12:26:37 PM »
Hi all,

@ Mike , it is common to use the operator first as in apply , map , for-each etc.. in recursive based mechanisms , but the NewLisp iterative constructions do it your proposed way   (for (i from to &opt::step)  body)  and (dotimes (i end &opt::break)   body )
so I changed it.

It is still "camouflaged" mapping -- there are no real iterative steps involved -- it just maps a function over a list in one flow - this operation can not be split in parts that give back intermediate results -- there is no way to declare the arguments of the lambda function non-local -- there is no way to define a global variable inside a function (NewLisp can do this)  -- there is no single iterative mechanism to start with that can be expanded ...    but, maybe ...   I have to sleep on it , yes , maybe ...

the operator has to be quoted -- otherwise it will be evaluated before its result is passed as an argument -- if the pseudo-index doesn't need manipulation, it is directly assigned without the need for setting up a local variable for it  (see attached).
..  I also defined  (nth i L) , which gives the nth element of a List (beware indexbase 0)

best I'll read the documentation once again ...



0](iterate+ 1 6 1 '(lambda (x) (println (+ x x)))))
2
4
6
8
10
12
T
0](iterate+ 1 6 1 'println)
1
2
3
4
5
6
T
0](nth 2 (range 6))
2
0](nth 4 (make-indexx 1 10 0.2 '() ))
1.800000
0](make-indexx 1 10 0.2 '() )
(1 1.200000 1.400000 1.600000 1.800000 2.000000 2.200000 2.400000 2.600000 2.800000 3.000000 3.200000 3.400000 3.600000 3.800000 4.000000 4.200000 4.400000 4.600000 4.800000 5.000000 5.200000 5.400000 5.600000 5.800000 6.000000 6.200000 6.400000 6.600000 6.800000 7.000000 7.200000 7.400000 7.600000 7.800000 8.000000 8.200000 8.400000 8.600000 8.800000 9 9.200000 9.400000 9.600000 9.800000 10.000000)
0]

best Rob
(maybe something can be done with pre-declared global variables -- but it looks ugly to define some things for functions/procedures that are pre-coded  -- and I'm even not sure they are correctly assinged in nested lambda-function
(I mean    (lambda (x)
                   (lambda (y)   ....   ))    do x and Y know each other ??   i'll try , but doubt it ...

 @ John  ,  the real story of MacRob - b

The Story of Mac: A Just-So Story
------------------------------------------

Once upon a time, long ago, there was a company of Lisp programmers. It was so long ago, in fact, that Lisp had no macros. Anything that couldn't be defined with a function or done with a special operator had to be written in full every time, which was rather a drag. Unfortunately, the programmers in this company--though brilliant--were also quite lazy. Often in the middle of their programs--when the tedium of writing a bunch of code got to be too much--they would instead write a note describing the code they needed to write at that place in the program. Even more unfortunately, because they were lazy, the programmers also hated to go back and actually write the code described by the notes. Soon the company had a big stack of programs that nobody could run because they were full of notes about code that still needed to be written.

In desperation, the big bosses hired a junior programmer, Mac, whose job was to find the notes, write the required code, and insert it into the program in place of the notes. Mac never ran the programs--they weren't done yet, of course, so he couldn't. But even if they had been completed, Mac wouldn't have known what inputs to feed them. So he just wrote his code based on the contents of the notes and sent it back to the original programmer.

With Mac's help, all the programs were soon completed, and the company made a ton of money selling them--so much money that the company could double the size of its programming staff. But for some reason no one thought to hire anyone to help Mac; soon he was single- handedly assisting several dozen programmers. To avoid spending all his time searching for notes in source code, Mac made a small modification to the compiler the programmers used. Thereafter, whenever the compiler hit a note, it would e-mail him the note and wait for him to e-mail back the replacement code. Unfortunately, even with this change, Mac had a hard time keeping up with the programmers. He worked as carefully as he could, but sometimes-- especially when the notes weren't clear--he would make mistakes.

The programmers noticed, however, that the more precisely they wrote their notes, the more likely it was that Mac would send back correct code. One day, one of the programmers, having a hard time describing in words the code he wanted, included in one of his notes a Lisp program that would generate the code he wanted. That was fine by Mac; he just ran the program and sent the result to the compiler.

The next innovation came when a programmer put a note at the top of one of his programs containing a function definition and a comment that said, "Mac, don't write any code here, but keep this function for later; I'm going to use it in some of my other notes." Other notes in the same program said things such as, "Mac, replace this note with the result of running that other function with the symbols x and y as arguments."

This technique caught on so quickly that within a few days, most programs contained dozens of notes defining functions that were only used by code in other notes. To make it easy for Mac to pick out the notes containing only definitions that didn't require any immediate response, the programmers tagged them with the standard preface: "Definition for Mac, Read Only." This--as the programmers were still quite lazy--was quickly shortened to "DEF. MAC. R/O" and then "DEFMACRO."

Pretty soon, there was no actual English left in the notes for Mac. All he did all day was read and respond to e-mails from the compiler containing DEFMACRO notes and calls to the functions defined in the DEFMACROs. Since the Lisp programs in the notes did all the real work, keeping up with the e-mails was no problem. Mac suddenly had a lot of time on his hands and would sit in his office daydreaming about white-sand beaches, clear blue ocean water, and drinks with little paper umbrellas in them.

Several months later the programmers realized nobody had seen Mac for quite some time. When they went to his office, they found a thin layer of dust over everything, a desk littered with travel brochures for various tropical locations, and the computer off. But the compiler still worked--how could it be? It turned out Mac had made one last change to the compiler: instead of e-mailing notes to Mac, the compiler now saved the functions defined by DEFMACRO notes and ran them when called for by the other notes. The programmers decided there was no reason to tell the big bosses Mac wasn't coming to the office anymore. So to this day, Mac draws a salary and from time to time sends the programmers a postcard from one tropical locale or another.

best Rob
« Last Edit: August 21, 2014, 12:52:29 PM by RobbeK »

JRS

  • Guest
Re: Lisp in Basic
« Reply #624 on: August 21, 2014, 01:37:56 PM »
Thanks MacRob for the great story!


JRS

  • Guest
Re: Lisp in Basic
« Reply #625 on: August 21, 2014, 03:04:10 PM »
Quote
There will be no more updates to the lisp.sb from me and all my further activities will be focused on FBLisp only.

I assume the Bitbucket code is now unfrozen and I can continue on with the current SBLisp source? Thanks for your efforts and advice with the SBLisp project.

I'm going to take a shot at converting what we have now to PowerBASIC PBCC 5. If things don't go smoothly, I will terminate my efforts, leave a note where I left off and what problems I have found.
« Last Edit: August 21, 2014, 05:39:42 PM by John »

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #626 on: August 21, 2014, 06:33:46 PM »
Hi Aurel,

/oups ...my fault ,,i have started this topic  ::) /

This is not a fault and you have nothing to be ashamed of here. In fact this is the very first time (and likely also the last) when I am actually greatful to you for starting a thread on a forum. This thread awoke my interest and it actually led me out of stasis and got me working mentally and typematically.


Thank you for that. :)

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #627 on: August 21, 2014, 07:09:00 PM »
Hi Peter,

Cool Aurel,  you have courage.  :)
I hope they do  not bite you!. You started a dangerous attempt.

Exactly!

The BASIC environment of today is rather acid and only the most poisonous and aggressive entities have survived in it. Many simply went aloft following the natural flow of events in their lives and yet many more mimicked and migrated to other more promising and nourishing pastures.

What you are witnessing here is the genesis of a completely new species that will integrate fission power of modern BASIC with fusion power of modern LISP and become deadly dangerous in a fight. The wars are turning thermonuclear, Peter.

Beware! :D

JRS

  • Guest
Re: Lisp in Basic
« Reply #628 on: August 21, 2014, 07:13:21 PM »
Mike,

While converting the SBLisp source to PBCC, I noticed in the original QB code that there is TEMP and TEMP$ being used. In the SB conversion this became one variable. I think this needs to be changed. I suggest temp_num and temp_str in the SB code.

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #629 on: August 21, 2014, 07:34:23 PM »
Mr MacRob,

Your fairytale is fantastic! :D

In fact, it is so close to your own current mission in this thread that there's practically nothing fabulous in it. Thank you for co-operation on the XBLisp effort. We need your advice and guidance in so many matters.

If the leading exec operator is a LISP tradition then I am simply discarding John's model

(loop for i from 1.0 to 3.0 by 0.5 do (print i))

as non-canonical LISP. Perhaps it was just another macro invented by someone for the immediate needs of the program.

Quote
which gives the nth element of a List (beware indexbase 0)
I guess we wouldn't be able to recreate the ASCII Mandelbrot code in XBLisp without this operator.

Quote
maybe something can be done with pre-declared global variables -- but it looks ugly to define some things for functions/procedures that are pre-coded
Exactly! I didn't like the three predefined global vars that I used in my (for) solution but I couldn't figure out how I could pass in the variable that the iterator should have used for incrementation.