At 8:33 PM -0300 8/19/02, Jecel Assumpcao Jr wrote:
>I wrote a page with five ideas to simplify Self (slightly blue plane
>stuff):
>
>    http://www.merlintec.com:8080/software/11
>
>The jargon there is very Self oriented and so might not make much sense
>to Squeakers. Some of the ideas at least could be applied to Squeak -
>
>1) unified block/method/context objects
>
>in Self, methods are supposed to be prototypes from which we obtain
>contexts by cloning. In practice it doesn't work that way and this is a
>call to take the idea seriously. Since Squeak is class based we are
>already used to the idea that an object and the template from which it
>is created are very different, so the idea doesn't have the same
>impact.

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.
      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.

>
>2) up arrow as binary selector
>
>Squeak has little special syntax: <- (or :=), ^, self, super,
>thisContext, true and false. Self has even less and I would like to
>take advantage of idea 1 and make ^ be just another binary selector.
>This doesn't apply to Squeak since it doesn't have the "implied self
>receiver" syntax.

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.

>
>3) simpler syntax: no literals
>
>This idea would work just as well in Squeak and we already have a taste
>of it in MathMorphs and eToys. If you can embed a graphical
>representation of any object in source code, you don't need syntax for
>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.

>
>4) simpler assignment
>
>This is an attempt to make assignment and message argument binding be
>the same thing. A side effect would be to allow more flexible keyword
>messages with default arguments.

This is really important, and was much better done in ST-76 and ST-72.

>
>5) removing inheritance from the base-level
>
>parent slots are a neat language design "pun" (a single thing is used
>for both "has-part" and "inherits-from" relations) but it would be
>better to have all program structuring stuff live exclusively in the
>meta-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.

>Squeak doesn't have parent slots, of course, but does have
>#class, #isKindOf: and other unmarked portals into the meta-level
>underworld.

We need a complete (or darn close) and real metasystem.

>
>===
>
>As I was thinking about the pink plane / blue plane stuff, I came to the
>conclusion that there is a related but separate dimension. A project
>can seek "synergy" or it can work towards a "separation of concerns".
>
>If you add a JIT, for example, it might be an optional plug-in that
>makes things faster when present, like in Jitter 3. Everything can work
>either with it or without it. An alternative would be to make it a
>central aspect of the design (like Self or Jikes) and try to see what
>can be made simpler because of it. Can name spaces be simpler? Modules?
>3D graphics?
>
>My personal taste makes me favor synergetic designs but there are
>problems. It is harder for more than a small group (or even a single
>person) to work on it. It is harder (impossible?) to understand a part
>of the project without learning all the rest. New requirements might
>come along and it might be easier to throw away the system and build a
>new one than to adapt it.
>
>The "separation of concerns" step-by-step development is the way to go
>in the pink plane. But what is the best style for Squeak on the blue
>plane?

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.

Cheers,

Alan

----------

>
>-- Jecel


--