Strange how my thoughts turn to BOOL in the early part of even-numbered years. (I wonder if it has something to do with the San Francisco Giants baseball team, although I don’t know why, and I’ve been hitting even-numbered BOOL version years longer than they’ve been winning World Series, plus I hope they don’t win this year.)
But in any event, I found myself pondering the
*array type (again)…
I think the final piece of the array puzzle finally fell into place. The issue resolved when I last wrote about arrays — whether all data Models have array capability versus arrays being a distinct data model — still stands.
The final piece involves a slight syntax change and — much more importantly — the full rationale for the array syntax. Not really having one was a bother; it made arrays seem arbitrary and patched on. The rationale brings them more fully into the BOOL fold.
One of the things that’s kept me from completing BOOL is that I haven’t been able to make up my mind regarding arrays.
There are two basic directions: All data types can have the native ability to create single or array instances, or the Array type is a special data type that can make an array instance of any data type.
There is also the issue of what should be the array syntax. How are arrays declared, and how are array members referenced?
I think, after all this time, I have finally made up my mind.
In the last article I explained where the name, BOOL, comes from. This article concerns the names of things within BOOL.
Languages have various terms for the concepts reified by by the language. For example: “sub-routine”, “function”, “method” and “procedure” all describe the same thing, a chunk of code that can be called by other code. The terminology for data objects is even more diverse!
In part to find the most descriptive words—but also to find new terminology for fun—BOOL has its own terms for the basic concepts.