Toy interpreter and Bottom Up versus #lookahead

[Arnold]

Hello,

I found the toy.o2bas in projectA\ToyInterp and the discussion about it here:

http://www.oxygenbasic.org/forum/index.php?topic=1094.msg9241#msg9241

The demo did not run with the latest version of o2 and the error message was rather meaningless:

ERROR:   Unknown type
WORD:    long
LINE:    942
FILE:    main source
PASS:    1

so I commented out the #lookahead directive and tried to arrange the procedures from bottom up, following the error messages when running the demo. This worked until I came to sub primary(), which calls expr() which calls primary() ..., also if_stmt() and while_stmt(), which call stmt_seq() which calls if_stmt() and while_stmt() ....

I am not sure if such constructions are legal. At least there is a great chance to create endless loops. Therefore I personally will prefer the bottom up strategy. After inserting the code of primary() into expr() and inserting the code of if_stmt() and while_stmt() into stmt_seq() the demo finally worked.

Then I tried to do this procedure of inserting with the original code of toy.o2bas but this seems not to be sufficient. I got a similar message like before.

So my question is: what are the rules for using #lookahead? Is there any advantage for using this directive?

Roland

.

[Charles Pegge]

Hi Roland,

#lookahead creates declarations for each function it encounters down the script.

Example:

Code: OxygenBasic

1. '#lookahead
2. 'equivalent:
3. ! f1(sys a) as sys
4. ! f2(sys a) as sys
5.  
6.  
7. f1 1
8. f2 2
9.  
10. function f1(sys a) as sys
11. printl 1
12. end function
13.  
14. function f2(sys a) as sys
15. printl 2
16. end function
17.  

Personally, I prefer natural order (bottom up) coding wherever possible. It is easier to follow and debug.

I'll check the Toy Interpreter and see what needs fixing.

[Arnold]

Hi Charles,

your code above makes sense to me. Recursion makes sense to me also, if I can see the stop criterion. But the combination: a calls b, b calls a, a calls b, b calls a etc. makes me dizzy. Can this really work? I wonder why the original toy.o2bas code obviously could run with an earlier version of o2. There were no memory leaks at all?

Roland

[Charles Pegge]

Recursion is a burden that language developers have to endure. For instance: solving an expression which contains arrays which contain index expressions ...

I have now fixed #lookahead. It should support both Basic functions and C-style functions.

And ToyInterp now works correctly

It is also possible to assign {data} directly to UDTs containing member arrays.

Oxygen Update
http://www.oxygenbasic.org/o2zips/Oxygen.zip

Code: OxygenBasic

1. includepath "$/inc/"
2. include "Console.inc"
3.  
4. type a_note
5.     int iDur
6.     int iNote[2]
7. 'int n
8. end type
9.  
10.  
11. a_note notes[] ={  
12.     {110, 69, 81}, {110, 67, 79}, {990, 69, 81}, {220, -1, -1}, {110, 67, 79},
13.     {110, 65, 77}, {110, 64, 76}, {110, 62, 74}, {220, 61, 73}, {440, 62, 74},
14.     {1980,-1, -1}, {110, 57, 69}, {110, 55, 67}, {990, 57, 69}, {220, -1, -1},
15.     {220, 52, 64}, {220, 53, 65}, {220, 49, 61}, {440, 50, 62}, {1980, -1, -1}
16.     }
17.  
18. print sizeof a_note
19. printl
20. #recordof a_note
21.  
22.  
23. for x =1 to countof notes
24.     print notes[x].iDur " " notes[x].iNote[1] " " notes[x].iNote[2] cr
25. next
26.  
27. waitkey
28.  

[Arnold]

Hi Charles,

this update is really very impressive and it happened so fast. Besides solving my little problem with udt two more OxygenBasic demos now run successfully on my system.

Roland

[Charles Pegge]

Well thank you Roland, for bringing these problems to my attention. It is so easy to accidentally break the syntax when introducing new features, but it is often possible, to create better, more compact code when fixing.

[Aurel]

I

t is also possible to assign {data} directly to UDTs containing member arrays

so that is why this code not work on my old version...
and i am not very much impressed with the logic of this array but who care if work
then is good  ..right
 

[Charles Pegge]

Hi Aurel,

You can still assign data specifically to a sub-array as before. For instance:

Code: OxygenBasic

1. type typ
2.   sys a[100]
3.   sys b[100]
4.   sys c[100]
5. end type
6.  
7. typ t
8. t.b[10]={2,4,6,8 ...}
9.  

[JRS]

and i am not very much impressed with the logic of this array but who care if work then is good  ..right

[Aurel]

ok charles...