4 ms·

I should have mentioned a few other things for the later Smalltalks. First, selectors are just objects. Second, you could use the automatic "message not underst

I should have mentioned a few other things for the later Smalltalks. First, selectors are just objects. Second, you could use the automatic "message not understood" mechanism to field an unrecognized object. I think I'd do this by adding a method called "any" and letting it take care of arbitrary unknown objects ...

shalabhc 9y ago
> adding a method called "any" Right, I understand there are ways to do this with methods but my question was more about the purity aspect, which you already addressed above.
- alankay1 9y ago
  A selector is an object -- so that is pure -- and its use is a convention of the messaging, and the message itself is one object, that is an instance of Class message. What's fun is that every Smalltalk contained the tools to make their successors while still running themselves. In other words, we can modify pretty much anything in Smalltalk on the fly if we choose to dip into the "meta" parts of it, which are also running. In Smalltalk-72, a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc. This is quite possible to make happen in the more modern Smalltalks, and would even be an interesting exercise for deep Smalltalkers.
  - shalabhc 9y ago
    > A selector is an object -- so that is pure -- and its use is a convention of the messaging The selector 'convention' is hard coded in the syntax - this appears to elevate selector based messaging over other kinds. But now I'm rethinking this differently - i.e. selectors isn't part of the essence, but a specific choice that could be replaced (if we find something better.)
    - alankay1 9y ago
      It's an extensible language with a meta system so you can make each and every level of it do what you want. And, as I mentioned, the first version of Smalltalk (-72) did not have a convention to use a selector. The later Smalltalks wound up with the convention because using "keywords" to make the messages more readable for humans was used a lot in Smalltalk-72.
    - mmiller 9y ago
      I can't remember if I've brought this up already in this thread, but if you want to "kick the tires" on ST-72, Dan Ingalls has an implementation of it up on the web. It's running off of a real ST-72 image. I wrote about it at https://tekkie.wordpress.com/2014/02/19/encountering-smalltalk-72-on-the-web/ https://tekkie.wordpress.com/2014/02/19/encountering-smallta... I include a link to it, and described how you can use it (to the best of my knowledge), though my description was only current to the time that I wrote it. Looking at it again, Ingalls has obviously updated the emulation. The nice thing about this version is it includes the original tutorial documentation, written by Kay and Adele Goldberg, so you can download that, and learn how to use it. I found that I couldn't do everything described in the documentation. Some parts of the implementation seemed broken, particularly the class editor, which was unfortunate, and some attempts to use code that detected events from the mouse didn't work. However, you can write classes from the command line (ST-72 was largely a command-line environment, on a graphical display, so it was possible to draw graphics). If you take a look at it, you will see a strong resemblance to Lisp, if you're familiar with that, in terms of the concepts and conventions they were using. As Kay said in "The Early History of Smalltalk," he was trying to improve on Lisp's use of special forms. I found through using it that his notion of classes, from a Lisp perspective, existed in a nether world between functions and macros. A class could look just like a Lisp function, but if you add parsing behavior, it starts behaving more like a macro, parsing through its arguments, and generating new code to be executed by other classes. The idea of selectors is still kind of there, informally. It's just that it takes a form that's more like a COND construct in Lisp. So, rather than each selector having its own scope, as in later versions, all of them exist in an environment that exists in the scope of the class/instance. After using it for a while, I could see why they went to a selector model of message receipt, because the iconic language used in ST-72 allowed you to express a lot in a very small space, but I found that you could make the logic so complex it was hard to keep track of what was going on, especially when it got recursive.

shalabhc 9y ago

> adding a method called "any" Right, I understand there are ways to do this with methods but my question was more about the purity aspect, which you already addressed above.

alankay1 9y ago
A selector is an object -- so that is pure -- and its use is a convention of the messaging, and the message itself is one object, that is an instance of Class message. What's fun is that every Smalltalk contained the tools to make their successors while still running themselves. In other words, we can modify pretty much anything in Smalltalk on the fly if we choose to dip into the "meta" parts of it, which are also running. In Smalltalk-72, a message send was just a "notify" to the receiver that there was a message, plus a reference to the whole message. The receiver did the actual work of looking at it, interpreting it, etc. This is quite possible to make happen in the more modern Smalltalks, and would even be an interesting exercise for deep Smalltalkers.
- shalabhc 9y ago
  > A selector is an object -- so that is pure -- and its use is a convention of the messaging The selector 'convention' is hard coded in the syntax - this appears to elevate selector based messaging over other kinds. But now I'm rethinking this differently - i.e. selectors isn't part of the essence, but a specific choice that could be replaced (if we find something better.)
  - alankay1 9y ago
    It's an extensible language with a meta system so you can make each and every level of it do what you want. And, as I mentioned, the first version of Smalltalk (-72) did not have a convention to use a selector. The later Smalltalks wound up with the convention because using "keywords" to make the messages more readable for humans was used a lot in Smalltalk-72.
  - mmiller 9y ago
    I can't remember if I've brought this up already in this thread, but if you want to "kick the tires" on ST-72, Dan Ingalls has an implementation of it up on the web. It's running off of a real ST-72 image. I wrote about it at https://tekkie.wordpress.com/2014/02/19/encountering-smalltalk-72-on-the-web/ https://tekkie.wordpress.com/2014/02/19/encountering-smallta... I include a link to it, and described how you can use it (to the best of my knowledge), though my description was only current to the time that I wrote it. Looking at it again, Ingalls has obviously updated the emulation. The nice thing about this version is it includes the original tutorial documentation, written by Kay and Adele Goldberg, so you can download that, and learn how to use it. I found that I couldn't do everything described in the documentation. Some parts of the implementation seemed broken, particularly the class editor, which was unfortunate, and some attempts to use code that detected events from the mouse didn't work. However, you can write classes from the command line (ST-72 was largely a command-line environment, on a graphical display, so it was possible to draw graphics). If you take a look at it, you will see a strong resemblance to Lisp, if you're familiar with that, in terms of the concepts and conventions they were using. As Kay said in "The Early History of Smalltalk," he was trying to improve on Lisp's use of special forms. I found through using it that his notion of classes, from a Lisp perspective, existed in a nether world between functions and macros. A class could look just like a Lisp function, but if you add parsing behavior, it starts behaving more like a macro, parsing through its arguments, and generating new code to be executed by other classes. The idea of selectors is still kind of there, informally. It's just that it takes a form that's more like a COND construct in Lisp. So, rather than each selector having its own scope, as in later versions, all of them exist in an environment that exists in the scope of the class/instance. After using it for a while, I could see why they went to a selector model of message receipt, because the iconic language used in ST-72 allowed you to express a lot in a very small space, but I found that you could make the logic so complex it was hard to keep track of what was going on, especially when it got recursive.