[ANSI-Smalltalk] squeakers

[Peter van Rooijen]

Good post Jecel!

In my mind whether a standard may represents a danger to some Smalltalker  
(or Squeaker) also depends very much on what it states. The current ANSI  
standard is very liberal. It requires very few things, mostly only a  
handful of globals to be defined.

So it leaves a very great amount of freedom to the individual language  
implementer. But I wonder, how many people actually know this? It may not  
be immediately obvious from a cursory look at the standard that this is  
the case.

Some more thoughts:

1) ANSI-ST requires a number of protocols to be implemented but for most  
of them how the implementation (i.e. the object or an object that  
implements the protocol) can be reached (conventionally through a global  
but may be via a message too) is up to the implementer. This basically  
means that an implementer who claims that his implementation is (to some  
extenty) ANSI-ST compatible, must specify under which names or message  
expressions each implemented protocol is reachable. I have never seen such  
a specification (Dolphin Smalltalk contained a browser that came pretty  
close). Has any implementer ever seriously tried to  
ascertain/assess/verify/test a degree of compatibility with ASNI-ST?

2) Because ANSI-ST message specifications are circular in nature,  
compatibility with message specifications can only be tested to some N-th  
degree. Any thoughts on how this should feed into what a test  
suite/assessment program contains/does?

3) Maybe the standard we want should not (primarily) have the  
(declarative) form of the ANSI-ST standard, but we should just have a  
test-suite/program, evolve and fix that, and let that be the standard. The  
tests will still be commented with semantic/declarative comments of  
course, explaining what the intention/idea is behind the tests, but the  
tests are the leader. A test without a comment can still be useful. In  
ANSI-ST we have comments without tests, and how useful are they?

What advantages and disadvantages would it have to build such an  
executable standard?

Hope these thoughts are of use to anyone, regards, Peter


On Thu, 17 Jan 2008 22:11:08 +0100, Jecel Assumpcao Jr  
<jecel at merlintec.com> wrote:

> I see that possible concerns of the Squeak community about the standards
> process were discussed on this list long before I joined, but if you
> don't mind I would like to address this issue. A good start would be to
> divide that community into three groups:
>
> 1) eToys (and Scratch) users
>
> This is the silent, but vast majority. The are mostly children and their
> teachers and build their applications using a tile based visual language
> representation. They are mostly (or completely, in the case of Scratch)
> isolated from the underlying Smalltalk layer so if a comparable
> environment were to be created on top of Python or Javascript instead
> they would probably be just as happy. So obviously they don't care at
> all about Smalltalk standardization efforts. And we, on the other hand,
> don't have to care about them even though their numbers are growing at
> an increasing rate due to OLPC and similar projects.
>
> 2) free Smalltalk-80 camp
>
> Where "free" just means no cost to some while others insist on open
> source. Many in this group also use other Smalltalks and find Squeak's
> differences to be a problem. Some are bothered by the Morphic user
> interface and would prefer native widgets, MVC or even nothing at all in
> the case of embedded or web applications.
>
> You would think that this group would push hard for compatibility with
> the ANSI standard and there is some effort in this direction, but not
> nearly as much as there should be. I can't think of what could be done
> to increase awareness about the importance of the standards project
> among these people that hasn't been done already.
>
> 3) the "inventing the future" guys
>
> In his first OOPSLA keynote, Alan Kay said they had not created Squeak
> to give people a free Smalltalk, but rather a tool with which to build a
> far better replacement for it. Some such projects end up starting over
> while using some stuff from Squeak (Fonc/Cola, Slate, my own Neo
> Smalltalk...) while others grow Squeak itself in new directions (Spoon,
> Traits, Morphic, the extensions for Tweak and Croquet...).
>
> It is this third group that worries about standardization being a
> barrier to innovation. They feel that making Squeak compatible with ANSI
> and/or other Smalltalks would hold it back. In some cases it might be a
> matter of laziness - adding stuff to Squeak that other Smalltalks
> already have without the least effort to see how they did it, which
> introduces needless incompatibility. In other cases there seem to be
> technical advantages of doing it differently.
>
> My impression is that many of these worries are not based on fact. The
> current ANSI standard allows a lot of flexibility by defining most
> things in terms of "protocols". So not only would being ANSI compatible
> not keep Squeak from adding Traits, but adding these would actually make
> it *easier* to conform to the standard. Even a version of Smalltalk that
> doesn't implement classes can be fully compatible as long as a few key
> global objects implement the "Factory" protocol somehow.
>
> So as long as similar care is taken in upcoming versions of the
> standard, I feel that the need of this third group will have been
> properly addressed. It is important that they know this, of course. Once
> this effort picks up steam it will be important for any Squeakers here
> (including me) to tell groups 2 and 3 about it.
>
> -- Jecel
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>



-- 
Peter van Rooijen
Esstede 19
1112 EP Diemen
m: 06-2854 2048