(Mis?)using DEFFN to define constants fails in compiled programs?

[Yet Another Troll]

This works in the Android 1.26-55-unstable.apk interpreter but the compiler doesn't like it at all:

DefFn Nil% = -1
DefFn TreeStartingSize% = 200

Head% = @Nil%
Tail% = @Nil%
Free% = @Nil%
Print @TreeStartingSize%()
Dim Left%(@TreeStartingSize%)
Dim Right%(@TreeStartingSize%)
Dim Key$(@TreeStartingSize%)
Dim Value$(@TreeStartingSize%)

# ...

Print Head%, Tail%, Free%, Dim?(Left%())
Print "OK"
End

Some screenshots:

[Markus Hoffmann]

confirmed. The compiler has problems with functions defined without empty brackets (). I will have a look into this.

[Yet Another Troll]

The compiler doesn't like my attempted workarounds either.

Is there a better syntax highlighting code than ":::basic" or is it because I'm using VBA style mixed case?

#!/usr/bin/xbasic

DefFn Nil%() = @CLng%(-1)
DefFn TreeStartingSize%() = @CLng%(200)

DefFn CLng%(x%) = (x%)

Head% = @Nil%()
Tail% = @Nil%()
Free% = @Nil%()
Print @TreeStartingSize%()
Dim Left%(@TreeStartingSize%())
Dim Right%(@TreeStartingSize%())
Dim Key$(@TreeStartingSize%())
Dim Value$(@TreeStartingSize%())

# ...

Print Head%, Tail%, Free%, Dim?(Left%())
Print "OK"
End

[Markus Hoffmann]

The programs above do indeed show two problems, Ine is a bug in X11-Basic compiler, which did not recognized function macros without empty brackets. This Problem I have fixed now, it will be in the next release. But:
A second problem has shown up, also only in the compiler, concerning the DIM statement.
The values inside the DIM brackets are evaluated at runtime (only), but the DEFFN macros are resolved already at compile time, so that excecuting the DIM will produce a function not found error. This is not yet solved. The solution would be to reimplement the DIM statement, such that it takes precompiled arguments, and not evauate the expersssion as a string at runtime. The latter I have used whernever I was lazy, when I have built the compiler. Because the interpreter was already there it was easy to evaluate things atruntime and not write a special code for the compiler. Since the DIM statement usually is not time critical (only used once os ro at thebeginning of the program) I have not completet this for DIM, however for most of the other commands it was (due tu speed issues). Maybe I find some other leftover-commands, whoich now finally need to be implemented correctly in the compiler.

BTW: the PLIST command (after having loaded a program) shows you details of the preprocessed COMMANDs, but these things are really insider information. As well as using xb2c on the bytecode (not possible on Android).

[Yet Another Troll]

So using DIM to expand an array using an expression like, DIM X(N% + ShR(N%, 2) + 4) will also be slow? Should resizing arrays be done as infrequently as possible then, using the simplest expression possible, even at the expense of using much more memory than necessary, and then perhaps shrinking it back to only what is needed once processing is completed?

IF N% = UBOUND(X()) THEN
DIM X(N% * 2 + 1024)
ENDIF
X(N%) = NEWSTUFF

[Markus Hoffmann]

slowis relative. With the bug, compiled DIM is as slow as in the interpreter. Without the bug, it could be processed much faster than in the interpreter, especially, if there are complex expressions used to calculate the dimensions. However, Memor allocation (possible resizing etc..) will be the same.

[Yet Another Troll]

So a little slower, but it adds up if arrays need to be expanded too often. I'll need to review certain recursive routines that DIMension LOCAL arrays and see if a reduction in strength is possible, perhaps using just one buffer allocated in a driver proc that is then passed into the recursive routines. Perhaps even copying that array will be faster than DIMming a new array. I don't compile everything, or even most things, but when I do use the compiler, it's because I'm trying to squeeze out every last drop of performance. Otherwise I'd have found this DefFn problem back in April and perhaps even become suspicious of DIM.

[Markus Hoffmann]

I have finally fixed this issue (at least I believe so). It was a complicated one and the result need intensive testing. It will be in 1.26-56. I hope, I have not broken anything.

Both of your test programs run in the interpreter, compile and run compiled now without errors. DIM wit complex expressions will be as fast now as other expressions in X11-Basic.