Moving Forward Towards The Right Kind of More Less
written by Peter William Lount
version 1, 20050604

Michael Lucas-Smith writes:
I suggest that you read his entire article and the comments that follow.

Michael, awesome work! I encourage you to keep moving your design forward.

In a "keyword" language like Smalltalk, Self, Slate, Zoku, et al. the colon, ":", provides seperation from the keyword and the parameter value. Smalltalk already has the usage of ":=" and ":". Your extenison of the ":=" is an innovative solution using an existing syntax element from Smalltalk.

In the Zoku language evolution one of the key succcess has been to keep the set of syntax characters used small and if possible to the set that Smalltalk currently uses. It's very interesting to note that powerful languages don't need very many characters and syntax elements. LISP, Smalltalk and Forth are but three examples.

APL is a language that took the opposite approach and used lots of special characters. Actually Smalltalk originally had two special characters, the "up arrow" for returning objects from a method and the "left arrow" for assignment into variables. Smalltalk had to adapt due to the harsh reality of the characters available in the ASCII character set. Keyboards and printers were a limiting factor in this adaptation (if I recall, first by Digitalk Smalltalk V), and thus the usage of ":=" in Smalltalk was born. The origin of using ":=" goes back further to Pascal (was it the first?)

Now with the massive UNICODE character sets there is an explosion of special characters to choose from. Yet, fundamentally computer languages only need a handfull of non-alpha-numeric characters. Sure you have domain specific languages such as math and sheet music that require special characters, glyphs, syntax, and layout rules, but that's only because these domain specific languages are really human languages.

How does on integrate UNICODE into the Smalltalk syntax so that variable names, object names etc... are valid without adding any new syntax elements to Smalltalk-80 or ANSI-Smalltalk standards? Hmm...

I had been wondering how the Smalltalk syntax element ":=" might be reused for other purposes and now there is one!

As we know the use of ":" distinguishes a keyword and it's paired parameter. How many others are there? Taking your inspriation Michael and the above analysis into account suggests that ":C" where "C" is another character might enable options on the message sending, but those options should be related to the sender or the message passing algorithm itself and most certainly not the receiver (otherwise the uniform message sending breaks).

As to Michaels proposed specific usage of ":=", there does seem to be a conflict with the unification of variable access and messages that Self brings to the table. Usually "name: 'bob'" would set the slot or be a method that takes a parameter, the sender doesn't care, but now you have two syntaxes, "name: 'bob'", and "name:= 'bob'", that the sender must be aware of; yikes.

Having ":" and ":=" breaks the pure simplicity that comes from the getters and setters using the uniform unary, binary and keyword "message" syntaxes. Ick, because now if you change the "name:" slot from an instance variable to a method you have to rewrite all the senders to use ":" instead of ":=" and thus you've made programming more difficult not simplier. The vice versa is also true. You've broken encapsulation by requiring the senders to "know" the format of the receiver. Your messages are no longer in the same format thus causing a leaking of detailed implementation knowledge from the object.

I would therefore recommend choosing a different approach. There must be a way to have your cake and eat it too (i.e. there must be a way to use "name:" for both instance variable setting and for message sends. Keep looking into how you can resolve the ambiguities that arrise from a uniform ":" syntax during parsing, compiling and runtime. The answers are out there in the solution space.

As Brian Rice points out in a comment (here) the challenge is dis-ambiguating an implicit variable slot declartion/access from an implicit self message send, otherwise how can you determine when to invoke "doesNotUnderstand: aMessage" or to create a slot? Maybe you try the message lookup first, then doesNotUnderstand, then the variable slot creation (or some other yet to be illuminated resolution process)?

Michael, I'm wondering why you feel it's so important to not have to define instance variables? What is the rational behind this?

What do "implicit instance variable definitions" really buy you?

What other way can "name: 'bob'" be used to set a variable slot and also be a message so that the pure uniformity of keyword message sends be preserved?

Keep up your inspirational work!

---

Copyright 1999-2009 by Smalltalk.org™, All Rights Reserved.