[ANSI-Smalltalk] Code as standard - Standardizing the base-library first

[Bruce Badger]

On 26/01/2008, Panu Logic <panulogic at gmail.com> wrote:
> Is the spec about standardizing Smalltalk the language
> or is it about standardizing  a standard library, or both?

Both.  But the process will be time-boxed with the aim of having a new
version of the standard released every 18 months to two years.  This
means that slow things won't hold up the things we can do quickly.  It
also means that things that need more time can have more time.

> Another reasonable characteristic of a successful standard:
> it should be easy to implement ...
> existing major Smalltalk  environment, by creating
> a standard-compliant base-library

I think this would be good to have, but more important IMO is that the
standard defines a language that is easy for programmers to use.  In
other words, I think we should give usability priority to the users
over the vendors.  Having said that I'm sure that implementing the
standard will have largely happened in every existing dialect *before*
the standard is released, so any implementation problems will get
plenty of air-time as the standard is being worked upon.

> Therefore I think it would be wise to attack the standardization
> of (only the) base-libraries as the first step. This would leave
> out things like  the syntax of name-spaces for instance.

You are free to contribute your time as you see fit :-)  I don't think
we should forbid people from working on things that interest them,
though.  For example, my main interest at the moment is in the area of
Files and Sockets - would that be in a "base-library" or just one of
many libraries?

There will no doubt be a dependency tree with the language syntax
(which I hope does not change) at it's root, but who is to say which
parts beyond that are "base" and which are not?

> If we are trying to specify a standard for a set of class-libraries
> (only), then this should be possible to do with a set of tests,
> or pre- and post-conditions for a set of methods.

My view on this is that we should have both a specification and a set
of tests for everything in the standard. The spec and the tests will
reinforce each other.

> Such a parallel "specification hierarchy"  would also make it easy
> to "read the standard" by browsing code - making it much easier
> to grasp than reading a sequential PDF -document could.

Before we have an implementation we have the specification.  There is
no code for the implementer to look at yet.  I would agree that an
implementation of the standard should be clear enough others to read
and understand, but unless the implementer has a time machine they
can't see the implementation until they write it, and when they write
it they need a spec and the spec is the standard.

Your naming ideas are similar to what we have in mind for Sport such
that many versions of Sport can exist in one image at a time.  I had
hoped for something neater in the standard (i.e. no prefixes) but I
suspect that trying that will lead someone to say "name space" or
something like it.

All the best,
    Bruce
-- 
Make the most of your skills - with OpenSkills
http://www.openskills.org/