Lisp in Basic

[Mike Lobanovsky]

IMO stack, data and "code" storage should always be dynamic. Fixed-length arrays are acceptable in toy interpreters only.

[JRS]

You're right. Hope others get the message. 

BTW I figure by the time you solve the SBLisp issues, SB will have spoiled you and you will be hooked. Not having to declare anything is addicting.

Call it gut but I'm sensing REF might come into play with SBLisp.

[JRS]

FYI If you get tired of scriba lisp.sb myscript.lisp you can create a standalone SbList.exe with the following.

scriba -Eo SBlisp.exe lisp.sb

Then all you have to type is sblisp myscript.lisp.

[Mike Lobanovsky]

Thanks for the tip.

Just FYI,

1. FBSL allows for three levels of user stupidity:

- #Option Implicit:
--- don't declare simple variables but declare arrays and UDT's (for WinAPI compatibility), and classes;
--- don't report missing declarations and related compile-time warnings but break on compile- and run-time errors;
- #Option Explicit (default):
--- declare everything;
--- report missing declarations and related compile-time warnings and break on compile- and run-time errors; and
- #Option Strict:
--- declare everything;
--- report all warnings and break on all errors.

The display of warnings is controllable throughout the script with a #Warnings On | Off directive. All errors can be trapped and handled with an On Error ... directive and associated functions.

2. Apart from direct access to memory pointers, FBSL has three options to dereference an FBSL object:

- ReferenceOf foo = bar - dereference any object as a whole and point it to any other object by name;
- PointerOf foo = PointerOf bar - point any non-executable entity to any other non-executable entity; and
- AddressOf foo = AddressOf bar - point the entry point of any standalone procedure or object method to the entry point of any other executable entity.

@ is a shorthand for the PointerOf operator. Both PointerOf and AddressOf accept also a numeric variable or literal as the right-hand side of the assignment.

[JRS]

In SB you can turn AUTOVARS on/off anywhere in script making assignment before use required. You can set the option to make compares case insensitive. You can make all variables in a FUNCTION/SUB local by default. There are a few other SB options but these are the ones I use normally.

[Mike Lobanovsky]

Peter Verhas did a very clever job with his choices for the SB vocabulary. I guess he was fond of coding SB programs as much as SB itself.

FBSL's #Option choices reflect its becoming more mature as more and more complicated projects were evolving with time. It's impossible to maintain a multifile #Option Implicit project efficiently. You can already see it even in SB Lisp.

The lack of possibility to declare an SB array without assignment is a drawback. "Initialization" of a large (say, 32MB) array in a client-side For/Next loop is extremely time-consuming as compared to Dim a[33554432] which is done on the server side by malloc() or calloc() instantly and without memory fragmentation.

[JRS]

The lack of possibility to declare an SB array without assignment is a drawback. "Initialization" of a large (say, 32MB) array in a client-side For/Next loop is extremely time-consuming as compared to Dim a[33554432] which is done on the server side by malloc() or calloc() instantly and without memory fragmentation.

If the Array you wish to DIM is a single dimension, then this is an equivalent.

SPLITA STRING(1000001,"0") BY "" TO a

This is the same a DIM a(1000000) with a base of zero.

My plan is to extend the Tools extension module to DIM array structures at the C level.

[Mike Lobanovsky]

SPLITA STRING(1000001,"0") BY "" TO a

This may be a good palliation in some special cases.

My plan is to extend the Tools extension module to DIM array structures at the C level.

This looks like the most reasonable direction to go provided C-compatible array and structure declarations go into the extension together. Think of an array of UDT's with arbitrary member alignment requirements - common practice in C but totally impossible in SB so far.

[JRS]

Here is how to DIM a two dimensional array.

Code: [Select]

SPLITA STRING(1000001,"0") BY "" TO a
SPLITA STRING(500001,"0") BY "" TO b

a[0] = b

PRINT UBOUND(a),"\n"
PRINT UBOUND(a[0]),"\n"

PRINT a[0,500000],"\n"

jrs@laptop:~/sb/sb22/sblisp$ time scriba dim.sb
1000000
500000
0

real   0m0.561s
user   0m0.392s
sys   0m0.164s
jrs@laptop:~/sb/sb22/sblisp$

[JRS]

Actually it can get a little more interesting. In this example the first dimension is initialized to 1000000 zeros (long) and the second dimension is dimensioned to 500000 zstr's. That could be further expaneded out with assiciative arrays as well. There is no practical dimension limitation with structure, size or type.

Code: [Select]

SPLITA STRING(1000001,"0") BY "" TO a
SPLITA STRING(500001,0x0) BY "" TO b

a[0] = b

PRINT UBOUND(a),"\n"
PRINT UBOUND(a[0]),"\n"

PRINT ASC(a[0,500000]),"\n"
PRINT LEN(a[0,500000]),"\n"

jrs@laptop:~/sb/sb22/sblisp$ time scriba dim.sb
1000000
500000
0
1

real   0m0.549s
user   0m0.360s
sys   0m0.184s
jrs@laptop:~/sb/sb22/sblisp$

[Mike Lobanovsky]

Hmmm,

It doesn't look like a two-dimensional array to me, John. It looks more like a one-dimensional (byte ?) array a[1000000] with another one-dimensional (byte ?) array b[500000] assigned to the 1st element of array a[].

Otherwise I don't think you'll be able to create an almost 466GB byte array even under 64-bit SB.

I think a reasonably large and genuinely two-dimensional 1.86GB array (a.k.a. matrix)

Dim a[0 To 1000000, 0 To 2000] As Byte

would take FBSL only a couple microseconds to allocate and fill with zeros, which would be impossible to measure against a few calls to (relatively) turtle-slow C-based Print.

[JRS]

This is the best I can do and still show flexibility.

Code: [Select]

SPLITA STRING(1001,"0") BY "" TO a

b[0] = 0
b[1] = 1.23
b[2] = "ABC"

FOR x = 0 to 1000
  a[x] = b
NEXT

PRINT UBOUND(a),"\n"
PRINT UBOUND(a[500]),"\n"

PRINT a[10,0],"\n"
PRINT FORMAT("%g",a[100,1]),"\n"
PRINT a[1000,2],"\n"

jrs@laptop:~/sb/sb22/sblisp$ time scriba dim.sb
1000
2
0
1.23
ABC

real   0m0.006s
user   0m0.000s
sys   0m0.004s
jrs@laptop:~/sb/sb22/sblisp$

[Mike Lobanovsky]

John,

Please take a little nap while I'm drawing a picture of what you do with your two arrays and how a two-dimensional array looks in reality.

You can't  create an empty two-dimensional array in SB in any way other than "initialize" its elements in a For/Next (or any other suitable) loop by assignment similar to the first lines in the SB Lisp source code.

[JRS]

It will sink in once you try it yourself.

Good night/morning.

[Mike Lobanovsky]

Apart from all sorts of fully C-compliant static arrays for simple and arbitrarily aligned compound data types, FBSL provides an exhaustive range of non-compliant dynamically resizable "arrays" for all of the entities that it supports including ranges, collections, dictionaries, and object instances.

These dynamic "arrays" are implemented internally as doubly linked lists, i.e. quite like the "arrays" as they are known in SB. Their elements respawn to existence only when they are referenced in the code for the first time through any sort of polling or assignment, very similar to what you're showing by your latest test. Non-referenced elements remain unallocated.

Anyway here goes the diagram; it may come in handy as a reminder on your first steps with your projected SB extension module.

Have a good night's sleep, John.

P.S. BTW what will be the timing to split a string of 1Mln+1 bytes? This last benchmark doesn't correlate well with the preceding ones.

.