Author Archives: Tenoch

As we know, using nil is a little bit heavy in sool: optional variables must be “casted back” to non optionals using the if as syntax, or the boolean operator or. I was trying to write a simple linked list … Continue reading → Continue reading →

For design testing purposes, I was writing a mockup of some future standard classes, and trying to strain the template and interface system. I got into an interesting situation that suggests that we might need to be able to extend … Continue reading → Continue reading →

One tiny thing bugged me while I was taking a shower this morning, about my big new shiny interface system. Basically, a class implements a few methods. object Foo method bar() end end — call: foo = Foo foo.bar() Then, … Continue reading → Continue reading →

Sitrep: we have interfaces, which simply define method sets. Interfaces are used: as bounds for template parameters (requiring compliance with the interface) as generic types (to which can be casted any compliant class) The major difference being that in templates, … Continue reading → Continue reading →

So, with all we said in the last post, sool now has interfaces, which also defines generic classes that can be used to create generic code, which uses dynamic dispatch to work with every class that implements the interface. An … Continue reading → Continue reading →

So, what would sool look like without the classic inheritance mechanism, but with interfaces, embedded subobjects, dynamic interface type, and template with interface-restricted type parameters? As always, we want light but clear and unambiguous syntax, that exposes in a convenient … Continue reading → Continue reading →

In short, yes. But that might not be a good idea. First, why would we question their utility? they are a pain to code in the compiler, as I’ve been learning recently. Sure, that’s a compiler-writer problem, but still. they … Continue reading → Continue reading →

Inheritance, we know it, is a cornerstone of object-oriented programming, along with dynamic dispatch, abstraction, encapsulation, and subtype polymorphism (your mileage may vary). In particular, the combination of inheritance, dynamic dispatch and subtype polymorphism allow us to flexibly enjoy: code … Continue reading → Continue reading →

I’ve been a lazy person, and haven’t worked on the compiler’s implementation in a while. I’ve been stuck on some big design problems (namely, template class instantiation) and wandered away to easier activities. And, to make things even more stuck, … Continue reading → Continue reading →

I definitely don’t plan to put threads in the current version of sool, but it doesn’t prevent me to think about future features. More and more, we need applications that spawn multiple subprocesses, each running independently and at the same … Continue reading → Continue reading →

Conditional statements as expressions In my small review of Rust, I noticed one useful thing, that was the fact that the branches of if-else constructs could “return” a final value, which made the whole construct an expression, that could be … Continue reading → Continue reading →

Class and struct renaming One thing has always bothered me while writing my compiler, it’s the fact that the words “class” and “struct” have a very different status, although they are used at the same level. Lemme clarify. A class … Continue reading → Continue reading →

What I found most special about Rust is that every variable is always initialized, and no pointer can ever be NULL. In C++ or sool, you allocate an object of a given type, and then fill its members. In Rust, … Continue reading → Continue reading →

So, Mozilla released version 0.1 of its upcoming programming language Rust. I read the tutorial that presents most of its aspects, and I found a few things worth noting, in terms of programming language design. Types Rust supports natively all … Continue reading → Continue reading →

Oh no, more structs! So, I had a bit of a blank in my head during implementation, when I was dealing with the ref keyword, which is meant to signify that a struct as single return value of a method … Continue reading → Continue reading →

My implementation is going well. The lexer was easy, the hand-written descent recursive parser is OK so far, and I even started the semantic analyser for the classes’ interfaces. Even using C++ has been somewhat pleasant. I suppose that the … Continue reading → Continue reading →

After the enlightening comment to my previous post, I realized I got it somewhat wrong. By maybe trying to mimic Lua too closely, I lost track of the fact that since my language was going to be, in fact, deeply … Continue reading → Continue reading →

Whence trouble came When applied to objects, I’ve always considered that the operators or and and were special and non-overloadable, because they relate to variable properties instead of object properties (being nil or not). Likewise, the equality operator == acts … Continue reading → Continue reading →

Members’ initial values I hadn’t decided, but I think it will be necessary to allow members to have a default or initial values. True, it could be replaced by setting them in the init method, but I think it is … Continue reading → Continue reading →