Folks,

    thanks to Andreas for a great topic.  My Squeak directions are two-fold,
pragmatics (performance and interoperability), and programming (the system
as a metasystem for defining languages & systems).  I don't think I need to
justify these; they both are important underpinnings and enablers even if
they're only means to ends.

Performance for me translates to continuing with Cog, getting it released to
the community, and integrating with other performance work (especially
Igor's Hydra).  The next steps are a less naive code generator and a
streamlined object representation which together should raise performance to
VisualWorks levels.  Releasing to the community could yield some more ports
(PowerPC, ARM).  I'd like to see someone copy the zygote idea in Dalvik of
having the system spawn a read-only copy from which instances are rapidly
obtained and diverge via copy-on-write.  This obviously fits with Hydra.

Interoperability agan translates initially to Cog work. The threaded VM I've
been working on should result in much more convenient interfacing with APIs
such as those for GUI events and blocking i/o such as sockets.  Providing
proper callbacks, merging Alien facilities with the FFI and providing a
natively multi-threaded but non-concurrent VM provides a good platform for
lots of stuff.

For a vision I think both of the above point in the direction of image-level
components, which I believe is one sensible direction up from objects.  All
sorts of distribution, reliability, scalability and update issues are
addressable when one architects a system out of many virtual machines (think
thousands or millions of ~< 1 meg footprint images).

Another direction is being able to allow plugins to be covered by the sands
of time.  I know you are concerned about the lack of modularity and hence
fragility that implementing plugin-like facilities at the image level might
entail.  But that militates for better modularity constructs and things like
exception handling in the FFI to allow easier debugging of crashes.  That
many plugins are prototyped and written in Smalltalk^H^H^H^H^H^H^H^H^HSlang
and then deployed through C is testament to the advantages of writing them
in Smalltalk, and it would be great if the whole Slang cycle was eliminable.

As far as the metasystem goes, keeping Squeak really good at doing language
experimentation and tool evolution will keep things like Seaside and
Newspeak happening and, even if only indirectly, enriching and growing the
Squeak community.  This is another source of requirements for better
modularity, since being able to understand a small core and spawn a new
language system from it while jettissoning the rest of the system is key.

Of course the jury is still out on how to do namespaces for Squeak.
 Newspeak is excitingly radical here but its perhaps too far.  Perhaps one
can get a long way without a language construct and instead relying on tools
to help partition the system into the right set of onion skins, each skin
divided into techtonic plates.  But modularity is a consistent theme in most
of the above, so I hope lots of experimentation with modularity occurs and
the current cleanup work continues.  Good conventions and language support
like pragmas can probably go a long way.

On a specific you've mentioned:
Packages:  Better performance and smarter implementation will allow one to
get rid of image segments.  As you've pointed out image segments are too
inflexible.  David Leibs' basic design for parcels, which is essentially
batch allocations and keep the interconnection graph separate, so that
loading involves populating an object table with instances and then knitting
these together using the graph data, is much faster than e.g.
ReferenceStream.  Once binary loading is handled by the image it is easy to
make it flexible and add the metadata to allow shape-change on load etc.

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091129/b6a5c9f6/attachment.htm