Lisp in Basic

[Mike Lobanovsky]

1. Milla unda teh desk rulez!

2. I need that bowl straight on my head, not for my feet.

3. QB45's NOT FALSE evaluates to -1. You can check it with PRINT. QB45 doesn't define the FALSE and TRUE constants internally.

4. I'm doing a quick port to FBSL now to see if it would work there.

[JRS]

4. I'm doing a quick port to FBSL now to see if it would work there.

Since we are telling secretes, I'm working on modernizing the code a bit with CaSe and +=, -=, .... I will send it to you for review and see if you want to use it for the gold run. For me. it just makes it easier to see things as SB is typeless with no $ suffix.  (optional)

[Mike Lobanovsky]

Doesn't really matter for me right now but prettifying the final code is a good idea.

I think once it runs as expected, functionalizing it altogether might add a lot to its readability and maintainability.

[JRS]

I'm already thinking about how we add in SDL_gfx, SQLite3, ...

[JRS]

We're not dealing with true SB recursion here as these are not true functions. These are just recursive pieces of QB45 code which have their own scope (remember the "p" bug?). I strongly doubt Peter would go that far in his implementation of this ancient BASIC functionality. I certainly didn't. Neither did Charles, to the best of my knowledge. thinBasic doesn't have all this GoTo/GoSub mess at all.

SB is pretty smart with its stack management allowing to jump out of a FOR/NEXT, GOSUB, ... with a GOTO and SB takes care of popping the stack.

You may want to look at the MakeNumber routine. I think SB has a POW function and I'm not sure if the ^ QB syntax is working correctly. (my guess)

. QB45's NOT FALSE evaluates to -1. You can check it with PRINT. QB45 doesn't define the FALSE and TRUE constants internally.

Since SB's TRUE/FALSE are built in constants (F=0 T=-1) and the QBLisp program is using variables, I think the NOT(FALSE) means (F=0 T=anything not zero)

Also be aware that SB has INT and FIX which are similar but handles rounding differently. (up/dn)

Does SB compares need to be case insensitive? (INSTR,  IF a$ = b$ THEN , ...) If YES we need to enable that SB option in SBlisp.

[Mike Lobanovsky]

Thanks for the tips, John.

1. If FALSE is defined as 0, then NOT FALSE evaluates arithmetically to (short int)-1 in QB and VB. SB and O2 will generate (long)-1. FBSL will generate (unsigned int)1.

For Boolean logic, there's no difference what the arithmetic value of TRUE is. The logic defines FALSE=0 only and everything else is TRUE on default. It's just a matter of BASIC's (artificial) tradition to define its TRUE as -1.

The code doesn't check any entity for arithmetic equality with TRUE. It only uses NOT FALSE in IF conditionals where any non-zero value will do.

2. INT() isn't needed in the hash code at all. SB and FBSL (and QB45 BTW) support integer division \ which eliminates the need for all this trickery. Let's leave it at the author's discretion.

3. The only other place where INT() is used is not correct either. Lisp requires explicit Floor() in its DoFloor portion which is not the same as BASIC's INT(). It should round its positive argument down to the closest lower integer but it should round its negative argument to the closest upper integer. QB45's INT() works like a Round() function which rounds its argument arithmetically to the nearest absolute integer with a corresponding sign. This isn't correct for a Floor() call.

IIRC FIX() is simple truncation. Please correct me if I'm mistaken.

FBSL has a % cast for truncation and also built-in Round(), Floor() and Ceil() functions.

4. FBSL Lisp seems to be working OOTB even with #Option Implicit on (i.e. no declarations at all except for the six arrays used in the code). There's some minor problem with its printing a little garbage at its prompt but I'll fix it after a short lunchbreak.

This is good news which means SB should also work sooner or later as there are no more latent bottlenecks in the code. Perhaps I simply dreamed up that "recursive GoSub" nightmare in my hot and sweaty drowsiness.

[Mike Lobanovsky]

Hello John,

Here comes FBSL Lisp.

.

[JRS]

3. The only other place where INT() is used is not correct either. Lisp requires explicit Floor() in its DoFloor portion which is not the same as BASIC's INT(). It should round its positive argument down to the closest lower integer but it should round its negative argument to the closest upper integer. QB45's INT() works like a Round() function which rounds its argument arithmetically to the nearest absolute value with a corresponding sign. This isn't correct for a Floor() call.

IIRC FIX() is simple truncation. Please correct me if I'm mistaken.

SB INT

SB FIX

FYI - Reason for the O2 forum being down was due to a couple MySQL threads being corrupted. Seemed to only effect the O2 forum. Strange!

[JRS]

Here comes FBSL Lisp.

How do you spell happy again? 

I think we are close with SB. Then I can be as happy as you are right now.

[Mike Lobanovsky]

John,

In fact, if I'm looking happy here then it's you I'm being happy for. Frankly I, for one, didn't have the slightest shade of doubt it will work almost instantaneously. I still remember I was first modeling FBSL after MS BASIC.

If anyone wants the FBSL script, just let me know.

(Edited to correct faulty English)

[Mike Lobanovsky]

Oh,

That means SB FIX() works like true Floor() - so we'll be using it in DoFloor instead of INT().

[JRS]

That means SB FIX() works like true Floor() - so we'll be using it in DoFloor instead of INT().

Great!

Thanks for all the effort you're putting into this. Much appreciated!

FBSL Lisp Works on Wine too.


.

[Charles Pegge]

Now, what are we going to do with all this LISP?

[Mike Lobanovsky]

Let's ask Aurel - it's his thread, after all.

[JRS]

Now, what are we going to do with all this LISP?

Looks like Rob has a few more options than when this thread began.