Indeed, it required the lexer to disambiguate expressions like that: “obj setX::# comment #:value” by parsing “setX:” as one token followed by a comment, followed by an identifier… Which would force the user to separate manually the tokens by adding spaces: “obj setX ::#comment #:value” would become identifier “obj” followed by identifier “setX” followed by a one-line comment.

So I changed that, now comment blocks would be written like that: “#: comment :#” and one-line comments would start with “##“. This syntax retains comment nesting in comment blocks and removes all ambiguities since “#” is merely used for nothing much currently, whereas colons are used for keyword messages, class inheritance and assign operators…

I’ve edited my previous posts to fit in the new syntax.

When Apple announced blocks for C/ObjC/C++ in Snow Leopard, I was thrilled, what a great powerful idea for the code. On the users point of view, you could write code that can be injected into the implementor’s (Apple) algorithm, without the need to rewrite it or provide an ugly context pointer that the implementor would need to manage as well. Blocks are also great for the implementor because it allows him, without changing its API, to increase the efficiency of his algorithm over time.

Knowing that, I told myself: “Great! Blocks are beautiful and they can make it more efficient over time than their foreach construction”… Well, when I did benchmarks on Snow Leopard to compare -[NSArray enumerateObjectsUsingBlock:] and for( in ) construction, I was kinda disappointed… Foreach was still more efficient than the block enumeration… And by far.

However that’s normal, the difference between both constructions is that the -enumerateObjectsUsingBlock: needs to make a function call (the block’s code) with each parameters while iterating; whereas for( in ) does one method call for a bunch of objects (usually 16) and then do an inline iteration through the local C-array of objects.

Now, is foreach always more efficient than blocks in iterations ? Well no, it really depends on what you do in the iteration code. For example, it is more efficient to get the set of indexes to take from an array A to put in array B, than adding each objects one by one. That’s normal too! When you add objects one by one, the array will allocate a little block of memory to make the objects fit in it, but when you add  a whole big array, it is capable to allocate enough memory for all objects to fit in it at once…

In this case, the only way to make foreach to really compete with -indexesOfObjectsPassingTest: is to build the index set yourself… It would be generally slightly slower than block enumeration, because you would simply do [indexSet addIndex: idx] whereas Apple algorithm does it by ranges. So, instead of rebuilding the wheel, it is better to use the index enumeration through blocks.

This shows how benchmarking can be useful, when you have the choice between two seemingly efficient techniques, don’t try to guess !

Here follows my own benchmark for 10 million objects (on a MacBook Pro 2.8 GHz and 4 GB of RAM), here are the results I get (in seconds):

• Block: 2.122398
• Foreach: 2.855717
• Foreach indexSet: 2.224305

Here is the code to do the benchmark (need to be compiled with blocks on, Foundation framework and optimization to 0):

#import <Foundation/Foundation.h>

#define COUNT 10000000

void testBlocks(NSArray *allObjects)
{
  NSMutableArray *selectedObjects =
    [NSMutableArray array];

  NSDate *start = [NSDate date];

  NSIndexSet *indexes =
    [allObjects indexesOfObjectsPassingTest:
     ^BOOL(id obj, NSUInteger idx, BOOL *stop)
     { return (idx % 20) != 0; }];

  [selectedObjects addObjectsFromArray:
   [allObjects objectsAtIndexes:indexes]];

  NSLog(@"Block: %f", -[start timeIntervalSinceNow]);
}

void testForeach(NSArray *allObjects)
{
  NSMutableArray *selectedObjects =
    [NSMutableArray array];

  NSDate *start = [NSDate date];

  NSUInteger i = 0;
  for(id obj in allObjects) if((i++ % 20) != 0)
    [selectedObjects addObject:obj];

  NSLog(@"Foreach: %f", -[start timeIntervalSinceNow]);
}

void testForeachIndex(NSArray *allObjects)
{
  NSMutableArray *selectedObjects =
    [NSMutableArray array];

  NSDate *start = [NSDate date];
  NSUInteger i = 0;
  NSMutableIndexSet *indexSet =
    [NSMutableIndexSet indexSet];

  for(id obj in allObjects)
  {
    if((i % 20) != 0) [indexSet addIndex:i];
    i++;
  }

  [selectedObjects addObjectsFromArray:
   [allObjects objectsAtIndexes:indexSet]];

  NSLog(@"Foreach indexSet: %f",
        -[start timeIntervalSinceNow]);
}

int main(int argc, char **argv)
{
  NSAutoreleasePool *pool = [NSAutoreleasePool new];

  NSMutableArray *allObjects =
    [NSMutableArray arrayWithCapacity:COUNT];

  for(NSUInteger i = 0; i < COUNT; i++)
    [allObjects addObject:
     [NSNumber numberWithUnsignedInteger:i]];

  testBlocks(allObjects);

  testForeach(allObjects);

  testForeachIndex(allObjects);

  [pool drain];

  return 0;
}

The $ sign

Okay, it will seem weird (or ugly) for some of you, but this is the only way I found to keep the syntax coherent and remove ambiguities in the language. The $ sign serves only one purpose in the language: defining local variables. It actually separates the type from the variable name, example: “Point $ origin := value.“. Spaces around it are optional. Since the $ sign is only used when declaring a variable, you can also remove the type before the $ if the type of the variable can be inferred from its initialization value. It also allows you to define multiple variable of the same type (if it is explicit). For example:


Point $ origin := Point new. ## explicit type
$ center := origin. ## inferred type from the origin's type
$ other := Point new. ## inferred type from @Point new return type.
## note you shouldn't put a period after Rect new in this declaration, because then "bounds" type would be unknown.
Rect $ rect $ frame := Rect new $ bounds.


This syntax is necessary to avoid ambiguity of such declaration: “AppKit BezierPath bezierPath.“, is this the message “bezierPath” sent to “AppKit BezierPath” object -or- is it a declaration of the “bezierPath” variable of type “AppKit BezierPath”? The $ sign removes this ambiguity:

• “AppKit BezierPath bezierPath.“: this is the message sending;
• “AppKit BezierPath $ bezierPath.“: this is the variable declaration.

Namespaces

One of the big demands concerning Objective-C, was namespaces, and it seemed like a good thing to add to this language. Namespaces are just a way to group classes, types, structures, and even other namespaces. This is the syntax:

namespace NamespaceName
{
## declarations
}

To access objects defined in the namespace, you simply use the message syntax:

## Definition of the Cocoa namespace with a nested AppKit namespace
namespace Cocoa
{
namespace AppKit
{
class BezierPath : Object { #: defs :# }
}
}
## Using the BezierPath class outside of the Cocoa namespace
Cocoa AppKit BezierPath $ path := Cocoa AppKit BezierPath new.


With that feature, you can see the use of the $ sign to indicate a variable declaration. Everywhere you can put a type you can use the whole declaration. For example: “- (Cocoa AppKit BezierPath)buildPath.“. The namespace construction will reduce most name collisions in bigger projects, it also allows more modularity by separating the classes into larger logical sets.

Import

Okay, this namespace syntax is cool, but can become really heavy when you use the same type quite often. So, you can simply use the import keyword to tell what namespace you want available  in the current scope. How do you use it: “import Cocoa AppKit.“. As I just said, it is scoped, so you can put it in a block and the import will only be valid for that block.

Typedef

Typedef allows type aliasing. Its main purpose is essentially providing a more readable name for product and sum types, but it can be used for other types as well. The syntax is as follow: "typedef <new_name> <existing_type>.“, example: “typedef Person { String firstName, lastName. }.“.

Nesting

We saw earlier that namespaces could be nested into other namespaces. You can do this for other types as well. Classes and structures can be nested into other classes or structures, as if you accessed it from outside of a namespace, in a similar way to C++’s “vector<string>::iterator”, that is the enclosing class retains its generics and can pass them to its nested classes.

Also, a nested class methods have the same accesses to ivars of the enclosing class’s then one of its methods. You can as well restrict access to the nested classes from outside using private or protected access modifiers. Enums can also be nested into classes or structures and have the same access restrictions.

Protocols

Protocols, as called in ObjC, AKA interface in Java/C#, is another tool to enforce typing. Protocols define a contract a conforming object must comply with, for objects, that require the protocol, to show exactly what they need to do their work. A protocol only declares methods and properties, a class that conforms to the protocol must implement the required methods of the protocol and can define any of the optional methods it declares. The protocol syntax is pretty simple:

[attributes]
protocol MyProtocolName <Protocol, List>
{
- (void)requiredMethod.
optional
- (void)optionalMethod
{
self requireMethod.
}
required
- (void)otherRequiredMethod.
}


Note that a protocol name is in its own namespace, which means it can have the same name as a class without collisions. As you can see, you can provide a default implementation for an optional method, it can only call required methods, or test for optional methods before calling them (unless they’re also implemented). If a class doesn’t implement an optional method, the protocol’s implementation becomes part of the class. It allows the implementor of the protocol to provide default behaviors depending on other methods of the protocol. For now, the only available attribute for protocols is “deprecated”.

Generics

Generics is another way to enforce typing, it’s usually used in collections. The principle is as follow: you provide at the beginning of your class, protocol or structure definition, a list of abstract type that are used throughout the construction. When the user will want to use a class that provides generics, he will be able to tell which are those actual types. For example, an array collection would define a collection of any kind of objects, and thus accept any kind of objects in or out. The user would have the possibility to tell which type he wants in that array, telling the compiler “this object will always contain string”, in this case the compiler will be able to do type-checks like “here you’re inserting an object that is not a string”.

The generics syntax is as follow:

class MutableDictionary[TKey as id<Copying>, TValue as id] : Object
{
- (TValue)objectForKey:(TKey)aKey.
- (Integer)count.
- (void)setObject:(TValue)aValue forKey:(TKey)aKey.
- (void)removeObjectForKey:(TKey)aKey.
- (Array[TKey])allKeysForObject:(TValue)anObject.
- (Array[TValue])objectsForKeys:(Array[TKey])aKey notFoundMarker:(TValue)marker.
}

You can see here you can define as many generic types a you want. You can then use the identifiers as types anywhere a type is expected in your class, notably as types for other generic classes. A user can also ignore the generic type of a class, by default, the type for a generic is “id”, that is “any object”. In this definition, you notice you can also force the generic type to have certain requirements.

As an example, in the MutableDictionary collection, the type TValue has no requirement (“as id” is optional), whereas TKey requires to conform to Copying protocol. If the user doesn’t set any type when instantiating the collection, these will be the defaults, so the compiler will do a type-check for keys to check whether the inserted object conforms to Copying protocol.

Method syntax

The method syntax is basically the same as in ObjC:
## Class methods start with a + and Instance methods start with a -
## Unary method
[method, attributes]
- (ReturnType)methodName
{
## method implementation
return value.
}
## Binary method, binary_op is any combination of the following characters: "~ ! @ % & * - + = | \ < > , ? / ^ `"
[method, attributes]
- (ReturnType) binary_op (ArgType)arg [argument, attributes]
{
}
## Keyword method
[method, attributes]
- (ReturnType)methodNamePart1:(Arg1Type)arg1 [argument, attributes] namePart2:(Arg2Type)arg2 := 0 [argument, attributes] namePart3:(Arg3Type)arg3 := 0 [argument, attributes]
{
}

Each method can be preceded by an optional list of comma-separated attributes surrounded by square brackets, among attributes you can have “deprecated” or “abstract” (other attributes might come later).
Arguments can also be followed by an optional square-bracket surrounded comma-separated attribute list, among attributes you can have “unused” and maybe others. In keyword messages, arguments (except the first one) can have default values, it is denoted with the assigned operator followed by a constant or an expression in parentheses. Setting a default value for an argument makes the compiler add the methods definitions automatically with the different arguments.
For example, this definition:
- (Integer)firstArgument:(Integer)arg1 secondArgument:(Integer)arg2 := 0 thirdArgument:(Integer)arg3 := 0.
Make the compiler create for you the following methods:
- (Integer)firstArgument:(Integer)arg1.
- (Integer)firstArgument:(Integer)arg1 secondArgument:(Integer)arg2.
- (Integer)firstArgument:(Integer)arg1 thirdArgument:(Integer)arg3.
- (Integer)firstArgument:(Integer)arg1 secondArgument:(Integer)arg2 thirdArgument:(Integer)arg3.

This means you can define:
- (Integer)firstArgument:(Integer)arg1 secondArgument:(Float)arg2.
- (Integer)firstArgument:(Float)arg1 secondArgument:(Float)arg2 := 0.

But not:
- (Integer)firstArgument:(Integer)arg1 secondArgument:(Float)arg2 := 0.
Because “- (Integer)firstArgument:(Integer)arg1″ is already defined

Thanks to the keyword syntax there can be as much different methods as there are different keywords. You can see, in the previous definition, that I don’t need to use secondArgument: if I just want the thirdArgument. In case the keywords are the same, the keywords are filled in the order they appear. For example in this definition:
- (id)performSelector:(Selector)aSel withObject:(id)obj1 := nil withObject:(id)obj2 := nil.
Generates these methods:
- (id)performSelector:(Selector)aSel.
- (id)performSelector:(Selector)aSel withObject:(id)obj1.
- (id)performSelector:(Selector)aSel withObject:(id)obj1 withObject:(id)obj2.
The “obj1″ in the second definition is the same “obj1″ in the third definition. Note that you cannot reorder keywords.

Property Syntax

Properties usually define accessors, and if necessary also define the storage for the variable they represent. You can also provide an implementation for either or both methods of the property. Whenever you’ll do a get outside of the getter method, it will necessarily go through the method, if you do a set outside of the setter it will necessarily go through the setter method. This feature is inspired from SalesForce.com’s Apex language. The syntax is as follow:

## default get and set all public
- PropType propName1 [attributes].
- PropType propName2 [attributes] { get. set. }
## default public get and private set
- PropType propName3 [attributes] { get. private set. }
## Provide an implementation for both get and set
- PropType propName4 [attributes] { get { return propName4. } set { propName4 := value. } }

Note: The variable “value” is the name of the setter’s argument, the method declaration is equivalent to: “-(void)setPropName3:(PropType)value.“.

Attributes can be:

• “readonly“/”writeonly“/”readwrite“: telling which methods are implemented.
• “getter=methodName“: provides an alternate name to get the value of the property
• “setter=methodName:“: provides an alternate name to set the value of the property (the colon is required)
• “weak“/”strong“/”copy“: tells how the property behaves with the garbage collector, strong is the default, copy is a strong reference too, but calls the “-copy” method of the value.
• deprecated

Constructors

BambooTalk implements a different kind of constructors than either ObjC or C++/C#/Java. Constructors in BambooTalk is actually a mix of the two.

In Cocoa, you have to define, in a class, a designated initializer, and you can define any number of secondary initializers. The designated initializer is the only init of the class that will call the designated init of the super-class, and all other initializers will call the designated one. Also the class must override the designated init of its super-class to make it call its own designated init. Respecting these conventions makes subclassing easier, making sure all the class and its super-classes designated initializers are called and their ivars properly initialized. It also allows all init methods of all super-classes to be usable on your own class.

BambooTalk constructors retains these conventions providing a syntax to let the compiler do the repeating code. Constructors are, like in ObjC, simple class methods, they are, in fact, Class methods with a different prefix character. Each class have, at most, one designated constructor, which is a class method that starts with “@“, and can have any number of secondary constructors that start with the “*” character.

The designated constructor doesn’t need to explicitly call the super-class designated constructor, although you can call it explicitly using “super designatedConstructor” syntax. If you don’t call it explicitly, it will be the first statement before your own code. When you define a designated init, the super-class designated init is overrode automatically and call your own designated init with nil parameters (or default arguments, if you provide them), if you want other default you have to override it explicitly and call the designated constructor explicitly. You can name parameters the same as your ivars, in this case, you don’t need to implement the constructor if all you do is copying the values.
Example:
## This class would usually be implemented as a struct
class Range : Object
{
- Integer location, length.
@ (self)newWithLocation:(Integer)location := 0 length:(Integer)length := 0 ## implementing is optional here
{
self := super new. ## reassignment is optional, calling super new is optional
self location := location.
self length := length.
return self. ## optional
}
* (self)newWithRange:(Range)aRange
{
## return is optional.
return self newWithLocation: aRange location length: aRange length.
## If the designated constructor is not explicitly called it is added at the beginning of the declaration
#: alternate implementation:
location := aRange location.
length := aRange length.
:#
}
}

Notes:

• As an exception, the designated constructor’s first argument can have a default value to help the compiler generate the overridden version of the super-class designated constructor, as any other secondary constructor. However, when called explicitly, the first argument of the designated constructor is still required.
• If the reassignment of self or the return statement are wrote explicitly in the constructor, the compiler won’t generate the calls to the designated constructors.
• Constructors are class methods, meaning you can’t use a constructor name in another class method. The feature is really optional and allows you to let the compiler do most of the implementing work.

Complex Types

Classes

Classes in BambooTalk are equivalent to Objective-C classes and retain a very close syntax, a class:

• can inherit from other classes, with single-inheritance;
• can conform to any number of protocols in the manner of ObjC;
• has properties and methods, which can have access restrictions (public, protected, package, private);
• can have categories to add new methods;
• by default, all properties and methods are public to a certain extent

The syntax is pretty similar to ObjC classes, except for the used keywords:

class ClassName : SuperClassName <Comma, Separated, Protocol, List>
{
private
+ Integer count. ## class property
- Integer count. ## instance property

protected
## instance method taking one argument (binary message)
- (Integer) + (Integer)arg { return self count + arg. }
}

As you can see, like in ObjC, class methods/properties and instance methods/properties are in different namespaces and you can, without problems, define class and instance methods with same names. On the other hand, properties are in the same namespace as methods, so in this class, you can’t define -(Integer)count or -(void)setCount:(Integer)value separately outside of their property definition. However, BambooTalk supports parametric polymorphism/overloading, so you can define -(void)setCount:(Float)value method.

Note: public, protected, package and private work the same on properties and methods as they work in ObjC for ivars. The access modifier changes the nature of all declarations following it until the end of the declaration or until another modifier is found.

Structures

Structures are very close to classes, however there is no inheritance for structures, but they can still conform to any number of protocols. They can also define properties and methods. The lack of inheritance allows the compiler to optimize messages to structures and thus making the access more efficient. The syntax is exactly the same as classes although there is not super-class name:

struct StructureName <Comma, Separated, Protocol, List>
{
private
+ Integer count. ## class property
- Integer count. ## instance property
public
## class method taking one argument (keyword message)
+ (void)myMethod: (id)arg1 { Log print: arg1. }

## instance method (unary message)
- (void)myMethod { #: do something clever :# }
protected
## instance method taking one argument (binary message)
- (Integer) + (Integer)arg { return self count + arg. }
}
You can see that you can also have class and instance properties/methods in a structure type.
Note: Structure names lie in the same namespace as class names.

This conclude the article. In the next article, I will discuss features shared by both complex types: properties, constructors, etc.

BambooTalk actually defines two typing systems: typing is both static and dynamic, while at runtime every message is dispatched dynamically like in SmallTalk and ObjC, you can help the compiler in helping you debugging your code more easily by using static typing. Static typing works the same as in ObjC, you give a specific type to a variable, the compiler will always consider that this variable will have the same type at runtime and thus will respond to selectors of this type, allowing the compiler to check whether you’re sending messages to an object that doesn’t respond to it.

The improvement, compared to ObjC, will be the possibility to override methods in subclasses and provide a return type that is a subclass of the return type in the super-class, without making the compiler shout about type mismatch. BambooTalk will also include type inference, for example a method having the return type “self”, or taking “self” as an argument, will be considered as returning the type of the receiver, even if it’s not the actual receiver that is returned. Another improvement is generics, BambooTalk will provide generics as a mean to enforce object types. For example, you could say that an array can only accept objects of type Integer. I will discuss these features in the next articles.

The Type Families

There are two kinds of types: simple and complex types. Complex types are discussed in Part 2. Among complex types you have structures and classes, and among simple types you have enumerations (equivalent to enum in C), product (equivalent to struct in C) and sum (equivalent to union in C). The difference between the two kinds is that complex types have properties and methods, whereas simple types only have attributes.

Simple Types

As Lolcats would say, “simpel typs R simpel”. They are easy to construct and have a simple syntax. Sum and product type can even be constructed on the fly where they are used. Enumerations on the other hand are preferably defined at one specific place and define constants, like in C. The other difference is that enums have an explicit type name whereas the sum and product types don’t require it.

Enumerations

Enumerations have the same syntax as in C and the same behavior:

• They represent integers;
• By default, they start at 0;
• By default, the value of subsequent constants is incremented by 1;
• You can force the value of the constant using the assign operator.

The syntax is equivalent to C’s (minus the required end-of-statement marker after it):
enum EnumName
{
value1, ## implicitly set to zero
value2 := -2, ## explicitly set to -2
value3, ## implicitly set to -1, the last comma is neither required nor an error
}
You can access an enumeration constants by using message syntax on the type, like a property, for example: “myVar := EnumName value1.“. This syntax is inspired from C#, the advantage is that it encapsulates each constant names into its own namespace, allowing one to reuse the name in other enums or even as types. The other advantage is that it helps in type checking removing ambiguities. Enum being integers there is no restriction as for assigning them to number variables.

Product Types

Product types are equivalent to C structures. They can store multiple variables of various types in one logical group. They are especially useful for return types as they provide a way to return multiple variables at once. The syntax is as follow:
{ type1 var1, var2. type2 var3. }
Note: there is no explicit name for the structure, I will show later how to provide one. Just like enumerations and classes, the members of the product are accessible using the message syntax:
{ type1 var1, var2. type2 var3. } v.
v var1 == v var2.
v setVar1: value.

Note: the setter uses the variable name with a capital letter. You can also use the assignment operator: “v var1 := value.“.

Sum types

Sum types are equivalent to C unions, however they can represent only one type at a time. The construction is only composed of types separated by a bar “|”, example: “{ type1 | type2 | type3 }“. This type is also useful in return types: a method can return nothing if it succeeded; or an error object that contains a description of the problem that occurred. How the type is tested or how the value is recovered is yet to be defined.

Comments

There are, like in ObjC, two kinds of comments, block comments (like in ANSI-C) and line comments (like in BCPL/ObjC/C99…) :

• Line comments start with two colons ‘##‘ and runs until the end of the line,
• Block comments start with colon and hash signs ‘#:‘ and finish with hash and colon signs ‘:#‘, comments can be nested and distributed over multiple lines.

All commented text is, obviously, ignored by the compiler. I chose not to use C-like // and /* */ because they represent valid binary messages, colon and hash signs aren’t valid binary message characters. For your information, SmallTalk uses double-quoted strings as comments: "this is a comment", though I prefer keeping this syntax for normal strings.

Expressions

In BambooTalk, every time you use a semicolon in C-like languages you will use a period ‘.’. Periods end a statement in BambooTalk just like they do in SmallTalk, this is because it’s closer to human languages and also because I find it nice. The semicolon, on the other hand is used for cascading messages, another nice feature from SmallTalk which I will talk about later.

Control structures

BambooTalk retains most construction from C-like languages:

• Conditions:
  if(condition)
#: statements :#
else if(condition)
## statements
else
## statements

• Loops:
  • while(condition)
{ #: statements :# }
  • do
{ #: statements :# }
while(condition).
  • for(initialize . condition . increment)
{ #: statements :# }

• Switch (for now it’s defined like in C, but might change in the future):
  switch(expression)
{
case value : ##statements
case value : #: statements :# break.
default : #: statements :# break.
}

• Collection iterations:
  foreach(variable in collection)
{ #: statements :# }
• Keyed/Indexed collection iterations:
  foreach(value_variable at key_or_index_variable in collection)
{ #: statements :# }

Other control structure can be added in the future. BambooTalk being a whole new language nothing prevents it from defining new keywords, I take advantage of this fact to introduce C#’s “foreach” construction and improve it a little bit. ObjC 2.0 defines the same construction, but uses the already existing “for” keyword from C to avoid the need of reserving an ugly “__foreach” keyword, like they did for “__block“.

So, BambooTalk defines “foreach(variable in collection) { #: statements :# }” which can iterate through any collection conforming to the fast enumeration protocol (yet to be defined) equivalent to ObjC 2.0′s.
It also defines the “foreach(value_variable at key_or_index_variable in collection) { #: statements :# }” construction equivalent to PHP’s “foreach (array_expression as $key => $value)“, which can iterate in any indexed or keyed collections, so it excludes set iterations. Any object conforming to the fast keyed enumeration protocol can be used with this foreach.

Along with those control structures, BambooTalk defines, like C-like languages, “break” to stop the execution of a loop or the flow of instruction in a switch, “continue” to go to the next iteration of a loop and “return” to stop the execution of a method and return control to the caller.

The sole actual operator of BambooTalk

As seen before, in BambooTalk “operators” aren’t operators but actual messages, in fact, BambooTalk only defines one operator. This operator is the assignment operator and is represented as a colon followed by an equal sign: “:=“. It is NOT inspired from Pascal (which I never touched) but from SmallTalk, which defines two operators, this one, and the return operator “^“.

This operator is evaluated from right to left, the value of the expression on the right is assigned to the variable defined on the left:
Example: a := b := c. ## the value of c is assigned to b and the value of b is assigned to a.

As I was thinking about the language design, a major C-user problem hit me: C reassign operators (like +=) are still valid messages in BambooTalk! The receiver of the message is passed as a reference to the message, so I wouldn’t be able to transform this statement “a += b;” into this “a = a + b;” without breaking the language coherence: the reference doesn’t allow the “variable” receiver to be changed from within the call (in ObjC, reassigning self does not affect the caller’s code), and enforcing special cases in the compiler is not an option (it’s ugly, error-prone and uselessly complex for nothing). So, to solve this problem, I thought about a new syntax for the language that would add more flexibility than normal reassign operators, and keep coherence of the language:

The reassignment syntax is as follow, “variable assign_op binary_message expression”.

For example: a := + b. is equivalent to a := a + b., the left operand is required to be a variable. Although the binary message represents a message, it will be evaluated last, for example “a := * b + c” would be transformed into “a := a * (b + c)” and not “a := (a * b) + c” as the messaging syntax usually suggests.

And last, but not least, due to right-to-left evaluation of (re)assignment operator, expressions containing multiple assignment operators are also evaluated from right to left.
Example: a := + b - c := * d + e. the first expression being evaluated is “d + e” then “c * (d + e)” reassigned to “c“, and then “a := + b - c” is evaluated.

Cascading messages

To finish with this article, I will talk about a nice feature from SmallTalk that I absolutely wanted in BambooTalk: cascading messages. The principle of cascading messages is about sending multiple messages to one receiver in the same expression. Only the first message of the cascading list has an explicit receiver, and all the other messages that follow uses the same receiver. The result of a cascading message is the result of the last message in the cascade: if previous messages return a value, this value is simply ignored, only the last return value counts. Cascaded messages are separated by semicolons.
Example: “a b; c; d; e; f.” this expression contains 5 messages and one receiver. The first message is “b” and its receiver is “a”, then each messages are sent to the same receiver. So, “a” receives sequentially the messages “b”, “c”, “d”, “e” and “f”, also the whole expression evaluates to the last message’s return value: on the caller’s point of view, the whole expression is equivalent to “a f.”, that is the message “f” sent to receiver “a”. Of course, if intermediate “b”, “c”, “d” and “e” messages were not doing anything, it would be useless to chain them.
Any kind of message can be used in cascading messages, for example: “a := 10. b := a + 5; * 4; - 1.” would assign the value 9 to “b” because “a – 1″ equals 9 and the return values of messages “+ 5″ and “* 4″ are simply ignored.

This construction is very useful as an alternative to big constructors, for example instead of “r := Rect newWithX: 0 y: 0 width: 10 height: 100.“, you can use the cascading messages as follow: “r := Rect new setWidth: 10; setHeight: 100; self.“. Note that the last message in the cascade is “self”, as I said before, the result of the whole cascading expression is the result of the last message: without self, the last message would be “setHeight:” which, like any setter, returns void, the result of the whole expression would be void, which is not suitable for an assignment. This is why “self”, that simply returns the receiver, is the last message in the cascade, so the result of the whole expression is the object we allocated at the beginning, namely the result of “Rect new”, and thanks to cascading messages, this instance also received “setWidth:” and “setHeight:” messages with 10 and 100 as arguments.

Some of those features might be difficult to understand, some of them might look weird, and some others are still in thinking process. Any comment, question or suggestion is welcomed. Thank you for reading.

As I said before, this language is based on both SmallTalk and Objective-C. The former has quite a simple philosophy: everything is an object, if it’s not an object it’s a message. And the latter OO model is actually the same as SmallTalk with the difference that it also retains compatibility with C.

BambooTalk philosophy should then be equivalent, I’ve retained a lot of nice stuff from SmallTalk and kept some from C/ObjC to prevent this language to become too alien.

Let’s start with messages. Messages are equivalent to method/member function calls in C++/Java/C#. In SmallTalk and ObjC, and thus in BambooTalk, a “message” is sent to a “receiver”, if the receiver can respond to the message it will return an “answer”. The “selector” of a message is an identifier that will be used by the runtime to find the receiver’s method implementation attached to the sent message, the selector is simply the name of the method.

BambooTalk keeps the 3 different kinds of messages from SmallTalk, namely: unary, binary and keyword messages.

Unary messages: they take the form of a simple identifier and have no arguments.
Example: “obj message”, here the unary message “message” is sent to the receiver “obj”.

Keyword messages: it’s the form that disorient most ObjC newcomers, but it is also a very nice auto-documenting message construction. It takes the form of a list of “keywords” representing the subparts of the message name, and each keyword is followed by an argument, a keyword is simply an identifier directly followed by a colon.
Example: “obj setValue: v forKey: k”, here the keyword message “setValue:forKey:” (colons are included in the name) is sent to the receiver “obj” with the arguments “v” and “k”.

Binary message: I put this one in the last position because it’s a nice feature of SmallTalk that may be confusing for C/C++/ObjC/Java developers. A binary message is simply a message taking one and only one argument, and the selector of the message uses only a special restricted set of characters: “~ ! @ % & * – + = | \  < > , ? / ^ `”.
As you can see here, binary messages look a lot like operators, but they really are messages, and they can be any combination of characters in this set, nothing prevents you from inventing your own “operators”, for example “~!&&//\\?^” is a valid binary message selector, I have no idea what it does though.
Although they look a lot like operators, they really are messages and since the receiver, like for all messages, is always on the left, they’re evaluated from left to right, which makes this calculus: “3 + 2 * 5″ equal to 25 and not 13, because this is equivalent to “(3 + 2) * 5″ and not “3 + (2 * 5)”. In one word, there is no precedence between binary messages; to force precedence, however, parentheses can be used, as in the two examples before.

There is no operator precedence between messages of the same kind, all messages are evaluated from left to right, but there is a precedence between message kinds. Parenthesized expressions are evaluated first, then come unary messages, followed by binary messages and then keyword messages, which allows you to nest unary messages into keyword message arguments or as a receiver.

Example: MyClass new + t setValue: obj copy not / z forKey: k – k1 * c. I have no idea what that code does, yours to find a signification, though I know how it is evaluated:

• “new” message is sent to “MyClass”
• “+” message is sent to the answer of the “MyClass new” message with “t” as argument
• “copy” message is sent to “obj”
• “not” message is sent to the answer of “obj copy”
• “/” message is to the answer of “obj copy not” with the argument “z”
• “-” message is sent to “k” with the argument “k1″
• “*” message is sent to the answer of “k – k1″ with the argument “c”
• “setValue:forKey:” message is sent to the answer of “MyClass new + t” with the answers of “obj copy not / z” and “k – k1 * c” messages as arguments.

This weird expression shows one particular thing: you can chain as much unary and binary messages as you wish but you cannot chain keyword messages without parentheses. Indeed, if you write: “obj setValue: v forKey: k index: i” the message will be “setValue:forKey:index:”, whereas “(obj setValue: v forKey: k) index: i” the messages will be “setValue:forKey:” and “index:”.
This is a limitation enforced by the nature of the keyword messages: how can you tell this expression “obj setValue: v forKey: k index: i” is the message “index:” sent to the answer of the message “forKey:” sent to the answer of the message “setValue:”, and not the message “index:” sent to the answer of “setValue:forKey:” or the message “setValue:forKey:index:” sent to “obj” ? Well, KISS principle applied, as well as in SmallTalk, keyword messages need to be parenthesized to be chained because a sequence of keywords in an expression will be considered as part of the same message.

With these three kinds of messages, the developer is provided pretty good tools to make an easily readable code: unary and keyword messages can retain their auto-documenting properties that are extensively used in Cocoa, and binary messages gives more flexibility than operator overloading in other languages.

This is yet another object-oriented language, I sincerely think there is not enough languages out there so I wanted to add mine… No seriously, that’s not the reason.

This project started a long time ago in a galaxy far far away (in my head), some time between 1 or 2 years ago. In the beginning, it was just something to have fun as I had fun implementing a Lisp interpreter in ObjC/Cocoa, but then it became more concrete when I thought about its actual goals:

I am a true fan of Objective-C and Cocoa, to me they are the best languages and frameworks out there… You agree or not, that’s not the point, a lot other frameworks and languages have good ideas and are nicely designed, but to me, the one that is the most well-designed is ObjC/Cocoa. But during my wanderings on the internet or outside, I’ve heard a lot of criticisms about ObjC or Cocoa, some would piss me off (features asked by users that would come from C++), some of them were justified (loose typing, too many brackets for example), and I have mine as well (the non-flexible imposed C base). Hence my first goal for this language was to address those criticisms in mine and keep all the nice stuff of ObjC.

So, I started designing something, it was called Objective-Psy (yes I’m Humble) and was kinda just ObjC without the C part that was annoying and some more strict typing… But it mostly kept ObjC existing stuffs, including functions, multiple different base types, .h/.m pairs, @keywords, [bracket messages], etc. Not very fun…

Then came Landon Fuller, founder of Plausible Labs, who has, among other things, ported Blocks to Mac OS X Leopard and iPhone (based on some rudimentary Blocks runtime I made). Landon proposed me to work with him on a new language that would also address some of the problems of ObjC; his biggest concern about it was typing: it is either too loose or too tight, he prefers some strict typing, having the compiler telling him he’s doing it wrong and not the runtime. Fair enough, that’s not something that bothers me much, all I want is keeping ObjC dynamism which is its biggest strength and also the keyword-method syntax (initWithFirstName:lastName:).

So here we start working on designing the language: BambookTalk, with his compile-time typing and functional background and my runtime typing and object-oriented background, we did some good work together that we put in here. We looked back at the roots of ObjC and dug into SmallTalk, the first OO language that was qualified as is. It is a really pure and extremely dynamic language, to the point that you can modify your IDE whilst running it to perform the change… Though the typing is full-runtime, the syntax is very nice, except when defining classes in separate text files for archiving… So then we looked a little at StrongTalk, which is SmallTalk with “strong” compile-time typing and some other languages like Newspeak… We ended up wanting to build a love-child of SmallTalk and ObjC, so we started to put some proposals available in the project’s wiki; but then the project lost some attention due to lack of time mostly.

It was 1 or 2 months ago since I decided to get my hands dirty to work on a compiler to have clearer ideas on how to construct the languages. I think I’ve came up with a pretty nice language so far, some stuff may seem weird because I tried to keep the language as coherent and simple as possible, however the language itself comes up nice, in my humble opinion.

So for now, the language is still a (love-?)child of SmallTalk and ObjC, most of its features come from those two languages, some others are inspired from other languages as well… The language includes namespaces, classes, enums, public/protected/package/private class/instance properties/methods, constructors, garbage-collection, generics, strong compile-time/runtime typing, reflection, parametric/polymorphism overloading, “operators” overloading and a very nice SmallTalkish message syntax. I will expose all of that in future articles.