Ioke is not a Lisp

I generally get lots of different kinds of reactions from people when showing them Ioke. A very common misconception about the language is that it is “just another dialect of Lisp”. That is a quite easy mistake to make, since I’ve borrowed heavily from the things I like about Lisp. But there are also several things that make Ioke fundamentally different. Ioke is Lisp turned inside out and skewed a bit.

First we have the syntax. Ioke has syntax inspired by Ruby and Self, but includes some variations that come from Common Lisp too. The main difference between how Ruby and Ioke handles syntax is that Ioke will transform everything down to the same message passing idiom. Most of the syntax is in the form of operators, which don’t get any special handling by the parser at all. But the syntax is still there, and it is also deeper embedded compared to how Lisp generally does it. Ioke acknowledges the existence of different kind of literals – and allow you to override and handle them differently if you want. One of the examples in the distribution is a small parser combinator library. It allows you to use regular text and number literals, but in the context of the parser those literals will return new parser for their type.

Common Lisp can play these syntactic games with reader macros, but it is generally not done. Ioke embraces the use of syntax to improve readability and the creation of nice DSLs.

Of course, any Lisp guy will tell you that syntax has been tried – but programmers preferred S-expressions. The latest example of this is Dylan. But I’ll have to admit that if you look at the Dylan syntax, you understand why the programmers didn’t feel like bothering with it. It’s one thing to try syntax by just adding some very clumsy Algol-derivation. It is another thing entirely to actually focus on syntax.

That said, Ioke is homoiconic, and translates to a structure that could easily be represented as cons cells. It doesn’t, though, since the message chain abstraction works better.

The other thing that really makes Ioke different from Lisp – and also a reason that would make infix S-expressions extremely impractical – is that Ioke is fundamentally object oriented based on a message passing idiom. In a lisp, all function calls are evaluated in the context of the current package (in Common Lisp). You can get different behavior if the function you call is in fact a generic method, but in reality you’re still talking about one method. If you want to chain method calls together, you have to turn them inside out. That doesn’t lend itself well to a message passing paradigm where there is an explicit receiver for everything.

Ioke in contrast have the message passing model at its core. Any evaluation in Ioke is message send to some receiver. In that model, you really need to make it easy to chain messages in some way. And that’s why S-expressions would never work well for Ioke. S-expressions fundamentally doesn’t use the concept of a receiver at all.

All the other differences in Ioke versus any Lisp could be chalked down to minor dialectical differences, but the two biggies are the above. Ioke is not a Lisp. It’s heavily inspired by Lisp, but it’s fundamentally different from it.

7 Comments, Comment or Ping

  1. Lisp Panzergrenadier

    Oh, why those dynamic languages people keep reinventing Lisp, calling it “kewl” names, using arbitary-syntax-just-popular-on-slashdot?
    (end-of troll)

    January 26th, 2009

  2. Mr Panzergrenadier: Exactly my point.

    January 26th, 2009

  3. Justin

    Not sure that I would describe Dylan syntax as clumsy!!

    Perhaps a little verbose, but clumsy, no.

    January 26th, 2009

  4. Justin:

    That’s totally up to you. To me it feels very clumsy.

    January 26th, 2009

  5. How do you figure you need to turn generic functions “inside out”? With the standard CLOS method combination, you just define :before or :after methods which in most cases does what you want. If it doesn’t, you’re free to define an :around method (and make sure the next method is properly called).

    Or, you can just write your own method combination, if any of max, +, progn, … don’t fit your needs.

    January 26th, 2009

  6. Mikael:

    Well, I didn’t mean from that perspective (Ioke has aspects that work mostly like generic method combinators from Common Lisp).

    What I mean is that if you have a foo, and a class Bar, and you have an operation quux on Foo, that returns a Bar, and then you want to invoke baz on the Bar returned from the quux message. In Common Lisp that would be invoked as:

    (baz (quux foo))

    while in Ioke it becomes

    foo quux baz

    which is what I meant that you have to turn it inside out.

    January 26th, 2009

  7. The proof of the pudding is in the eating: writing Ioke code doesn’t much feel like writing Lisp code.

    There are a lot of homoiconic languages out there. Lisp was the first but there have been many that followed, many of which look and feel nothing like Lisp. Like all languages, Ioke bears the influence of the languages that came before it, but that doesn’t mean it’s a “reinvention” of anything, any more than Smalltalk was a “reinvention” of Lisp.

    The fact that Lisp is a functional language and Ioke is an prototype-style object-oriented language should be a large enough difference to tip you off.

    January 27th, 2009

Reply to “Ioke is not a Lisp”