Re: Syntax of SmallTalk

Lex Spoon <>
19 Jan 2005 22:12:31 -0500

          From comp.compilers

Related articles
Syntax of SmallTalk (Klaas-Jan Stol) (2004-12-23)
Re: Syntax of SmallTalk (Tim Olson) (2004-12-25)
Re: Syntax of SmallTalk (2004-12-25)
Re: Syntax of SmallTalk (Peter Ilberg) (2004-12-25)
Re: Syntax of SmallTalk (Nick Roberts) (2004-12-25)
Re: Syntax of SmallTalk (2004-12-25)
Re: Syntax of SmallTalk (Lex Spoon) (2005-01-19)
| List of all articles for this month |

From: Lex Spoon <>
Newsgroups: comp.compilers
Date: 19 Jan 2005 22:12:31 -0500
Organization: Georgia Institute of Technology
References: 04-12-110 04-12-120
Keywords: smalltalk, parse
Posted-Date: 19 Jan 2005 22:12:31 EST

Tim Olson <> writes:
> [I think it's like Lisp in that the basic language is so low level that
> it's easy to parse, but you can't tell much about the program after
> you've done so. For usful analysis you need to know what a lot of the
> standard operators do. -John]

Yes, but since Smalltalk has no macros, it simplifies things compared
to Lisp. If you see something that looks like a message send, then it
is actually a message send. It's not something that will macro expand
at runtime into something completely different. (This simplifies the
code browsers, too; if you ask for all code that might invoke a
specified method, you can actually find them; there aren't hidden
senders lurking in the middle of pre-expanded macro code.)

On the other hand, control operators (if-then, while, throw-catch,
...) are all in the library, as are numeric operators. In theory, 3+4
might not invoke the addition operation, if the programmer has
redefined +.

Many compiler-writers simply assume that this won't happen for the
basic operations. They assume if they see a +, then it means "add".
On the other hand, if you use a dynamic translation approach like in
Self, it appears that you can leave the programmer the option to
redefine even very basic things, while still getting reasonably high
performance out of the compiler.

Overall, it's important to keep in mind Smalltalk's design strategy,
if you want to work with it. It's lead guy Alan Kay has attempted to
"late bind" as much as possible. He wants to leave as many things as
possible open to experimentation, because he never intended for
Smalltalk to be a done deal. His team completely rewrote the langugae
4-5 times throughout the 70's.... I'd guess this is a major reason
the core language is so tiny and so many things are in the library.

Nowadays, a lot of people use derivatives of Smalltalk-80 as a regular
industrial programming language; however, there are many researchers
around who very much want to keep around the extreme flexibility. As
a compiler writer, you should think carefully about which audience you
are targetting. The software developers don't care if you early bind
what + means, but the researchers would like to keep the possibility
of changing it around. To give you one idea, in Squeak, people have
implemented both continuations and exceptions without changing the
compiler; this was only possible because Squeak's compiler (and
bytecode interpreter) is a traditional late-binding one that doesn't
make many assumptions. On the other hand, Squeak's
compiler+interpreter runs code slower than that of Cincom VisualWorks.


Check out the article in History of Programming Languages for more
info. Here's an HTML version of it:

Or, grab it the PDF through the ACM portal if you have access:

Here's some info on the Self compiler:

(blatant plug) Here's a project that includes a Smalltalk parser plus
some infrastructure to help with program analysis:

But there is a ton of such stuff around.... As mentioned earlier, you
should really ask on the Squeak mailing list or on one of the
Smalltalk newsgroups if you have a more specific requirement.

    -Lex Spoon

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.