It’s Alive! (Sort of)
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.
Native Objects, part 1
Languages generally come with two distinct sets of features: native objects and library objects. The former are often built into a language, for example int and float in the C-family languages, or date and array in JavaScript. Such “binary” native types are quite distinct from user-defined types. In other languages, Python for example, there is little or no distinction between native types and user-defined types.
The lack of distinction is more common in object-oriented languages, and BOOL is not exception. Native types “look” identical to user-defined types; operationally they are identical. The next few posts discuss BOOL’s native objects.
BOOL-M
I’ve reached a huge milestone with BOOL, and it all happened through serendipity! I was creating canonical source examples and hand-compiling them into an off-the-cuff “language” to give me some sense of what the compiler would have to do to generate output. It’s probably the robot in me; when I invent off-the-cuff pseudo-languages to express an idea, I tend to make them very regular, very machine-readable.
This time that got me to thinking, “I bet it would be fairly easy to write a compiler for this stuff!” The figuring out part (the hard part) of the parsing is already done; the code I was generating (as a human compiler) just needed to be assembled.
