goran.hultgren at 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.