Lexical block return: The language crux


I have been thinking about my favorite programming languages: Smalltalk, Common Lisp, and Scheme. These languages have much in common, and share many features, all the way down to syntax extension. I tend to be working in or studying any of these three when I am not pushing PHP for money.

These languages have an amazing pedigree, and many of their features have been ever so slowly moving into the mainstream. So what keeps this little club so exclusive? Is it my affinity for Lisp macrology? Is it the necessarily corresponding dearth of built-in funny characters? Perhaps, but I also realized they shared lexical, non-local block return in common, an interesting feature that others seem to overlook.

All three languages encourage you to define new control structures procedurally, using higher-order functions. This is especially true of Smalltalk where even retrieving array and dictionary elements has useful¹ associated control structures:

anArray at: 42 ifAbsent: [self defaultAt: 42].
anArray at: 42 ifPresent: [:newElt |
    self defaultAt: 42 put: newElt].

Constructors come short

I've been writing several classes in PHP, and recently became so uncomfortable with the inflexibility of the "constructor" method of describing instance creation that I implemented what I had previously thought of as a Smalltalk hack to handle not having access to instance variables outside instance methods. Names changed to protect the …:

class Foo
  static function makeInstances ($args…)
    // code that constructs and calls the initializer here

  function initRawData ($args…)
    // finish munging the data and put it in instvars here

Hello World!

Hello!, I'm a 30yr old programmer from Salem, India. I first encountered Smalltalk in a demo of Visual Age Smalltalk that came with the OS/2 Warp CD. I was simply blown away by the visual programming that was demoed. The first Smalltalk that I actually played with was GNU Smalltalk version 1.1.5 (at that time the interpreter was called mst iirc) that came with Slackware Linux circa 1996. After that I played with other smalltalks including VW, ST/X and Squeak but GST has always remained my favourite mainly because it is both fast and free :) GST performs quite well in the language shootout considering that the collection classes are written in Smalltalk and not in C as is the case with others like Perl, Python and Ruby. Squeak is good too but back then I kinda got lost in the squeak world :). GST otoh, being file based, was easier for somebody from the C/C++ land.

I've been a silent lurker on the GST mailing list for many years now and it is nice to see the project picking up momemtum. Also good to see is the focus shift towards a scripting environment. Unlike the past, learning smalltalk is not a problem nowadays thanks to the number of excellent books freely available. I once again plan to study smalltalk "properly" and hopefully contribute to the development. Here, I intend to post my progress and also talk/ramble/rant/suggest ideas for future development.

A peek into Smalltalk

Hello to all those that have stumbled upon this entry!

 My name is Pete (hard to guess by my username, eh?) and I am a 
Computer Science student at Florida State University in the 
United States. The reason I find myself peeking into the 
smalltalk universe is the result of a project for my programming 
languages course.

 I intend to get my hands nice and dirty with Smalltalk, write a 
few programs, and try to convey an enthusiasm for this long 
living system.


Presource design and overriding the Smalltalk parser

Tagged:  •  

Paolo writes that he's looking to remove the capability to override the parser for a Behavior's methods from strings passed to #compile:, as well as old-syntax method definition lists, by moving #parserClass to CompiledMethod. He mentions that Presource fares quite well with this restriction, providing full message macros just by overriding the compiler.

Syndicate content

User login