Monthly Archives: December, 2013

BOOL RTE (continued)

Picking up where I left off regarding run-time sub-systems, there are a few more to mention. In a stripped-down version of BOOL, these sub-systems could be stubbed out, but proxy agents would still have to represent them. All the sub-systems discussed in these two articles are required to be present, but not all are required to be functional.

Obviously, non-functional sub-systems still accept Messages and respond appropriately, if only to signal their lack 0f function. No application can fail due to lack of a sub-system’s presence, but any application may be unable to continue due to lack of a specific resource.

This means applications must be aware of the potential for a sub-system to return a “no can do” response.

Continue reading →

Advertisements

Message Arity

There is another long-standing knotty BOOL issue that I’ve recently resolved. It has to do with the arity of functions. The original syntax of BOOL assumes the compiler knows how many arguments go along with any given Message. There is always at least one argument, the target object of the Message.

The problem is that how many other objects are involved depends on the the Message. For example, an add: Message has its target and one other object (as do nearly all math, relational and logical operators). But some Messages, sqrt: for example, only have their target.

The compiler needs to know this to build the Message properly!

Continue reading →

Invoking Actions

Finally, a post not filed under Basics!  I’m in a BOOL development mode (they come and go over the years), so more advanced topics are likely. I’m making what feels like excellent progress. Maybe once this phase completes, I can set down to the business of really documenting BOOL here.  (Assuming the development doesn’t end in frustration and tears and I put the whole mess on the shelf for another few years.)

I’ve been mucking about with my Python implementation trying to work my way through an implementation aspect I’ve never been able to see clearly. It has to do with how BOOL invokes code sub-units. We’re talking about “calling” what are variously called: sub-routines, routines, functions, procedures, methods or sub-programs. At least the term “call” is fairly global; in fact, the generic term for these things is “callable unit.”

Continue reading →

List Syntax

A design goal BOOL had from the beginning is that it should not use block scope delimiters. That is, I wanted neither the C family’s {curly braces}, nor did I want the ALGOL family’s BEGIN and END keywords. But how to indicate scope? If tokens at the ends are forbidden, the items themselves must somehow indicate their scope.

I hadn’t yet heard of Python and its elegant use of whitespace, but that’s the sort of thing I wanted. I came up with something similar, called “dot lists.” (Just not trusting the idea of indentation alone — turns out it’s totally bitchin’!) As it happens, since you can re-define the “dot” character, by changing it to a TAB character, you can have Python’s whitespace indentation!

With a couple extra BOOL-ish wrinkles!!

Continue reading →