Lisp in Basic

[Mike Lobanovsky]

Hi Rob,

Et voilà , messieurs ...  ...   the "iterator"
.............................................
addendum -- added 006 which does proper printing too.

Your achievements are simply amazing! I can't wait to see the ASCII Mandelbrot running in my XBLisp console too.

Nice to see this thing actually working. 

Thank you for your kind words. My eagerness to go on with this project has doubled now that you're emitting usable code for it.

the source is it QB ??  -- can't you wring/wrench it through something as QB64 / FB to give it more speed ??

The (inoperative) original was written in QB4.5. But having it as yet another standalone LISP is not the main goal of this project. The milestones are:

1. To maintain a common code development base compatible with at least 3 languages -- ScriptBASIC, FBSL, and OxygenBasic for as long as it is possible and reasonable;

2. To enrich the vocabulary to maximum compatibility with a standard Scheme dialog of LISP;

3. Finally, split the project into 3 distinct language branches and convert it to CBASIC for SB, and DynC, for FBSL. This will allow these two languages to have XBLisp running much much faster in native machine code. But this will also make the branches totally source code incompatible. Note that the O2 project branch currently named OxyLISP runs in fast JIT compiled machine code already now. But it is still having serious issues due to strong typification of its data. SB and FBSL don't have such issues due to their variant-based variables.

Yes, XBLisp is currently very slow but it is very convenient for development. Once XBLisp is re-written in CBASIC, DynC and usable O2, the LISP code will run anywhere between 200 to 500 times faster. In this way, each one of SB, FBSL, and O2 will have its own fast and practical LISP module.

Isn't that challenging as it is?

[Mike Lobanovsky]

Hi John,

Don't complain. You're getting major action in the commit comments. 

... which doesn't however justify your adultery with ECL in the meantime.

Here is Debian noroot running on my Samsung Galaxy  Tab 2 10.1 tablet.

Looks nice and very Linux-like.  

Gedit has standard built-in syntax highlighting themes for VB.NET and Scheme under my Win 7 styled Ubuntu LTS that you're seeing in my screenshot. They're working perfectly well for our SB/FBSL/O2 BASIC code and XBLisp scripts too.

(proceeding with the remaining GoSub to Function conversion as planned)

[Mike Lobanovsky]

Hello Rob,

A practical question to you. Is it natural for any LISP to see the source code of a program being outputted to the console while the program loads from a disk file?

If not then I can make it so that it would go to the console only in the -D mode. The normal mode will print only the output of the program. The interactive mode will stay unchanged.

Do you think this would be reasonable and natural for a LISP user?

[RobbeK]

Hi Mike,

The CL's (I think all of them) give the definition-names while loading , but not the bodies.
NewLisp also gives the bodies, but it has (silent .... ) if included in the source then it outputs nothing to the console.
Don't know about BigLoo (all my code was compiled from within a seperate console window, not the REPL ).

It has of course the advantage that when there's something wrong with the source it will indicate where ... (?) .. but then, on an error there should always be a kind of indication what/where 's happening.

best Rob

[Mike Lobanovsky]

Rob,

Is it auto-GC , or do I have to code it ?

It does automatic garbage collection all by itself. You can see it with your own eyes if you use the following command line to load your scripts using scriba.exe:

scriba.exe lisp.sb Xblisp006.txt -d

-d means "debug mode" in which you can see GC work.

Be sure to load the latest lisp.sb script from the repository!

.

[Mike Lobanovsky]

Rob,

it has (silent .... ) if included in the source then it outputs nothing to the console.

I like this very much. What do the periods .... here stand for? Can you give an example, please?

on an error there should always be a kind of indication what/where 's happening

That's exactly what's there in XBLisp now. Error reports are always active but if e.g. a file with an illegal line break character is being loaded in a usual way, then the report will look like the following:

ERROR: Read.
ERROR: Problem in file Xblisp002.txt
ERROR: Bad type.

OTOH when the same happens with a -d debug mode switch, then the report will be more informative:

ERROR: Read.
ERROR: Problem in file Xblisp002.txt
ERROR: Faulty line #2: '  (lambda (p q)'
ERROR: Bad type in SetCar: ptype=-1

And I'm planning to add many more detailed debug messages in the future.

Will you approve of such a scheme coupled with the (silent ....) directive added to the XBLisp vocabulary?

[JRS]

Mike,

What FUNCTION/SUB routines at this point would be better served by a Script BASIC C BASIC conversion to an extension module call? It would be nice to know the top 10 routines that are used most and are candidates for a conversion.

[Mike Lobanovsky]

Hi John,

You're indeed an early bird! Is it really 6:30 a.m. at your place?

Currently, XBLisp has no way of sharing memory with anyone. So for the moment the only two feasible functions in an SB:SBLisp interface on the SB side of it IMO would be SBL_StartInteractiveSession() and SBL_LoadLispFromFile(filename$). The functions should return when the respective interactive/file exec sessions are over.

Note that if the SBLisp file to execute doesn't contain a (quit) command, then the file exec session will be followed by an interactive spell until the user enters a command to quit.

The entire SBLisp should (and I think will) be finally rewritten in CBASIC, i.e. in ANSI C similar to FBSL's DynC. It will become feasible as soon as there are no more GoSub's left in XBLisp.

P.S. Or we can also add SBL_LoadLispFromMemory(stringtoload$) functionality easily on the XBLisp side of the interface and provide this function on the SB side of it.

[JRS]

P.S. Or we can also add SBL_LoadLispFromMemory(stringtoload$) functionality easily on the XBLisp side of the interface and provide this function on the SB/FBSL side of it.

I think that is a great idea. Please add it!

[Mike Lobanovsky]

Can a SB function accept a pointer to an ASCIIZ string as its argument and convert it into a usable SB string?


For example, in FBSL I can write:

CALL FBL_LoadLispFromMemory(POINTEROF "(quit)")

and use it further in the receiver in the following way:

SUB FBL_LoadLispFromMemory(strptr AS LONG)
DIM localstr = PTRTOSTRING(strptr)
...................
END SUB

and here localstr will be a usual FBSL String Variant containing the (quit) string that it has received.

[RobbeK]

Hi Mike ,

those ... stand for any thing ...

(silent
   (define x (lambda (...)   ...  ))
   (define message '"this is a message")
   .....
)  ;; end of the silence

'" below this marker the code is not tested - rev . 1.44 : new from (tst)  "     ;; goes to the console

(silent
    (define tst .... )
    .... 
)             ;; ends the silence again

best, Rob
.. probably   (silent)  and (speak)  [without arguments] could be easier mechanisms to code , I think

 

[Mike Lobanovsky]

That's cool Rob,

I'll have it implemented in XBLisp shortly.

Thanks for the tip.

[RobbeK]

Hi Mike,

the Post Script on my message was (in case it escaped you - i added it after some thinking ) :

. probably   (silent)  and (speak)  [without arguments] could be easier mechanisms to code , I think ..

This mechanism makes excellent communication -- once compiled this will be ignored , but in interpreted mode you can add things like

"should I compile and reload ? "       triggers        (load (compile "this-file.lisp))     

[Mike Lobanovsky]

Is (speak) used in any LISP dialect?

[JRS]

E-mail responses from Arthur.

   The reason for the "non-standard" flow is to implement proper tail
calls.  The BASIC code is written in a style similar to assembly
language...  If Script BASIC is properly tail recursive, then it should be
possible to change the code.

  (On errors, I attempt to clear the BASIC subroutine stack manually.)

   I don't have that much time to work on the new implementation, but I can
tell you why I wrote the code the way I did.

   Just make sure you don't break proper tail calling.

   I'll send you some Scheme code that should work without blowing the
stack.