OxyScheme (Scheme Interpreter in O2)

[Mike Lobanovsky]

Hi,

OxyScheme seems to be starting to show the first signs of life. The code is still dirty and needs much more debugging effort but the core is already there. Don't mind extra debug output while watching OxyScheme as it runs Rob's ASCII Mandelbrot on the left. You can also see the reference nanoscheme script running in FBSL's DynC on the right.

P.S. I've got very little spare time for leisure coding these days so I apologize for my sporadic posting. But watch out ye who don't like me: I'm still alive and kicking.

.

[JRS]

Mike,

Will OxyScheme be a custom Lisp version or are you striving for current Scheme compatibility?

You truly have become a Scheme/Lisp expert.

John

[Aurel]

But watch out ye who don't like me

you probably think of me ..and i can say that you are very wrong about that
in fact i really like all your work on fbsl and here on bytecode stuff.

[Mike Lobanovsky]

Hi John,

OxyScheme/nanoscheme structure follows a standard r4rs Scheme syntax. The later r5rs standard (like in TinyScheme) was introduced mainly to systematize the differences in earlier Scheme implementations and was very close to r4rs in practically everything except a somewhat more laconic notation for the description of new user-defined syntactic forms. Yet everything that's written for TinyScheme can also be described in OxyScheme/nanoscheme's r4rs syntax. And in very many cases, scripts written for TinyScheme are also runnable in OxyScheme/nanoscheme without adaptation.

OxyScheme/nanoscheme has a clear and well-defined modular structure, which makes adding new data types and corresponding functional instrumentarium a relatively straight-forward task. Currently it supports fixnums, flonums and strings only but an eager enthusiast can easily expand it to full numeric tower with exact numbers, chars, and vectors.

I'm planning to support FBSL's nanoscheme script in my spare time in the future and I will naturally be adding the corresponding features to OxyScheme as well. Still I won't mind if someone takes over OxyScheme and then I will be able to augment nanoscheme accordingly.

My only concern at the moment is that judging by the very rough benchmarks that I was able to run to date, OxyScheme appears not so fast as I expected. For example, the doubly recursive fibonacci(35) test yields the following approximate results on my PC:

• 30 sec for nanoscheme compiled with gcc -O3
• 110 sec for same with gcc -Os
• 110 sec for DynC nanoscheme script
• 125 sec for TinyScheme
• 230 sec for OxyScheme

Currently, OxyScheme's source is a spitting image of its C language original. Hopefully someone will be able to better optimize it for OxygenBasic which was not my own primary goal. I think making such a lengthy and feature rich alien script runnable in OxygenBasic at all is already an achievement in its own right.

[JRS]

125 sec for TinyScheme

That's encouraging news. At least I didn't waste my time with the TinyScheme extension module for SB.

 

[Charles Pegge]

Hi Mike,

I look forward to your final Oxy-Nanoscheme. It will be very useful to discover where further optimisation can be made.

[Mike Lobanovsky]

Hi Charles,

Do you want me to post the code that hasn't been fully debugged yet? I'm still adding r5rs features to it (mainly numeric stuff) while debugging the rest of it in the process.

[Charles Pegge]

Hi Mike,

Complete your debugging ceremonies first. It will make our interactions much simpler. There is no hurry.

[Mike Lobanovsky]

OK guys,

So here comes OxyScheme Beta.

1. All procedures and pieces of code that are labeled with '/*...*/ comments belong to the former developers of this code.

2. All procedures and pieces of code that are labeled with C-stylish // comments or not labeled at all have been added by me.

3. The code implements partially (but rather thoroughly) exact and inexact numeric functionality based on integer and double-precision floating-point math. String data type functionality is implemented in full except for its interaction with char data type. Char and complex numeric data types and vectors are not yet implemented.

4. The file nsinit.scm is OxyScheme's initialization file that can be extended to contain a richer library of user-defined procedures and useful macros collected from other sources and adapted to the syntax currently available in OxyScheme. The complete list of internally supported keywords can be found
at the bottom of o2scm.o2bas file (see mk_proc() calls) and additional procedures and macros from nsinit.scm are printed to the console as the file loads at app start.

5. The r5rs manual is included in the zip for you reference as to how an r5rs-compliant Scheme works or should work if bugs are spotted in this Beta version.

6. A few of Rob's .scm samples have also been added for demonstration.

I'm washing my hands of this project for some time (got a little bored with O2's char* pointers ) but your feedback is much welcome nonetheless.


Enjoy!

[EDIT] DIS CODE IS IN TEH PUBLIC DOMAIN!

.

[Charles Pegge]

Many thanks, Mike.

We must conjure up a few useful applications to put Oxyscheme through its paces. I think the most natural way to interface these Lispish languages is through text i/o, redirected from console to specified APIs: For instance, passing data to SQL, or drawing lists to Opengl via a command interpreter.

[JRS]

Mike,

When I try to (quit) it goes to the next line (no prompt) and hangs. I have to CTRL-C to exit.

[Mike Lobanovsky]

Hi John,

I confirm this bug. Please find case OP_QUIT at line 2595 and overwrite this handler with the following code:

Code: OxygenBasic

1.       case OP_QUIT '/* quit */
2.        ExitProcess(0)

and also overwrite the main program loop function Eval_Cycle() at line 3271 with the following code:

Code: OxygenBasic

1.   '/* kernel of this intepreter */
2.  sub Eval_Cycle(sys op)
3.     operator = op
4.     do
5.       push operator
6.       call dispatch_table[operator]
7.     end do
8.   end sub

This makes things even simpler.

Thanks for spotting it!

[Mike Lobanovsky]

Many thanks, Mike.

... I think the most natural way to interface these Lispish languages is through text i/o, redirected from console to specified APIs ...

Morning Charles,

My pleasure.

I think the most efficient way to interact with 3rd party APIs in DLLs such as OpenGL would be as follows:

• add a new procedure to OxyScheme's vocabulary, say, (call-dll) that would push its variadic arguments on stack, make the actual call, and fetch the return value back to OxyScheme as one of its currently supported internal data type (boolean, fixnum, 64-bit flonum, or string for the moment)
• conjure up specific .scm include files with macros built around this (call-dll) procedure bearing the same names as the original DLL functions, so that the LISP source remains ultimately readable in the way natural for a particular DLL, e.g. (glVertex3d 1. 2. 3.)
• use the same (call-dll) in yet another -- Windows.scm -- include file with high-level macros as a simple and efficient means to create Windows GUIs
• ........
• profit!

[Mike Lobanovsky]

Oh, and of course this strategy would require that OxyScheme use a non-blocking console implementation in place of its existing ordinary console include file.

[JRS]

Life is so much more challenging working with an interpreter from a compiler standpoint rather than another interpreter. Is the end goal something like a TinyScheme extension with SB or will it be more tightly coupled?