Arrays Yet Again

But hopefully once and for all. What started in Disarray, and then seemed briefly Final, yet was still Revisited, has, just perhaps, at last settled into a design that doesn’t nag me. (Or, at least, doesn’t nag me so much I find myself constantly chewing on the bone.)

It feels that I have finally solved how I want BOOL to do arrays!

Always subject to changing my mind, of course.

The biggest change is dropping the idea of a distinct array type and requiring that each Model support array instances. This removes that messy dual-Model syntax as well as issues regarding how to do the array’s Model.

As a review, the original scheme:

*array [10] *int my-array
*array [8][8] game-board

Was replaced by:

*array <*int> [10] my-array
*array [8][8] game-board

Then there was a tweak involving the dimensions:

*array <*int> my-array/10
*array game-board/8/8

(An alternate idea used commas instead of slashes.)

In all cases the second Model was optional. The idea being that arrays could be lists of varied-type objects or lists of a specifically typed objects.

But BOOL already has generic lists — they’re a fundamental part of BOOL, so arrays are free to be mono-typed. Which means no need for an *array Model.

I also decided to move the dimension declaration to the Model (rather than after the name), so now array declarations look like this:

*int/10 my-array
*int/8/8 game-board

Which is nice and clean!

Following are some examples…

Arrays can be initialized, just as with any object declaration:

*int/10 arr =1,2,3,4,5,6,7,8,9,10

BOOL supports numeric and alpha ranges:

*int/10 arr =1...10

If an array is initialized, the dimension specification can be generic:

*char/* letters = "A...Z"

The dimension specification can be a numeric object:

*int dx =20
*int dy =20
*float/dx/dy grid

Array access looks like this:

set: arr/0 3
set: arr/1 4

set: game-board/3/7 0

Access to member objects of an aggregate object uses the same technique as array access:

*point p =10,10
set: p/x 12
set: p/y 12

In an array of aggregate objects, array access binds more tightly than member access:

*point/10 parr
set: parr/0/z 10
set: parr/0/y 11

Access to individual members of a list uses the same notation:

=A, B, C, D, E, F
set: stuff/2 M

The general idea behind the access technique is that it apes file paths.

Here’s a more involved example:

*int mx,my =8,8
*float/mx/my grid

*int x,y =0,0
@while lt:x dx
.   @while lt:y dy
.   .   set:grid/x/y add:x y
.   .   set:y add:y 1
.   set:x add:x 1
.   set:y 0

With any luck, this is the last time I’ll have to write about this!

%d bloggers like this: