Lisp in Basic

[Mike Lobanovsky]

That's perfectly feasible. Hehe and it will also allow us to reimplement this LISP thingy in at least one more BASIC (guess which) so that Charles could also jump on the bandwagon.

So what about concatenation? I remember you used to try and glue two SB arrays together at some earlier stage, didn't you?

[JRS]

SB allows tacking on arrays to elements. I can find no way to concatenate a template array to an existing array. 

Expanding (with initialization) a SB array can only be done in a FOR/NEXT.

Maybe we find a sweet spot with SPLITA at startup and let them dynamically expand after that. What is the average stack/heap a typical Lisp script would need?

I'm still trying to spell Lisp.

[Mike Lobanovsky]

Hmmmm, I rarely use multithreading in my work so I can't recollect off the top of my head if the memory allocated in one thread can be preserved for use in another one once the worker thread exits. If it can then we can theoretically spawn a worker thread to make delayed 1K+ FOR/NEXT preallocations in a non-blocking parallel manner while the main thread continues its routine recursion.

I'm so concerned about recursion because recursion is what the Scheme concept is based upon as opposed to canonical LISP which uses iteration and features all sorts of iterative constructs unavailable in a strict Scheme syntax. Scheme has that for-each iterator only applicable with lambda (user-defined function) callbacks, which doesn't seem very practical from my C- and BASIC-oriented egotistical perspective.

I can't answer your question now as I haven't got enough experience in that area. I was planning to study some RosettaCode programming solutions written in Scheme to get a rough idea of what resources might be involved in an average Scheme application...

[JRS]

I rarely use multithreading in my work so I can't recollect off the top of my head if the memory allocated in one thread can be preserved for use in another one once the worker thread exits.

In SB each thread has it's own memory  / variable object. MT allows passing data between threads and has in memory session support of web applications.

I'm going to try and catch a few hours sleep. My vote is for the single array direction which allows more BASIC languages to jump in. (like O2 as you mentioned) If you can convert the two multiple dimension arrays to single dimension arrays, I'll do the SPLITA stuff and then see if dynamic or FOR/NEXT expansions results in better performance. Does GC get called by heap and stack separately or only heap calls GC?

[Mike Lobanovsky]

GC is triggered by the heap top pointer only but the stack and its stack top pointer are also involved in rearrangement in sync with the heap. The stack is also growable.

A GC cycle is a huge piece of CPU- and memory-intensive work to execute so it should be avoided at all costs whenever possible.

So we go the array split and Splita vs. For/Next way. Fine.

Good night, John.

[JRS]

A GC cycle is a huge piece of CPU- and memory-intensive work to execute so it should be avoided at all costs whenever possible.

That sure sounds like a good job for a C based SB extension module.

[RobbeK]

Hi all,

It seems this Scheme is missing the standard itertive mechanism (do ....   )  ? identical with Common Lisp and powerful.

An example from something written yesterday (Bigloo Scheme)

-----------------------
(do ((i 0 (+ i 1)))
                   ((= i (vector-length vec)))
                     (j_drawline cs i 400 i (- 400 (vector-ref vec i))))
----------------------

first line initiates the local(s) and the step  , second the end condition, 3rd the body , without this coding will be somewhat difficult ...

best, Rob

[JRS]

FOR / NEXT array initialize

Code: [Select]

FOR x = 0 to 99999
  a[x] = 0
NEXT x
PRINT UBOUND(a),"\n"
jrs@laptop:~/sb/sb22/sblisp$ time scriba fornext.sb
99999

real   1m26.954s
user   1m14.281s
sys   0m12.501s
jrs@laptop:~/sb/sb22/sblisp$

SPLITA create / initialize

Code: [Select]

SPLITA STRING(100000,"0") BY "" TO a
PRINT UBOUND(a),"\n"

jrs@laptop:~/sb/sb22/sblisp$ time scriba splita.sb
99999

real   0m0.033s
user   0m0.024s
sys   0m0.008s
jrs@laptop:~/sb/sb22/sblisp$

[Mike Lobanovsky]

@Rob:

Thanks for reminding me about (do). In fact I'm keeping it in mind. I'm simply waiting for when John finds a little time to get acquainted with the Scheme vocabulary to tell me that there's no (print) in there but rather (display), and that there's not only (for-each) in there but also (do).


@John:

Splita does seem very impressive!

In the meantime, I want you to have a look at the picture below. I'm not showing off or something. It's just FYI. I've split the FBSL 2-dimensional arrays into 4 separately declared but not dimensioned dynamic arrays (i.e. for example DIM HEAPvalue[]) that are similar in their behavior to what your growable arrays now do. But mine are doing all this bloody damn faster! Incongruously faster! Look at the results: 5.5MB is the starting memory footprint, 12MB only is the ending footprint, and a mere 10 seconds to complete the interpretative recursive evaluation proper.

My maxheapsize is set to 4 000 000 and my maxstacksize is set to 2 000 000.

This is very difficult for SB to beat. But we must find a way to move as close to it as possible. Let's keep our fingers crossed.

Now to bed. Both of us. We need all the power there is.

.

[JRS]

I'm not showing off or something.

SB and FBSL variables are like comparing apples and oranges. SB variables are like variants. (objects) SPLITA is the fastest way (at the user level) to create arrays (single dimension) in SB. It seems that once the array is built, accessing elements seem as quick as accessing any other SB variable type. We are using SB in the development phase for the following reasons. Once this works there will be multiple BASIC options to choose from (SB, FBSL, O2, ...) for your Scheme Lisp projects.

• Cross platform and 32/64 bit.
• Typeless - saves time in the definition phase
• Excellent debugger. (Windows)
• Multi-threaded support out of the box
• Easy and flexible syntax to work with

There will be no claims from me  that SB is the fastest or most feature rich BASIC in the SBLisp offerings. On the Windows platform I think it will be you and Charles in the speed/feature race, not SB. If you have a better suggestion of a BASIC to use to develop SBLisp, I'll follow along and maybe learn something new as well.

[Mike Lobanovsky]

You got up on the wrong side of the bed, John.

Please let me know:

1. where I can read up on SB's SWAP command; and

2. if I can still have a pair of malloc()-based scriba.exe+sb64.exe for Windows from you.

I don't need anything else currently to continue my research of SBLisp on my own. As soon as I'm through with it, I will make my results and suggestions available publicly or privately following your advice on this particular matter. I guess this will be the best suggestion I can offer.


Thanks!

[JRS]

Mike,

Just showing that you have some interest in SB and willing to give it a try is more than I could have ever hoped for. Your evaluation of Script BASIC will go a long way and if positive, maybe be others will add it to their programming toolbox.

[Mike Lobanovsky]

Where did you hear me say I was going to evaluate ScriptBASIC? I said I'm going to research Es-Bee-Lisp. This isn't the same as FBSL LISP or OxygenLisp as soon as the latter is ready. Neither FBSL LISP nor OxygenLisp depends, or will depend, on SBLisp for their own evolution.

Just give me an answer to my questions, please. This is all I would like to know at the moment.

Thanks again!

[JRS]

Where did you hear me say I was going to evaluate ScriptBASIC?

Oops. I misread SBLisp as Script BASIC. My comment still stands.

[Mike Lobanovsky]

REPEAT

Just give me an answer to my questions, please. This is all I would like to know at the moment.

UNTIL GOTTEN