Lisp in Basic

[Mike Lobanovsky]

I suggest temp_num and temp_str in the SB code.

Occam's Razor

Entia non sunt multiplicanda praeter necessitatem
(Entities must not be multiplied beyond necessity)

Code reusability is a requirement of good programming practice.

[JRS]

Mike,

To avoid confusion with the name of the proof of concept project, (SBLisp - Scheme BASIC Lisp) and the FBLisp version of the prototype, maybe you can go with what is already established.

FBSL = Freestyle Basic Script Language  & Freestyle Basic Scheme Lisp

Isn't your goal to integrate the two at some point?

I would like to see OxygenBasic be the project language being used in it's traditional BASIC format. At this point it seems that Arthur and I are the only non-Windows users. This started out as nothing more than a personal challenge to convert a sizable QB program to SB. It worked (with your help) and I would have been happy with that. Mr. MacRob getting involved and showing interest in the Lisp is encouraging. I would still like get this into an either a SB BASIC MODULE or a SB C ext. module using C BASIC. Without your input and help, I have better things to do.

[Mike Lobanovsky]

Hi Charles,

However, the stack may also be explicitly managed thus:

Congratulations! You've hit the most essential point in the FBSL engine.

The entire FBSL is built around this hack: all its vocabulary functions, DynAsm and DynC calls, user-defined functions in FBSL BASIC scripts, calls to all external DLL's follow this save-stack/call/restore-stack pattern.

This way you are allowed to not give a damn whether it is an STDCALL or CDECL function that you're calling because you will never end up with an unbalanced stack. And the overhead of this store/restore toggle is only 2 CPU clocks, which is an infinitessimal by the standards of interpretative environment. These calls are coded in the FBSL sources using GCC's inline assembly.

This however doesn't resolve the task of jumping to a label like in QB's RETURN Label instead of simply resuming execution at the line that follows the call statement. The means for such a jump should be added to the engine itself to immediately retarget the program flow to Label regardless of where the function actually returned to in the script.

[Charles Pegge]

Hi Mike,

It could be implemented for o2 programs like this:

def RetLabel add esp,4 : goto %1

But for 64 bit code 16 bytes must be added: (stack alignment rules)

def RetLabel add rsp,16 : goto %1

Code: [Select]

def RetLabel add esp,4 : goto %1

sys i
gosub sa
print "ok main"
end

sa:
if i=0 then RetLabel bb
ret

bb:
print "ok bb"



PS: source of Rob's anecdote:
http://www.gigamonkeys.com/book/macros-defining-your-own.html

[JRS]

Mike,

I haven't seen the FBSL version of the SBLisp project since the beginning. What is the current format? Does it look more like the original QB version or the SB version?

[JRS]

PS: source of Rob's anecdote

Busted! (still a good story)

Another classic macro-writing macro is once-only,

Code: [Select]

(defmacro do-primes ((var start end) &body body)
  (once-only (start end)
    `(do ((,var (next-prime ,start) (next-prime (1+ ,var))))
         ((> ,var ,end))
       ,@body)))

The SB IMPORT will only include the source once if already reference somewhere else. The SB INCLUDE will include source as many times as the keyword is use. Offloading routines into separate include files may make the code more readable.

[Mike Lobanovsky]

John,

... the name of the proof of concept project ... maybe you can go with what is already established

This is not an established fact to me. Had I considered the repo as the center of this project's activities, I would have confined mine to it. Instead you're seeing me active in this terrifically entertaining thread and you had my assurances that I wasn't even pretending to have my name included in the list of SBLisp acknowledgments.

What I'm trying to do is bring BASIC LISP to the stage where its code is equally usable in three languages. SB is just one of them and, alas, not the strongest one. Therefore I have been doing all my remodeling in the SB dialect of it knowing that if it works in SB then it will also work in the other two. I am deliberately pulling my horses because I have to keep the overall pace in sync with the trailing man in the squad.

You have not yet answered my question here. It was not a mockery but a practical question. I rarely ask irrelevant questions that I don't need answers to.

I would like to see OxygenBasic be the project language being used in it's traditional BASIC format.

It will be so as soon as I see the BASIC LISP structure finalized. Then I will be able to select, with Charles assistance of course, the Oxygen means and features most appropriate for the final layout of this project in its BASIC notation.

I would still like get this into an either a SB BASIC MODULE or a SB C ext. module using C BASIC. Without your input and help, I have better things to do.

With or without your participation, I will have the SB implementation finalized together with the other two. It will be fine with me if then you can make use of my output to the benefit of SB. Neither will it be a tragedy if you can't or wouldn't.

So if there are more urgent matters on your agenda than this fun and entertainment project then you may go ahead right away. It will hardly affect my own plans for this venture.

[Charles Pegge]

I'm rather concerned that a language enforces the use of recursion, by not supporting iteration and other loops. Cyclical processes are fundamental in this universe, and also in mathematical procedures too

[Mike Lobanovsky]

It could be implemented for o2 programs like this:

Exactly!

But this isn't possible on the client side of SB and FBSL in their interpetative scripts. This has to be implemented on the server side in their engine's parsers/lexers. Since changes to the SB engine are hardly likely at this point, I'm following the early-exit-on-error pattern that all the three languages will support equally well with their existing functionality.

We haven't yet reached the stage where  the mighty potential of Oxygen's inline assembly will enhance the basic prototype at its most crucial points.

[JRS]

I'm rather concerned that a language enforces the use of recursion, ...

Does this have anything to do with Arthur's warning of not breaking tail recursion?

If Script BASIC is properly tail recursive, then it should be possible to change the code.

[Mike Lobanovsky]

I'm rather concerned that a language enforces the use of recursion, by not supporting iteration and other loops. Cyclical processes are fundamental in this universe, and also in mathematical procedures too

Rob says it is Scheme's most distinctive feature. I wish Mr Nunes-Harwitt had chosen Common Lisp as a model for his Lisp-in-Basic effort.

[JRS]

We haven't yet reached the stage where  the mighty potential of Oxygen's inline assembly will enhance the basic prototype at its most crucial points.

I'm not a PowerBASIC user or would I recommend it due to the current state of the company and the unknowns it's users are faced with. On the other hand in it's day, PB was a traditional BASIC standard. I think it would be worth the effort to use PBCC 5 (Classic ?) if nothing more than as an updated QB reference. I'm using the SB source to see how much of the code needs to change to support PB. I almost wish I didn't remove the optional $ symbol in the SB version. The % and other numeric type symbols aren't supported in SB.

[Mike Lobanovsky]

... it would be worth the effort to use PBCC 5 ...

I don't own a PB. I'm out on this project fork.

nothing more than as an updated QB reference

This is a deadly mistake. QB45 uses variants like SB and FBSL. PB and O2 use strongly typed variables.

I almost wish I didn't remove the optional $ symbol in the SB version. The % and other numeric type symbols aren't supported in SB.

This won't help you any. BASIC LISP uses common variant arrays to store integer and floating-point numbers. Moreover, it uses its temporary "registers" pvalue, qvalue, etc. to store the same plus strings that go into the hash table at the program initialization stage.

That's why I suspended O2 branch development until we have the current prototype finalized. O2 has the same shortcomings in this respect as your PB. You might as well use O2 for your exercises.

[Charles Pegge]

PB and O2 use strongly typed variables.

O2 variables are strong but supple! You can get close to interptetive scripts - mixing strings and numbers, and also relaxed rules on dimming.

[Mike Lobanovsky]

O2 variables are strong but supple!

I didn't mean to detract from the dignity of strongly typed languages in general, and OxygenBasic, in particular. My point was that neither O2, nor PB, nor C go well together with the QB 4.5 variant-based original.

Can you give me a practical example of storing both integers and doubles in a common O2 array, and integers, doubles and strings in a variable called pvalue, without the need to maintain an auxilliary array that would concurrently store the values' data types, please?