blue ideas

Jecel Assumpcao Jr jecel at merlintec.com
Wed Aug 21 01:41:46 UTC 2002


Hi, Alan

Thanks for your thoughts!

> First, I should say that I really like (a) a lot of the ideas in
> Self, and (b) the motivation behind trying to do Self.

BTW, I am thinking of having the official name of what I now call Self/R 
be "Neo Smalltalk". Would anybody have a problem with that? Even though 
it will be to Self what Self is to Smalltalk-80, I think it is very 
much in the spirit of Smalltalk (and I even intend to make it ANSI 
Smalltalk compatible).

>       But, I think there is an entity somewhere between classes and
> Self prototypes (I've been calling them exemplars) and some action
> somewhere between instantiation and cloning that would work better --
> and I'll bet there are several people on this list including yourself
> that could come up with these better structures.

Some people think that it is easy to build class-like objects in Self. 
What is easy is to have shared code (and even shared state) with 
mixin-like objects. There is no inheritance of "object format" (if 
class X has instance variables "a" and "b" any subclass will have them 
as well) and they aren't much good at grouping related objects 
together.

Note that these things are possible - so much so that Mario Wolczko's 
Smalltalk-in-Self implementation did it (see "self includes: Smalltalk" 
http://research.sun.com/self/papers/smalltalk.pdf) using a structure 
nearly identical to that described in W. R. LaLonde, D. A. Thomas and 
J. R. Pugh. "An exemplar based Smalltalk." In Proc. of ACM Conf. on 
Object-Oriented Programming Systems, Languages and
 Applications, 1986, pp. 322--330.

But on the issue of "an action more like instantiation" I don't have any 
ideas. What is missing from cloning?

> >2) up arrow as binary selector
> As Andreas and others before him have pointed out, minimal syntax (a
> la LISP) is a double edged sword. I personally liked the slightly
> richer syntax of ST-76, and especially liked the "slightly richer
> than that" syntax of ST-72. "Uniform with helpful markers" is a good
> motto here.

Right, the "less is more" temptation is the very first of the seven 
deadly sins listed in the paper of that name:

  http://www.csse.monash.edu.au/~lindap/research.html

And as Brian Rice pointed out to me, this idea makes you have to add 
parenthesis when returning expressions with keyword selectors :-(

> >3) simpler syntax: no literals
>
> Interestingly, this is even in my Master's thesis on Flex. It just
> never happened in Smalltalk despite occasional urgings. I have often
> wished for such a "literal literal" facility in Smalltalk.

Some people wish for a more declarative Smalltalk. And since the current 
modules design doesn't handle arbitrary objects, it isn't too friendly 
towards this idea.

The bear/flower/bee font picture in your 1977 Computer article was my 
inspiration for this. I discovered that I didn't really want a visual 
language. And I didn't want a textual language. I need the best of 
each.

> >4) simpler assignment
>
> This is really important, and was much better done in ST-76 and
> ST-72.

It is hard to be so flexible with a stack based virtual machine, 
unfortunately. I am still trying to figure it out how it might be done.

> >5) removing inheritance from the base-level
>
> Precisely. The problem with parent slots is that they are much too
> lisp-like for an OOP language. Also, there are many other
> relationships that are useful (as in CYCL) that should be metalevel
> implementable.

You mean http://www.cyc.com/cycl.html ? It reminds me of Frames, which 
of course remind me of prototype based languages. It also reminds me of 
UN's universal network language (UNL - 
http://www.unl.ias.unu.edu/unlsys/index.html).

> One way to think about this is that you want everything to be
> separate, but to be easily able to specify dynamic relationships that
> express the nonlinearities. For example, "a really good thing to do"
> in Squeak would be to put a vertical line in a method and have a
> really simple semantic description on the left, and an optional
> case-based set of optimizations on the right. Run both to test, etc.
> The case pattern matches constitute the dynamic relationships that
> "join" the two kinds of descriptions. Similar techniques can be used
> to implement multiple perspectives, delegation models, and nonlinear
> event-driven interactions. The whole blueplane idea here is to try to
> separate strategies from tactics and "ors" from "ands", but to be
> able to relate them in a clean way when it really helps matters.

I agree, but while this is also what the Aspect people are trying to do 
I am not very happy with their results. One problem is that any textual 
notation to describe these "join relationships" will be too awkward to 
be useful for non trivial examples. Another problem is their focus on 
"blue print" languages (where the whole system is described in the 
sources - no image files with hand made objects) so that their 
relations are static and not dynamic like you want.

BTW, I think I already mentioned this here but it seems to me that the 
most important optimization in expert code is cacheing results. Could 
you give an example of a method with a simple semantic description and 
with case based optimizations? I think it is likely that we could 
transform one into the other simply by tagging certain expressions as 
being cacheable (we could show them in a different color in a browser).

-- Jecel



More information about the Squeak-dev mailing list