Smalltalk.org™| main

Articles in the Extending Smalltalk series:

The F-Script Smalltalk Extensions
posted by Peter William Lount
version 1, 20040920 12:30pm PDT
revision 2, 20040920 6:37pm PDT, Updated conclusion, Added James Robertson code example and followup link.

There is a discussion here about adopting some of the extensions that F-Script makes to the Smalltalk syntax.

"In Smalltalk we deal with one object at a time. With the F-Script extensions, we can deal directly with whole lists of objects. I think this goes beyond the question of providing an alternative syntax to do collect:. Yes, it provides an alternative syntax to collect: (by removing the need for it), but the important point is that it does so with a model that allows us to think directly in terms of whole sets of objects, whereas collect: requires us to think in terms of "one object at a time" (OOAAT).

At least in my personal experience, it changes (for the better) the way I think when I program. My mind is freed from the OOAAT details, and can be fully applied to reasoning with higher-level abstractions (i.e., whole collections of objects). For me the experience is somewhat similar to that of going from a system with manual memory management to a system with an automatic garbage collector: I can concentrate on more interesting things. It can take some time to free our mind from its OOAAT reflex because, when starting to apply array programming, we tend to constantly mentally translate the array programming model to the more traditional model we were trained to use. When you start to think directly in terms of array programming, you get the benefits of this approach."
- Philippe Mougin

One of the benefits is that the F-Script approach eliminates the need for "loops"! This would potentialy reduce the need for writing loops and iteration blocks.

The [pdf] paper describing this model: OOPAL: Integrating Array Programming in Object-Oriented Programming .

You can also read section 20 in the F-Script guide [pdf], which compares the Smalltalk collection protocol with the F-Script array programming model.

Some of the extensions that F-Script implements should be trivial to implement in any Smalltalk since they rely on the interception of the "doesNotUnderstand" message to collections.

In the article An Example of Scripting Cocoa with F-Script we see the following:

dateStringsOut := dates descriptionWithCalendarFormat:'%a %b %e %Y %I:%M:%S %p' ...

Another interesting thing happens here. dates is an array, but we're sending a message to it (descriptionWithCalendarFormat:) that it doesn't understand. What happens here is that F-Script steps in again and sends the message to each array element, again collecting the output for us and returning a new array."

Well this can be implemented in just about all Smalltalk versions by implementing a version of #doesNotUnderstand: in the Collection class. The method would intercept any messages that were not understood by the receiving collection sub class instance which would then send the original message along to all the objects in the collection collecting up the answers in a new result collection.

We would need to deal with errors from does not understand messages coming from the instances. This implementation approach is limited in that any messages that the collection understands won't be passed on to it's instances but will be executed by the collection. Actually this can be a benefit as you can implement special methods on the collection classes to process your requests in a custom fassion as you might need.

Here is a version written on the Collection class for VisualWorks by James Robertson:

doesNotUnderstand: aMessage
   | selector |
   selector := aMessage selector.
   ^[self collect: [:each | each perform: selector]]
      on: MessageNotUnderstood
      do: [:ex | self]

Please see the basic F-Script examples that compare F-Script with Smalltalk.

In The Squeak Curly Bracket Extension to Smalltalk I wrote:

In general I support extensions to the Smalltalk Language that make sense, that keep the syntax clean, that have - and this is important - multiple overlapping purposes and benefits that provide new capabilities that wouldn't be possible otherwise. If it's just to have a second way to do things then it's generally not needed unless there is some other compelling benefit. For example, Squeak extends Smalltalk to create a short cut for filling Arrays with object instances. It uses "curly braces" surrounding standard Smalltalk expression statements and by doing so it reduces the amount of "verbage" significantly. It's nice in some cases.

For example this:

aList := {
   100.
   250 * 10.
   'peter'.
   aSpot := Point x: 10 y: 20
} asOrderedCollection.

rather than:

aList := (OrderedCollection new)
   add: 100;
   add: 250 * 10;
   add: 'peter';
   add: (aSpot := Point x: 10 y: 20);
   yourself.

In my view the F-Script extensions are worth a deeper look by all the Smalltalk versions providers. I think we need to dig deep into what the F-Script folks have done and understand how to add their extensions to Smalltalk, hopefully without modifying the syntax or virtual machines. In this case it looks like the F-Script examples given by Philippe Mougin and others can simply be implemented in Smalltalk class library. Are there any capabilities in F-Script that can't be implemented in Smalltalk that way?

James Robertson has a nice follow up to this article.

Articles in the Extending Smalltalk series: