Eero, an Objective-C Dialect

Hi,

Eero is a fully binary-compatible variant of Objective-C 2.0. It features a streamlined syntax, in some ways bringing Objective-C back to its Smalltalk roots, but mostly just striving to improve readability and reduce code clutter. It also uses the Python indentation scheme, removing most of the curly braces from the language.

There are also features not found in Objective-C, such as limited forms of operator overloading and namespaces. These were done in ways that stay backward compatible with other Objective-C code and frameworks, however. For example, namespaces are implemented as an extension of typedefs and type name prefixes.

Eero is implemented with a patched version of the Clang/LLVM compiler (Release 2.8). It is being developed on OS X, but is intended to work on any platform that Clang supports.

It is currently in the pre-alpha stage. If it sounds interesting to you, please check it out at eerolanguage.org. To go directly to a point-by-point description of how it differs from Objective-C, please go here.

Thanks

Nu

Very nice.

There are several other languages built on Objective-C. For example, Nu (http://programming.nu) is a Lisp built on Objective-C.

By Jason Grossman at Fri, 2011-02-25 03:48 | login or register to post comments

MacRuby

Thanks! Yes definitely, and one of them is MacRuby, which I find very interesting.

By andyarvanitis at Fri, 2011-02-25 16:41 | login or register to post comments

Syntax only

From the description you gave it was apparent that most changes were of syntactic nature, but reading the more detailed description it appears that all changes are purely syntactic, with not a lot of semantic meat for the programming language tinkerer.

In particular, I was disappointed to see what you mean by "namespace". You can specify that "Foo" is a namespace and, if the name resolution for the class "Bar" fails, the compiler will automatically check for the "FooBar" class instead.
It can be seen as a clever hack to remove a bit of repetition in the NSBlah class family, but the semantic itself is quite poor; it's modularity in the C tradition, by adding a hopefully unique string prefix to all names.

One problem with syntactic changes, I think, is that they tend to be quite subjective. Some of the changes in Eero are convincingly motivated, such as for example the PythonÂ¹-like meaningful indentation. But other are much more subjective, such as adding "and" and "or" while deprecating "&&" and "||".

Finally, a good number of them add additional ambiguities to the syntax: the general approach is to remove all kinds of delimiters, and a lot of different things come to be written in the same way. In my experience, this kind of ambiguities is in particular very difficult for beginners to cope with. There are also parts that, while not directly ambiguous, will make a great target for confusion. Consider for example the difference between NSArray arrayWithObjects: date, value, string, nil and myObject setOrigin 0.0, 0.0, 0.0.

Besides, I'm a bit uncomfortable with the rationale for some of the syntactic changes: "we move from this symbol to this one because it's easier to type on a qwerty keyboard". I agree that the small details matter, but I'm a bit uncomfortable with the idea that a language is specifically optimized for a specific keyboard layout, at the potential detriment of other.

Â¹: the document I'm reading about Eero asks if compiled languages have ever used meaningful indentation. Yes indeed; actually meaningful indentation is said to appear first in Peter Landin's "The Next 700 Programming Languages" (1966) and has been notably adopted by Miranda, then Haskell and F#. See the wikipedia article "Offside Rule".

By gasche at Fri, 2011-02-25 08:54 | login or register to post comments

Syntax

Thanks for the good comments. It is true, aside from syntactic changes, I have essentially not strayed far from Objective-C. I'm not sure I will at this point, but the temptation will likely arise as my current goals are all met.

As for Eero's "namespaces," I couldn't agree more with you. Objective-C's approach -- which is, as you say, in the C tradition -- is what I had to "deal with." I considered taking a more serious approach to namespaces, but decided that there was just too much to lose by invalidating the original forms of "NSFoo" (requiring something like "NS::Foo"). The alternative would be to do a proper namespace implementation, but then exclude its use with all the existing prefixed names out there (NS, AB, CA, etc.), and I didn't like that idea either.

And thanks for the reference/link to the Offside Rule. I'll add it to my document.

By andyarvanitis at Fri, 2011-02-25 16:59 | login or register to post comments

A few other points

Haskell and related languages also have layout rules similar to Eero's.

Returning void rather than id by default discourages method chaining, which is an important feature of Objective-C (and Smalltalk). If you want Java, you know where to find it.

Is the language named after Eero Saarinen, Eero Aarnio, Eero HyvÃ¶nen, or perhaps someone else?

By johnwcowan at Fri, 2011-02-25 21:38 | login or register to post comments

Returning void rather than

Returning void rather than id by default discourages method chaining, which is an important feature of Objective-C (and Smalltalk). If you want Java, you know where to find it.

I agree. I also prefer the solution where I can just wrap a return value in an ignore value function.

However, what I think is an abomination is discouraging method chaining while not providing an event processing alternative. In other words, method chaining, especially in OO languages, can be abused and result in code that has a lot of sequential coupling. If as a language designer you don't like method chaining, then the only sensible reason why (to me) is that you want to encourage event-driven code and message passing.

By Z-Bo at Fri, 2011-02-25 21:55 | login or register to post comments

the only sensible reason

...or because you have a language in which setting up delegation doesn't suck, so you aren't encouraged to break the Rather Strong Suggestion of Demeter? e.g. Seems like Go encourages respecting Demeter with the "anonymous field" thingamagiggery.

and there's probably a distinction to be made between method chaining of methods on the same type (cf. builder pattern) vs. method chaining where you are working your way through some object relationship graph of different types along the way. the former is less evil than the latter, i'd hazard.

(delegation could get into combinatorial explosion; depends on the relationship structure of whatever one is coding up.)

By raould at Sat, 2011-02-26 00:55 | login or register to post comments

Rather Strong Suggestion?

Sounds interesting, but I'm a bit lost by the reference. What's this "Rather Strong Suggestion"?

By David Teller at Mon, 2011-02-28 12:10 | login or register to post comments

The Law of Demeter

The Law of Demeter is its usual name. It's a suggested means of reducing coupling between objects.

By Michael Borek at Mon, 2011-02-28 14:27 | login or register to post comments

Thanks

By David Teller at Sat, 2011-05-21 20:33 | login or register to post comments

Return type

The intent wasn't to discourage (or encourage) method chaining, but rather to have an explicit notation instead of an implicit one.

Objective-C, being a hybrid language, leaves things a bit ambiguous here, in my opinion. The return type defaults to id, but an explicit return is required. Furthermore, the standard libraries (Cocoa) clearly and frequently use a multitude of return types other than id, including BOOL, primitive C types, structs, and void.

I feel Smalltalk has a clearer intent, as the return type is (of course) an object, and methods all return self by default if no explicit return statement appears. Eero could have gone either way (perhaps something to think about).

It's named after Eero Saarinen (see the about section).

By andyarvanitis at Sat, 2011-02-26 18:08 | login or register to post comments

Lambda the Ultimate

User login

Navigation