Folks,<div><br></div><div> 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>On a specific you've mentioned:</div><div>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.</div>
<div><br></div><div>best</div><div>Eliot</div>