Folks -

I'm attaching below a nicely considered response from Gilad which I though many would enjoy...
----------------------
>Dan,
>
>I saw your message about Animorphic. I've been lurking on the Squeak list recently, mainly to see if there was any response to the Animorphic release. To be honest, I was thinking of unsubscribing, since there's too much traffic for me to follow, and I (sadly) haven't that much time to play with Squeak.
>
>I'm sending my response to you and Nathanael. You can forward whatever parts you feel are relevant to the list. Most of it deals with the type system, which is what I really know about.
>
>At 10:49 AM 7/16/2002, Dan Ingalls wrote:
>
>>Ever since talking with Gilad & Co. about it, there has been this little plex in the back of my mind along the lines of "Squeak meets StrongTalk".
>>
>>The first component in this gestalt is that I think type annotations are useful as documentation, and I have always felt (and often said) that a Smalltalk with optional types would be an ideal computing environment.  It really fills a hole in the metasystem.
>
>Of course, I agree. The question is how can Strongtalk contribute to that goal.
>
>1) In my unbiased :-) opinion, the general approach taken in Strongtalk is the way to go. In other words, strictly optional typing that can be completely ignored and has no effect on execution.
>
>2) I think we can do better in terms of the actual type rules. There has been a fair amount of progress in type systems for OO languages since we stopped work on the Strongtalk type system in early August 1996 - 6 years ago now!
>
>This illustrates one of the key advantages of optional typing - you can evolve the type system while the underlying language stays the same. In conventional statically typed languages, you're stuck with what you started with.
>
>3) The Strongtalk source code is essentially useless to you. It is too poorly structured to port and/or maintain. As James Gosling once described an earlier version of javac, it is a "dog's breakfast". That's my fault I'm afraid - when you do new stuff in a hurry, that sometimes happens.
>
>4) Given a good spec, it shouldn't be too hard to implement Strongtalk and/or
>to develop more refined successors.
>
>5) I should be able to release such a spec in a few weeks. I'm working on it in the background, and it's quite far along. I'm also going to produce a tutorial.
>
>6) Of course, the real test is what you and others think of working with such a system. I have had zero feedback from people who downloaded Strongtalk wrt the type system so far. I hope people can play with it a little bit and get some feeling for it. If anyone does, they should READ THE SYSTEM TOUR FIRST!
>
>7) If people play with the type system, they will probably complain about the lack of documentation. I'm hoping the tutorial will address this. The spec will probably be too technical for many readers.
>
>8) So my suggestions for action are:
>
>a. Motivated and sophisticated users can play with the type system right now and get a feel for it.
>b. More casual users should wait for the tutorial to show up on our web site and then play with it.
>c. If there is still interest at that point, a fresh implementation should be done. I have this notion of doing this in my copious spare time. This is quite possibly delusional. I could help out and collaborate with someone, though this creates a commitment which I'm a bit leery of.  In any case, I'm temperamentally unsuited to open source development. I could work privately with select, qualified people, like Squeak central folks, or Nathanael for example.
>
>My strong preference would be to build the new system in Strongtalk first, so that I could use the type system (and reuse a lot of infrastructure). It could then be ported to Squeak or any other Smalltalk. In a well structured implementation a port would mainly involve dealing with parser/AST dependencies on the one had, and browser and reflection issues on the other.
>
>
>Finally, there's the issue of going beyond Strongtalk in terms of the incrementality of the system. Currently, we don't ensure type correctness of previously type safe code in the face of changes. This has been done in other systems (Trellis/Owl did it partially, VisualAge for Java does it). It's trickier to do if you want to keep footprint really small, and not keep enormous dependencies around, but that would be an exciting extension of the system.
>
>>The second component is a sort of BOBW (best of both worlds) notion that with the cool aspects of Squeak and its numerous multimedia facilities, together with what is arguably the fastest execution engine going, we could at least have a lot of fun.
>
>I think it's clear that Squeak needs better performance. People keep complaining that Morphic isn't fast enough, or that this or another abstraction or tool would be cool but too slow. You could do more interesting things more easily if you had good performance.
>
>>The third component has to do with applying the Squeak philosophy to what otherwise appears to me as a daunting project.  The Animorphics VM is (I would suggest) a programming tour de force.  I have always been paralyzed when considering such projects (and this goes for, eg, the SELF compiler, too), by the thought that I would burn out simply dealing with so much complexity all in C or worse (if you can imagine that ;-).  The whole idea behind Squeak (well, not the whole of it, but the implementation approach) was that we could write it in the language we already knew, and it would be easy to understand and test.  I don't see why we couldn't do the same thing for an engine similar to the Animorphics VM (Ian and I have also talked about doing the same kind of thing for Jitter).
>
>This is exactly what I would like to see happen. Unfortunately, that isn't my expertise. And some of it is inherently non-portable (you need to generate machine code somewhere).
>
>>Some questions are:
>>
>>        Would the system benefit from being cast into StrongTalk?
>
>Yes.
>
>>                and how much work would this be?
>
>A fair amount, but mostly in libraries that would have to be typechecked and  tweaked accordingly.
>
>>        Would anyone care if it ran 10 times faster?
>
>Yes.
>
>>                and how much work would this be?
>
>
>A great deal.
>
>>        Would it be fun to do?
>
>Yes.
>
>I hope we can actually move this forward. I would be delighted to see any or all of these things happen. Please respond to both my work and home addresses.
>
>
>Cheers,  Gilad
>
>*********************************************
>Gilad Bracha
>Computational Theologist
>Sun Java Software
>http://java.sun.com/people/gbracha/