At some point this year I realized I’d almost entirely given up on ever finishing BOOL, and I decided that was okay. The language was always butt ugly, and conflicting design goals combined with a lot of indecision,… it just began to seem pointless, so I decided to stop thinking about it and move on.
But recently I find myself noodling around with the idea of, yes, damn it, finishing it in some form, even if it doesn’t come that close to the original dream (which has proved problematic).
I’d gotten pretty close back in 2016 with Python, so why not?
There was meant to be a third article in the Native Objects series that would discuss the Actions (“methods”) supported by the native Models (“classes”). But I’ve only begun to define those things. For now, suffice to say that typical data types (integers, floats, strings, etc.) have the methods you’d expect. Assignment for all, basic math for the numeric types, stringy stuff for the string; you get the idea.
I’ve reached another major milestone, but I’m also about to begin another design phase as I figure out exactly how to implement the native Models. And I may be taking a break from this blog to give BOOL a rest and to deal more with other matters.
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.
I’ve changed my mind about the Gated List syntax. (These mind-changes are a key reason BOOL design is endless!) The idea of binding a label to the first statement in a List to indicate a Gated List just didn’t make good sense to me.
The problem is two-fold: Firstly, a key reason for Gated Lists in the first place is their use as named Action clauses. When the label is buried in the List (because it now belongs to the first List member), there’s no sensible way to migrate the label to the List. Secondly, a label on the gate expression really makes no sense and has no value.
So I’ve come up with something new!
I’m once again having a go at creating a BOOL Reference Implementation. I’ve tried this in code nearly half a dozen times before, and I’ve doodled countless lines of pseudo-code over the years, but I’ve always gotten bogged down in details and unknowns before.
I think I just solved a long-open issue in BOOL regarding conditional Lists. It’s something that’s been nagging me a long time. For one thing, it’s one place that’s line-sensitive, and BOOL tries to avoid that. (Actually BOOL is very line-sensitive, but not that way.)
The other thing is that it conflated two things into one, and that’s also to be avoided. Clarity is everything, and not overloading concepts is an important part of clarity. (Orthogonality is another clarity goal that BOOL considers important.)
The background for this goes back to a BOOL primary design goal and technique.