goran.hultgren@bluefish.se wrote: I agree in full with everything you wrote (including the rest) but what is your thought on compatibility?

If Squeakers turn to rely on this code working then the code they write will potentially not port to other Smalltalks. We could argue that depending on how other Smalltalks do it is a weak argument that will make any improvement in these areas impossible. I think this is time for a new thread. Goran has raised a general issue of some importance.

If I personally didn't care about compatibility, I wouldn't have bothered downloading the standard. (I was going to ask our office to get the electronic copy of the final, having found out how to do so and for how much, but with too many of our office staff sick/on leave, I'm not going to bother the one that's left. When things are back to normal.)

I _like_ language standards. I write to them whenever I possibly can. (Except Prolog and APL. I regard the ISO Prolog standard as too little and way too late and too incompatible with prior art. And I can't read the APL2 standard.)

There's one fairly basic problem with the ANSI Smalltalk standard. Well, two. If there are any students enrolled in SENG 405 (Formal Methods) next year, I am going to use the #removeAll: debate as a _perfect_ example of why specifications written in plain English can lead to misunderstandings, so that even the attempt at formalisation can help you debug a specification even if you end up never using the formal version for anything.

But the other one is that it's very much a minimal standard. There is no SequenceableCollection>>isSorted in ANSI Smalltalk. There is no PluggableSet in ANSI Smalltalk; not even IdentitySet. There is no Object>>storeOn: in ANSI Smalltalk. There is no MappedCollection in ANSI Smalltalk. There is no CharacterSet in ANSI Smalltalk. There is no indexOf:startingAt: in ANSI Smalltalk. There are no operations on directories in ANSI Smalltalk. Heck, there isn't even any Point class in ANSI Smalltalk.

There's even a Smalltalk dialect where there is no OrderedCollection, and none needed because Array and String instances can change size. Anyone here seriously proposing to stop using OrderedCollection?

But just knowing what the standard says is not enough. You have to know which of those operations are _actually_ portable. (Richard Harmon put a lot of work into his ANSI-Squeak kit. Many thanks to him! Why isn't this stuff already all in Squeak 3.2?)

This is just like when I was working in California, it wasn't enough for me to have the POSIX.1 standard and the C standard, I _still_ had to check things on as many different UNIX systems as I could, because they didn't all conform, even when they intended to. (And I also needed to do things that weren't in the standard, and needed to know how portable they were.)

What would be a great aid to people trying to write portabile code in Squeak would be a 'portability colouring' browser. (In 3.2, this would be just another source display mode.)

We'd start off with a data base of which methods were defined in ANSI Smalltalk. Some heros with access to VW, VA, Dolphin, &c would add notes on what was in their systems and not likely to change. Some Squeak hero would add similar things for Squeak. Add in GNU ...

When you were in the browser, the colour would tell you - this is an ANSI method (or classname) - this is an ST-80 method (or classname) not in ANSI but commonly supported - this is in several modern systems but not all - this is probably unique to your system - this is one of yours (known from change sets) This would only be approximate. Just as we currently have 'explain', there'd be a 'portability' menu item. Select a span of text that identifies a method, and 'portability' would give you a List showing which classes the method was available in, according to the various manuals. Select a class name, and 'portability' would give you a List showing which systems/specifications were known to support it.

In the absence of such a code view, it is very hard for people to actually know that they are writing portable code. In fact, we never know whether the code we are writing will port to the next version of Squeak, and quite often it doesn't, not without rewriting.

By the way, a huge great smiley-faced THANK YOU to all the Camp Smalltalk people who try to make some really useful stuff available in several Smalltalks. That's a huge help to people trying to write portable code.