"Some beef with uBasic/4tH"

[The Beez]

Hi 4tH-ers!

I told you I have "some beef" with uBasic. I don't find it much of a problem you only have one array in 4tH. I DO find it objectionable I have to partition it myself. 

So the idea was not the ability to create new arrays, the idea was some transparent way to partition it.

I gave it a lot of thought - especially how to address this thing. Should I introduce a new prefix - only $ was left - oh, horror. How should I store and retrieve those offsets (because that is what they are). SHOULD I may be introduce a whole new set of arrays? Should I make a new array to partition?

Well, I finally settled for partitioning the existing array WITHOUT affecting the current array functionality. The fix was easy. @() always feeds an offset of "0". The partitioner starts off with "0". When the first partition is requested by:

DIM @q(5)

It sets the "Q" partition offset at 0 and adds the requested space to the partitioner, which now holds "5", so element 0-4 are allocated.

If you repeat the same request, it is ignored - because partition "Q" is already assigned. However, a new request:

DIM @p(15)

Is honored, of course. It's offset is set to "5" and the partitioner is set to "20".  Etc. etc.

Of course, if you request MORE elements than are available, you get an error. 

The prefix "@" may be confusing, because "e@" is a local variable, but it has two advantages:

- First, the tokenizer automatically flags it as a variable, because it does the same thing to a single "@";

- It is clear, this is an extension to the array syntax.

There are also a few disadvantages to this approach:

- You can STILL approach the partitions using the original single "@" array;

- There is NO bounds checking. PRINT @q(10) just works fine.

Unassigned partitions feed the routine with such a bizarre index it has to bomb out. So that's not a problem. And yes, you can use a partition variable in any assignment. It's a variable as much as any other variable.

Now speedwise - "@" has an extra addition, but I wonder if you'll be able to measure any significant loss of speed. The penalty for local variable is negligible as well, may be a single DROP.

At the end of the message is my test program - just to give you an idea. Comments are welcome, of course!

Hans Bezemer

local (2)

a@ = 5

b@ = 3

' c@ = 4

print a@, b@

10 dim @a(5)

20 dim @b(10)

30 dim @c(200)

@(1) = 5

print @(1)

for x = 0 to 4

  @a(x) = 10+x

next

for @c(0) = 0 to 9

  @b(@c(0)) = 100+@c(0)

next

' 40 print @q(4)

print

print @c(0)

print

for x = 0 to 14

  print @(x)

next

[The Beez]

This is a full program using it. You may find it familiar. ;-)

Hans Bezemer

[The Beez]

Another tiny addition: the ASK() function now allows you supply a string variable or string expression - in addition to quoted strings. It doesn't just enhance its possibilities, but also makes up for shorter code. That are changes I like ;-)

Code in SVN.

Hans Bezemer