[ANSI-Smalltalk] Next up

[James Foster]

I'd like to second Eliot's comments that we need to discuss goals. One 
of the characteristics of the present standard is the "spartan" nature. 
Personally, I like that. My impression is that leaving out Association 
was not an oversight, but a considered decision to support a minimal 
implementation (say, subject to extreme size constraints).

Actually, I'd start with an errata to identify clear errors and typos.

James

Eliot Miranda wrote:
>
>
> On 10/18/07, *Bruce Badger* <bwbadger at gmail.com 
> <mailto: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.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20071018/11c793ba/attachment.htm