On Tue, 04 Sep 2007 19:39:17 -0700, Alan Kay <alan.kay at squeakland.org>  
wrote:

> In any case, what I meant was that it is too opaque to redefine a  
> pragmatically written compiler etc., for making most graceful  
> extensions. This is generally what is required for Smalltalk-80 and  
> leads away from a base language that is extended to an explosion of  
> different languages. So I meant that all extensions to the base language  
> should be simply visible as part of the new code that is added by the  
> extender and not be hidden in low level mechanisms if at all possible.

The idea being that...particular tasks would have their own  
sort-of-dialect?

> While at this, I think I'd also be tempted to try to make a more  
> fruitful architecture than ST-80 supplies for dealing with semantic  
> variants (cf the long discussions about problems of packages,  
> Monticello, etc.). The problems come from lacks of architectural  
> semantics for dealing with this kind of modularity and I don't think  
> trying to supply "life support" in the form of external tools is going  
> to help much in the long run. This is an important problem that no  
> language and DE handles well, and it's worthwhile trying to figure out a  
> stronger semantics to deal with it.

I seem to recall Bertrand Meyer trying to do something like that with  
Eiffel. (I studied the heck out of Eiffel when Meyer first wrote his books  
and ended up waiting and waiting and waiting....)

It seems like most gyrations done to existing languages to get them to  
support IDEs are severe and don't get them to the Etoys inspector level.