Tag Archives: Message
A recommended idiom involves defining Actions to implement Singleton Messages. This cleans up source code by removing the need to use the semi-colon, and shifts possible “Unknown Message” errors to data type errors, some of which can be detected at compile time.
One of the final hurdles in designing a BOOL implementation involves temporary objects. Any operation on an object may result in a transitory new object that is consumed by later operations. For example, in the arithmetic expression “5 x (3 + 4)” the addition operation creates a transitory value — 7 — required by the multiply operation.
The question for an implementation is, “Where to store such temporary objects?” In some languages, CPU registers suffice to store transient values (such as seven), but in object-oriented languages, registers aren’t enough. Objects take up some space, and often temporary objects need to be addressable.
There is the situation when an operation takes multiple operands, and one (or more) of those operands are inappropriate for the operation. For example, suppose an integer add operation was passed an integer object and an open file object? There is generally no “add” semantic for an integer and a file.
Total incompatibility results in a run-time error, but sometimes values are compatible enough for the operation to proceed. How the system accomplishes that often involves casting one value into another.
I recently determined to use a trailing marker — a semicolon — to close the list of arguments due a Message. But after using it for a while, I’ve decided that this:
. set:x add: mul:a b; div:c d; ;;
Is butt-ugly and has to change. Since I still think registering Message arity is an even worse option, I’ve had to take the only other real option: assuming Message arity.
The previous article introduced the basic run-time environment, the native
@global Actions that harbor all code and data objects. This article describes the required native Models and Actions found in the
@system Action. There is a core set of Models required for BOOL to function and an extended set that provides more complex data types (such as trees and tables).
Again the retirement free time, the pleasure of Python, and perhaps it just being the right time, conspire to move the BOOL project forward into new territory. The Reference Implementation is coming along nicely on several fronts. The design of various objects has become solid enough to use in writing bits of code.
In particular, it’s possible to discuss how objects are represented in Python, and it’s possible to start thinking about the code that works with those objects. With the BOOL source definition becoming more stable, it’s also possible to start thinking about compilers. This post introduces these things; in some cases, in some detail.
For dessert, I’ll briefly mention a BOOL XML binding.
From the beginning BOOL had this concept of System Messages, but they’ve never worked out — even as a design idea. Now that I’m working on the first realistic BOOL implementation, it’s even more clear the idea isn’t up to the reality.
System Messages — at least as an orthogonal idea — are dead. The few that are fundamental to BOOL still remain. Two of the more important ones are the Query Message (
q:) and the Execute Message (
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!
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.”
By now you’ve noticed that BOOL uses a lot of symbols. It steals (and runs with) the ball from Perl mostly, which uses punctuation symbols to determine basic data types (scalar, array, hash, and so forth). Many forms of BASIC have also used punctuation symbols to determine data type.
BOOL uses them to define basic meta-types of objects in BOOL, and it uses them to distinguish between definitions of new objects and references to existing objects.
And while it does make BOOL have a bit of that “line noise” look that so uglifies Perl, the syntax has been there from the very beginning, so it’s not going anywhere. Consider it part of BOOL’s “charm”.