Lisp in Basic

[JRS]

I'd rather spend more time on trying to enrich the structure and vocabulary of the two versions that are currently functioning. What do you think?

I would let Charles take the current SBLisp source and try to make it work. As a possible side benefit he may find a better way than the GOSUBs we are currently pondering.

Others are enjoying Sunday morning while someone else is still stuck in Saturday night.

Helps me dodge everyone else's mistakes. 

[Mike Lobanovsky]

I would let Charles take the current SBLisp source and try to make it work.

Well, I wouldn't. Firstly, his Lispish is our competitor and secondly, I'm ashamed to publish non-working code. That would be somehow unbecoming even if you don't take me for a developer.

As a possible side benefit he may find a better way than the GOSUBs we are currently pondering.

We've already discussed those better ways while fiddling with Ed's Toy interpreter. As a result of our discussion, FBSL is now stuck up to its ears with all sorts of such better ways.

You did send that check or is the mail just a little slow?

Nope, it isn't. Everything was done in just one lo-o-o-o-o-o-ng twinkling of the eye. 

[JRS]

Well, I wouldn't. Firstly, his Lispish is our competitor and secondly, I'm ashamed to publish non-working code.

Pretend you're Peter and just keep it to yourself. 

I would let Charles take the current SBLisp source and try to make it work.

I have had very few issues porting O2 code to SB. (Peter's games & examples)

[Mike Lobanovsky]

Pretend you're Peter and just keep it to yourself. 

Noooooo John,

That's not my style. The Toy interpreter just ran in FBSL out of the box whereas its O2 counterpart wouldn't. So I put it aside for some two weeks and when I came back later, it just worked with Charles' latest O2 from the Wizard at the top of this page. I posted the sources immediately.

There's nothing secret in XPLisp either. I will only be glad if someone gets it working in Oxygen before I do. Who knows, perhaps that someone may even appear to be you, the congenital terminal code developer.

[JRS]

Rob,

Can you create a simple plot or graphic (Mandelbrot would be great) in SBLisp with the following API?

Code: [Select]

Lisp::SBL_Init()
Lisp::SBL_CmdStr()
Lisp::SBL_CmdFile()
Lisp::SBL_Close()

Note: The SBL_CmdStr() & SBL_CmdFile() module functions will return a string with the result of the call. The SBL_Close() call is optional if a SBLisp (quit) is embedded in your script.

I will be using Script BASIC and the SDL GFX extension module for the graphics part. I hope to use the pattern matching SB functions to parse the return SBLisp response strings.

TIA

[Mike Lobanovsky]

Hehe John,

So I was not totally nuts and that recursive GOSUB nightmare was not entirely my hallucination: LispEval:, LispPrint: and ReadSExpSeq: are recursive GOSUB's.

I'm currently trying to finish your work on GOSUB elimination. Nothing much to report yet.

[RobbeK]

HI,

Yes, I can write something -- maybe (attached) is a candidate ( ? , please be frank -- sometimes , these maths are much less spectacular as I think 

It's interesting because :

- it's sets up prime numbers from scratch
- it sets up a pixel-spiral that in symbolic language can be written as U L 2D 2R 3U 3L 4D 4R 5U 5L  ..  up,down, left ; right (p.e. 4R means 4 times to the right ) , it's an example of mixing the two patterns.
- the use of complex numbers as lists   (Unlike CL, Bigloo comes without complex numbers )

so, written in Bigloo Scheme   -
buttons :

- a prime spiral (sometimes used to find linear correlations --  you can see some lines containing more primes than others - Euler made a few formulae   (without computer of course)
- the Gaussian primes (complex prime numbers).

However , I may need your help for something .. these graphics are slow and using a faster method (by building rgb arrays) is very difficult (both in CL and Scheme).   It needs pointers (only in NewLisp I can do this because it has (address ....  ))

I want to use this : void j drawimagesource ( int obj , int x , int y , int w , int h , int* r , int* g ,int* b );

(those pointers are the problem ... )

Bigloo has a C-interface, but I don't understand it ... there's something about setting up pointers - with accessors and mutators   , but I don't get how to communicate with these.

http://www-sop.inria.fr/indes/fp/Bigloo/doc/bigloo-28.html#The-C-interface

(there's no way (afaik) Scheme or CL will give an address of any allocated memory  )

best Rob



.

[Mike Lobanovsky]

Hi Rob,

Can you create a simple plot ... in SBLisp ...

If I understand John correctly, what he is trying to ask you for all this time is some useful script in the LISP dialect that we have translated from QBasic 4.5 as described in the PDF.

SBLisp stands for Scheme BASIC Lisp and that's John's SB version of QBasic LISP while mine is FBLisp that stands for Freestyle BASIC Lisp.

The LISP code that you're posting here is currently of no practical use to us because neither SBLisp nor FBLisp currently support any iterative constructs except (for-each).

[JRS]

Rob,

What I'm looking for is this to be converted into Scheme BASIC Lisp (SBLisp) so I can call it as a SB Lisp extension module function.

Mandelbrot Iterator

Code: [Select]

besFUNCTION(gfx_Mandelbrot)
  DIM AS double cx, cy, zx, zy, tp;
  DIM AS int iter;
  besARGUMENTS("rri")
    AT cx, AT cy, AT iter
  besARGEND
  DEF_WHILE (zx * zx + zy * zy < 4 AND iter > 0)
  BEGIN_WHILE
    tp = zx * zx - zy * zy + cx;
    zy = 2 * zx * zy + cy;
    zx = tp;
    iter = iter - 1;
  WEND
  besRETURN_LONG(iter);
besEND

Here is the Script BASIC code calling the C BASIC SDL GFX extension module version of the Mandelbrot iterator. What I would like to do is call the SBLisp version of the iterator.

Code: [Select]

' ScriptBasic GFX - Mandelbrot

IMPORT gfx.inc

s = gfx::Window(640,480,"ScriptBasic GFX Mandelbrot")
ts = gfx::Time()
FOR y = 0 TO 479
  FOR x = 0 TO 639
    cx = (x - 320) / 120
    cy = (y - 240) / 120
    rit = gfx::Mandelbrot(cx, cy, 510)
    gfx::PixelRGBA s, x, y, rit * 12, rit * 8, rit * 4, 255
  NEXT
NEXT
te = gfx::Time()
gfx::stringColor s, 20, 15, "Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0x000000ff
gfx::Update
WHILE gfx::KeyName(1) <> "+escape"
WEND
gfx::Close


[Mike Lobanovsky]

John,

Your CBASIC code is written for an optimizing C compiler. Be forewarned it's going to be slow as hell in an interpreter, be it BASIC or SBLisp or whatever. Remove duplicate zx*zx and zy*zy recalculations from the while loop.

You're making the exact same mistake that Peter and others were making in their Oldschool Plasma code.

[JRS]

Thanks Mike for the tip and your new adventure in GOSUB madness. I know it's going to be slow compared to the C BASIC version but I thought it would be a good function to help us optimize the XBLisp efforts.

You're making the exact same mistake that Peter and others were doing in their Oldschool Plasma code.

Correction: This Mandelbrot iterator is a verbatim port of the code posted on this forum. I take no ownership in its creation.
 

[RobbeK]

Hi John , Mike ,

Downloaded the SBLisp :

- there is no iterative mechanism   (for-each is a mapping device ).
- named-let (the pseudo-iterative Scheme mechanism does not exist)
- there is no (begin...  )  to mark a block, which is necessary inside the if macro , the problem is
    (if cond x y)   where both x and y is one single expression -- to overcome this
     -  in Scheme    (if cond (begin .... )   (begin ....))
     - CL   has several mechanisms   block ,  prog1 , ... progn
- However :  there is (cond  ... ) to replace previous , it accepts more than one expression / condition
- It does tail recursion perfectly
- This can be expanded that the lambda expression contains an accumulator and an iterator value , it is of course possible to add more parameters if several conditions are needed  (like while calculating a point of a fractal , there are 2 parameters : a maximum number of iterations and an orbit limit (p.e.   x²+y²)

an example of ordinary tail-recursion is attached called ff
and an extended tail-recursion which contains an iterator and an accumulator.
(with this everything is possible)
However , recursion (if not using a "smart" compiler that converts it into iterations into the native code) results in veeery slow run times. As Mike remarks, the Mandelbrot may not be something for the show-case.
The primes-sieve *is*  -- no problem to write & this also while this will give reasonable execution time.

(attached :  factorial    - TR recursion  - TR recursion + aux parameters.

best Rob

.

[JRS]

Thanks Rob!

I should have something to show soon.

[Mike Lobanovsky]

This Mandelbrot iterator is a verbatim port ...

This is exactly why I mentioned Peter; you weren't on the alert while porting.

... of the code posted on this forum.

This forum deals with code compilable to native code. Even so it can contain pitfalls especially when compiled by Oxygen that has no optimization mechanisms to rearrange pieces of inefficient code automatically. It cost Peter 20% of his FPS and I don't know how much these duplicate zx*zx and zy*zy would cost the O2 Mandelbrot code creator whoever that was.

Anyway, my obligation was to point that out. Your right is to accept or ignore my points. I'm not going to do any more benchmarks only to prove again and again what has already been proven.

[Mike Lobanovsky]

Rob,

Thanks a lot for your brief survey and a simple test of a couple of XBLisp features. Still I would like to ask you, while you are at it, to provide us with some usable code written in XBLisp to have a Mandelbrot set printed out to the console in the form of ASCII art.

I will provide you with very short but complete equivalent programs written in C and BASIC and I will attach a reference picture of what they would do in less than a second in your console.

Please give me 5 minutes or so to have it posted here.