[ANSI-Smalltalk] Next up

[Eliot Miranda]

On 10/18/07, Bruce Badger <bwbadger at gmail.com> wrote:
>
> The next thing we need to do is get the project proposal in so we can
> establish the committee under the auspices of INCITS.  I've sent in a
> few questions to INCITS for example asking about how many people are
> needed to sponsor the project.  Once I have the basics sorted out I'll
> post a draft of the proposal here so we'll have something concrete to
> discuss.
>
> In the meantime we can get cracking, I reckon.
>
> One think I would like to propose is that we embark on this on the
> basis that this will be an on-going process delivering a version of
> the standard every 18 months or two years.  I think we should time-box
> each version and simply leave out things that miss the deadline rather
> than hold up a version because of some thing we can get to an agreed
> position on.


Agreed; see below.

Then I think we can start talking about priorities.  What should we be
> tackling and in what order?  My suggestion here is that we take Sport
> as a guide since that exists to paper over cracks - and we should aim
> to seal up the most obvious cracks first.  Specifically I'd suggest
> Association, Sockets and Files as being at the top of the list.


I think the priority must be to start at the beginning, and that means
discussing the meta-structure of teh standard before we decide what is
standardised.  As I said in c.l.s. recently I think that a language like
Smalltalk needs to have a modular, exstensible and versioned standard where
the core language is broken down into modules (math, collections, streams,
exceptions, dialect divination, et al) and standardised.  Around this are a
set of optional modules that may or may not be provided by implementations
depending on their complexity (full implementations, implementations aimed
at embedded deployment, etc), comprising functionality such as reflection,
dynamic code modification, debugging, etc.  These are standardised but
optional so that if an implementation chooses to provide optional behaviour
it must do so in accordance with the standard to be conformant.  This avoids
the major flaw of x3j20 of only standardising a small part of Smalltalk as
we know it so as to include all implementations.   Because x3j20 only
specified a common core it wasn't able to standardise reflective APIs for
compilation etc and hence (IMO) badly missed, standardising something well
short of a typical (and useful) Smalltalk.

If we rush off standardising rather than considering the structure of the
standard I think we'll be in danger of repeating x3j20's mistake and specify
only the core library rather than what people commonly understand by
Smalltalk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20071018/e080423b/attachment.html