A Lexical Mistake

Ok, my prototype is slowly moving along, but one thing still alludes me. What is the best set of objects to bootstrap the system with, and which objects should be written on top of the system after the system is running?

The final version of the language was meant to be based on a concept of method inlining. Basically, since most memory accesses are more or less constant events within a message, and even when they’re not, most of the code could be inlined further down the message stack, we could rather than using conventions or making the language very memory neutral/high level, we can instead allow programmers to directly manipulate their objects.

Of course this doesn’t really help us now (the current prototype is based on Squeak, which lacks the effective memory model to warrant using raw memory layouts yet), but even if we did implement this approach, we would still require a more generalized object layer on top of it. For this reason I believe that implementing a more restricted object model is in order.

To start with, I believe the basic object structure will be needed (Objects must be defined by the external system), and from there I will attempt to describe the general structure of the language using the Multi-Method equivalent of delegation (traits). This will include all of the necessary interfaces required to make the language self sufficient post bootstrap (except the Virtual Machine itself which will be rewritten in C or Haskell until the language can compile itself).

There will also be several objects that need to be constructed right from the word go, which includes, roughly, Integers, Floats, Strings, Symbols, Lists/Arrays, Dictionaries, Classes, Traits, and the base level behavioral interfaces that apply to all objects. These objects will be provided from Squeak directly, or will be implemented on a Generic object Squeak class, which can provide all of the necessary behaviour to bootstrap language level objects.

One last point I’d like to make. The behavioral interfaces do not actually apply to Mention objects specifically, but rather describe how the programming environment reacts to objects in general. Any object may be added to the Mention system simply by defining the fundamental interfaces required (essentially just some relative typing information for the dispatch engine), and then it can be used anywhere in Mention that actual Mention objects can be! In-fact, this goes so far in the language that there will very likely be components that do not even encode type information into objects for the sake of performance (no object headers or garbage collection). This is possible if the interfaces do not require any dispatching at runtime (otherwise the lack of type information interfaces will cause compilation errors!).

Anyway, hopefully I’ll have the prototype more or less working soon and you’ll be able to check it out for yourself, though it won’t do very much at the moment;)

– Lorenz

Creating a programming language is hard. I’m not talking about the kind of hard that’s involved in math problems or even getting pwned with that rather expensive new internet connection (no, its not the mouse either… you’re really just not that good;). No, I’m talking about the sheer amount of effort required to first come up with your amazing, world changing programming language, and then realizing that you actually need to implement the whole thing a few times over, using variations of that language that are in-fact worse than what you started with (unless your using Java, in which case, jump right ahead).

As you might have guessed I’m mainly writing this out of mere frustration, that even the dumbed down, simplified variation of Mention that I’m attempting to bootstrap is going, well, slowly. Very slowly.

So far I’ve come to the conclusion that there may even be some general rules of thumb, which to the enlightened few, might not actually seem all that obvious. Firstly, the current attempt to bootstrap Mention is utilizing the Squeak programming language/tool-chain, in the hopes that it would help to speed up the development process. It didn’t. Actually, I’m even wondering if its actually slowing me down… Which brings me to the obvious question. Why?

The most useful languages that spring to mind after asking this question, probably actually come from the Lisp family, along the lines of some dialect of Scheme + a parsing language to complete the picture. But what would make a language like Lisp, outgun its successors like Smalltalk or perhaps even python. Well, actually, I think python might even work, but Smalltalk has issues… Namespace issues.

The issues with Smalltalk I’m referring to are the conventions surrounding the naming of global variables, or at least the lack-there-of. Many scripting languages and most Lisps, allow the programmer to assign to any old variable name, and its simply there, for the entire world to see. But of course, when you have to think in objects, you can’t expect to have globals. After all, good Object-Oriented software should be based on the interaction of object, and not glorified globals, singletons, or otherwise. Although you could be mistaken for thinking that the Application object is actually a global, but of course its not. Why, well I’m not sure really, its just not.

I’d rather not go on any further with this, but the point is simple. We know that software systems evolve, and don’t simply get designed and then implemented. And we know that software is not actually re-used until at least some refactoring has been performed (generally more than some). So why can’t we just use our globals while we understand the problem we’re working on, and if they do the job we can just keep them, and if they really are flakey code smells bend on silicon armageddon then we can simply refactor them once we understand how the problem breaks down into the individual problem level (application, subsystem, et cetera) objects.

– Lorenz (feeling slightly better ;)

Well I finally bit the bullet and decided to learn the Haskell programming language. For those in the know, Haskell is a very strictly typed language (like some kind of draconian Java dialect), which uses a type inferencing technique to allow the programmer to write code without excessively typing… well… the types really.

What makes the language interesting however, is that is does this kind of strict typing from within a pure functional syntax (one that is very close to the mathematical lambda notation), and quite literally everything except the bindings themselves are first class values (objects really), and they all have types, which are themselves of some type and all can be fully reasoned with using the full capabilities of the syntax.

What all this means is that unlike Scheme (Lisp), instead of allowing objects of any type as values, all values and expressions must be the the correct type in any given piece of code (or they must be inferred transitively from their surrounding/contained code). Any mismatches are not allowed by the languages semantics and will cause compilation (or interpretation) errors.

This brings me to the point of this post, is a strictly typed language actually less or more capable than a weakly typed language. Also, if this is the case, does is it make the language better, or are other considerations more important (i.e. architectural concerns)?

I find this discussion interesting since it quite effectively contrasts the type system I designed, for Mention. While Mention’s type-system is effectively not just weakly typed but in many cases not checked at all, it allows arbitrary objects to be used in most situations, as long as they conform to the interfaces requested (in the type annotations or implicitly like Smalltalk).

Already I’m finding that I miss the more flexible type system when I find the only error messages cryptic type incompatibilities (what do you mean the type ‘a -> [a] -> a’ isn’t compatible with ‘Num a’… Hell where is that number anyway?). It is slowly getting easier as I understand the impressive type reasoning capabilities of the language, not to mention the ominous Monad magic (think C++ templates on steroids… although probably very much easier to use effectively)

Presumably as I continue to work with both Haskell, Smalltalk (Squeak), and Mention I can come form a better opinion on the effects of strong vs. weak type systems (in languages with first class function and type objects). Oh… and they are right… Haskell does seem to be a language well worth the effort to learn effectively.

– Lorenz