<br><br><div><span class="gmail_quote">On 10/18/07, <b class="gmail_sendername">Bruce Badger</b> <<a href="mailto:bwbadger@gmail.com">bwbadger@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
The next thing we need to do is get the project proposal in so we can<br>establish the committee under the auspices of INCITS. I've sent in a<br>few questions to INCITS for example asking about how many people are<br>
needed to sponsor the project. Once I have the basics sorted out I'll<br>post a draft of the proposal here so we'll have something concrete to<br>discuss.<br><br>In the meantime we can get cracking, I reckon.<br>
<br>One think I would like to propose is that we embark on this on the<br>basis that this will be an on-going process delivering a version of<br>the standard every 18 months or two years. I think we should time-box<br>each version and simply leave out things that miss the deadline rather
<br>than hold up a version because of some thing we can get to an agreed<br>position on.</blockquote><div><br class="webkit-block-placeholder"></div><div>Agreed; see below. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Then I think we can start talking about priorities. What should we be<br>tackling and in what order? My suggestion here is that we take Sport<br>as a guide since that exists to paper over cracks - and we should aim<br>to seal up the most obvious cracks first. Specifically I'd suggest
<br>Association, Sockets and Files as being at the top of the list.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div></div><br>