Articles

The Design of Design

I just finished up reading “The Design of Design” by Fred Brookes JR (author of the Mythical Man Month):

This book is a reflection on the design process itself and, in particular, what good designers are made of.  Overall, I feel surprisingly positive about it, and basically enjoyed it.  Reading between . . . → Read More: The Design of Design

Implementing Actors on the JVM

Whiley adopts the [[Actor model]] of concurrency, instead of the traditional [[Thread (computer science)|multi-threading]] approach used in e.g. Java.  The actor model is simple and easy to use, and is less likely to result in complex [[race condition|race conditions]] or [[deadlock|deadlocks]]. The Actor Model has been around for a while, but Erlang has recently . . . → Read More: Implementing Actors on the JVM

Indentation Syntax in Whiley

Like Python, Whiley uses indentation syntax instead of curly braces for delimiting blocks.  When I started using indentation syntax with Python, I was pretty skeptical, but  it grew on me fast and now I really like it.  However, this wasn’t the only reason I chose to use indentation syntax in Whiley.  The other is . . . → Read More: Indentation Syntax in Whiley

Function Pointer Syntax for Whiley

One of the next big issues needing to be addressed is the syntax for [[function pointers|function and method pointers]].  The syntax I’m thinking of is close to that used in C and C++ (see e.g. here and here).  My initial idea results in something like this:

define MyComparator as { int compareTo(MyRecord,MyRecord) }

This . . . → Read More: Function Pointer Syntax for Whiley

Field Resolution in Whiley

An interesting issue has arisen as a result of my recent decision to move away from a declared-type model.  The issue is essentially about [[Scope (programming)|scope resolution]] of fields and local variables.   For example, consider the following:

define MyProc as process { int f } void MyProc::m(int x): f = x

Now, m(int) is . . . → Read More: Field Resolution in Whiley

Better Namespaces

An interesting problem I’ve encountered many times in Java is that of conflicting names.  For example,  suppose I have the following code:

import wyil.lang.*; import wyil.lang.Type.*; … public static Type T_Bool = new Type.Bool();

This is all well and good.  The problem arises when I want to import another class called Type from some . . . → Read More: Better Namespaces