Generic Programming In Smalltalk

Smalltalk's lack of ParametricPolymorphism has been a long-standing problem. C++ has templates and Ada has generics, but so far no-one has brought Smalltalk up to date.

Note: The original poster misunderstands the basics of Smalltalk. The discussion below may be interesting anyway.

See later: It was intended as an April Fool joke.

Smalltalk is already far more generic than any template system you propose. Smalltalk is almost the very definition of generic programming.

Generic programming is a very powerful technique. In its simplest form, it allows you to make collections that accept arbitrary types. In its more advanced uses, generic programming allows you to compose behaviors without using adapters all over the place. With generics, you can also vary the types of instantiated classes easily.

Smalltalk already allows you to use arbitrary types.

With a little work, we could add generics to Smalltalk. Consider the following BinarySearch code:

binarySearch: anObject over: anInterval 

   anInterval isEmpty ifTrue: [^-1].
   (self at: anInterval center) = anObject ifTrue: [^anInterval center]. 
       ^self
       binarySearch: anObject 
       over: (anObject < (self at: anInterval center)
           ifTrue: [anInterval start to: anInterval leftOfCenter]
           ifFalse: [anInterval rightOfCenter to: anInterval stop])
It works but it is limited. It only works with subclasses of Object. If Smalltalk had a preprocessor, we could make it robust:

How little you seem to understand about Smalltalk. Your entire assertion is silly. You need to study Smalltalk some more, it doesn't work like C++, doesn't have static typing, and doesn't require anything to be a subclass of anything ever. The code above is far more flexible than your proposed solutions below.

@define binarySearchImplementation(anObject,anInterval) { 

   anInterval isEmpty ifTrue: [^-1].
   (self at: anInterval center) = anObject ifTrue: [^anInterval center]. 
       ^self
       binarySearch: anObject 
       over: (anObject < (self at: anInterval center)
           ifTrue: [anInterval start to: anInterval leftOfCenter]
           ifFalse: [anInterval rightOfCenter to: anInterval stop])
}

binarySearch: anObject over: anInterval 

    binarySearchImplementation(anObject,anInterval)
The preprocessor would work well, but it could make the image very messy. Creating a full blown template system would be better:

template binarySearch<class T>: anObject over<class T>: anInterval 

   anInterval isEmpty ifTrue: [^-1].
   (self at: anInterval center) = anObject ifTrue: [^anInterval center]. 
       ^self
       binarySearch<T>: anObject
       over<T>: (anObject < (self at: anInterval center)
           ifTrue: [anInterval start to: anInterval leftOfCenter]
           ifFalse: [anInterval rightOfCenter to: anInterval stop])
Notice that the template syntax is used on each part of the selector. This is redundant, but it is better to force programmers to type a little more at times so that they think about what they are doing.

A good template system for Smalltalk should be pretty easy to create. Anyone want to try to do as an OpenSource project?

Smalltalk doesn't need templates; it is dynamically type-checked. So, anObject does NOT have to be a subclass of Object, it just has to understand = and <. In Smalltalk jargon, this means it needs to be a Magnitude. But note that does NOT mean that it has to be a subclass of Magnitude (and thus of Object), it just has to understand the Magnitude interface.

We all know the problems with dynamic type-checking; it is hard to optimize dynamically type-checked programs and many errors that could be detected at compile-time in other languages must be detected at run-time in a dynamically typed language. However, dynamic type-checking has many advantages, too. In particular, it lets a language be much more expressive than if it had a type system. Every compile-time type system is conservative and has to rule out some programs that would execute correctly in a statically typed language. Dynamic languages like Smalltalk are much more expressive than static languages like C++ or even Java.

So, the problem is NOT making generics for Smalltalk so that it can be more powerful, the problem is how to make a type system for Smalltalk that can give the benefits of static typing without losing the benefits of dynamic typing. So far, nobody has been able to do it.

The real problem is making programmers understand Smalltalk. It's a dynamic runtime system, static typing and templates would be silly...

Yes, you would lose things (ceteris paribus), but that doesn't necessarily make it silly; it depends on why it was done. Plus it might be part of an extension, such as adding a HindleyMilnerTypeInference system, etc., so that one could be a SmugMLweenie without giving up being a SmugSmalltalkWeenie. :-)

... and kill many of Smalltalk's benefits. Not to mention that there is no compile time in Smalltalk.

Since Smalltalk-to-machine-code compilers exist, this is a silly assertion.

Without losing anything, I doubt that, but if you have a link, I'll rethink my assertion.

* Even if I were wrong, the compiler-to-bytecode commonly used is still a "compiler", and that is the standard term for it (see e.g. Smalltalk-80 Goldberg & Robson, or Krasner's Bits of History, Words of Advice, etc). So there's definitely a compile-time.

* Any language at all can be compiled to machine code. The machine code in some cases might not be any more efficient than the interpreted version, but that wasn't the question.

* Here's the first link that popped up on google when I searched for smalltalk and machine code. There are others. http://florenz025.server4free.de:8080/doc/online/english/overview/TOP.html

-- DougMerritt

Yes, there is of course a compile time, but what I meant was in comparison to runtime, as in C. Smalltalk has no "compile time" as in you compile and then run.

It's an artificial distinction. People have done C interpreters which have as little of a compile time as does Smalltalk. Conversely, it would be practically trivial to add Lisp-style semantic macros to Smalltalk, and all of a sudden people would be talking about how macros happen "at compile time" in Smalltalk, where there's no need to distinguish that phase at present. (In Lisp one further distinguishes "read time", but never mind.)

About the only things that have no "compile time" at all are those things that aren't even translated into byte codes. Even regular expression search in editors gets translated into at least an NFA, and usually a DFA, but it's still a compile/translation phase. Very rarely, people have done regular expressions that directly drive the match from the untranslated string representation itself. Now that has no compile time. But it's also usually impractical.

Compilation happens whenever you 'Accept' a change. Generally, only the method that you changed is recompiled. Unless you changed a class definition in which case all sorts of other code gets run, including code to dynamically change any instantiated instances of that class to be an instance of the new definition. -- DarrenHobbs

I hate to be a nitpicker, but I believe that the statement "it only works with subclasses of Object" is inaccurate. It could be easily extended to work with subclasses of nil as well.

And what would a binary sort of nil produce, anyway?

Nothing useful. But subclasses of nil are often very useful for such things as forwarders.

"So far, nobody has been able to do it." - have you tried StrongTalk?

(You know, I'd assumed this page was intended as an AprilFool?. Was I wrong?) -- DaveHarris

Yes, it was an April Fool's day joke. Not a very good one. I should have made it more bizarre, or at least dropped a hint. Not as fun as convincing one of my co-workers that I was about to apply for an open position in marketing.

I'm glad someone mentioned StrongTalk. I've wanted to learn about it for a while.

-- MichaelFeathers

It was good. I got it. -- r

Ah, Michael, so it *was* you? :-) I liked this one very much. -- MarnixKlooster

moved from GenericProgrammingInSmalltalkComment

I'm adding this new page so that I don't have to spoil GenericProgrammingInSmalltalk.

I must say that I admire the choice of syntax. It's terse and it says exactly what you want to say. And I agree that the redundancy is a good thing. If I have some spare time I'll try an implementation.

BTW, I think I have found a pretty simple way to implement the template system, using the concept of TypeErasure. (See the papers on Strongtalk and on GenericJava / PizzaLanguage (the latter at http://www.cs.bell-labs.com/~wadler/pizza/gj in the Documents section).)

-- MarnixKlooster

CategorySmalltalk CategoryJoke

EditText of this page (last edited May 25, 2014) or FindPage with title or text search