Symbol and Array printOn: -- call for volunteers

Dwight Hughes dwighth at ipa.net
Fri Jan 14 07:15:26 UTC 2000


Dan's process reminds me somewhat of the Scheme SRFI (Scheme Request For
Implementation) process - http://srfi.schemers.org/ . While I consider
the actual SRFI process much too rigid and formal for our purposes, I do
like how it focuses each SRFI on a particular item or closely related
group of items (for example, some are relatively narrow in focus like
"SRFI 11: Syntax for receiving multiple values" or "SRFI 4: Homogeneous
numeric vector datatypes", while some are designed to define a proper
and reasonably complete working set of functions for a particular domain
like "SRFI 1: List Library" or "SRFI 13: String Library"). The emphasis
is on first defining in some detail the set of functions and
functionality that should be implemented, using feedback to smooth out
the obvious rough spots and omissions in the initial definitions, then
refining the details as the implementation is created. 

An aspect of this process that is very appealing is that it
"automatically" creates good (or at least detailed) documentation for
what is done.

Creating SqRFIs in a similar spirit might be a Good Thing. One thing
that could be very good for Squeak is to look at actually defining the
true core functionality for the core system classes -- in particular for
classes/class hierarchies that tend to accumulate a lot of cruft from
nearly every application ever added to any distributed image - String
and Object come instantly to mind of course. (A random thought -- as the
true core protocols were defined through a SqRFI process, it might be
useful to define a core/noncore marker bit in method headers to embed
this knowledge in the image.) A class or a small class hierarchy
protocol and its precise definition and implementation could be a single
SqRFI. Along the way old gotchas and surprising asymmetries and
omissions could finally be squashed -- a little bit at a time. Just
saying "Let's define the core methods for all the core system classes"
won't get us anywhere -- but saying "Let's define the core methods for
class String" is very doable task. [ A big underlying question here is
"why do Smalltalkers so often feel the need to add or modify methods in
the base classes" -- part of the answer is "because we can". But is
there a more fundamental "problem" at work here? Are the methods in many
base classes incomplete or insufficiently general for the classes'
domains? ]

Also, IIRC, one prime motivator of the Scheme SRFI process was to
finally create "complete" and reasonably general solutions to commonly
needed functionality. Several partial libraries would often exist for a
particular problem domain - each implementing the particular 80% of
functionality that each particular author needed to solve their
particular problem -- of course, this 80% was always a different 80%
from any of the other existing libraries -- and any common functionality
was usually so incompatible in detail that combining the libraries to
create a single general library was out of the question. Creating SqRFIs
to finally "complete" and generalize such 80% solutions in Squeak may be
very useful (I know I've seen at least 5 separate, partial, and
incompatible attacks at HTML generation and parsing in various apps for
Squeak).

-- Dwight

Dan Ingalls wrote:
> 
> Folks -
> 
> This is another topic on which we have been around at least once before.  The last time we discussed it, I channelled it into a project where I suggested a number of ANSI (or other de-facto) compatibility issues might be addressed together.  This was a mistake.  Like a political bills with too many barnacles, the effort pretty much died there.
> 
> The issue is of low priority to SqC, and that is why we haven't done more (though Vassili Bykov did notice that I recently implemented #'string for symbol'). That was easy because I knew it didn't conflict with anything else in Squeak.
> 
> The proposals before us are not so simple, because code such as
>         strm nextPutAll: 'named: '; print name; cr
> will fail if Symbols print differently.
> 
> However, it is clear to me that this would be a Good Thing, and this is the perfect time to make such a change.  2.7 is out and we have plenty of time to shake down this kind of change in 2.8alpha.
> 
> Here is a proposal for getting it done:
> 
> 1)  Some brave soul or (as we used to say in the 60's) affinity group steps forward to draft a spec for better Symbol and Array printOn: (and whatever not-too-vast set of other things that should accompany them).
> 
> 2)  We (all Squeakies) bless this, and someone implements it.
> 
> 3)  It then gets circulated for review and test as a fileIn (not an update).
> 
> 4)  We beat on it for a week, and report/fix bugs as usual.
> 
> 5)  As soon as it looks reasonable, I'll put it out as an update for 2.8alpha, where it will get lots more testing before 2.8 is done.
> 
> Does this sound like an effective approach?
> 
> Do we have some volunteers?
> 
>         - Dan





More information about the Squeak-dev mailing list