related projects

Jecel Assumpcao Jr
Wed Feb 26 13:30:02 2003

On Sunday 23 February 2003 19:16, Brian T Rice wrote:
> On Sun, 23 Feb 2003, Jecel Assumpcao Jr wrote:
> > [3 people basically wrote Squeak]
> Well, there's core squeak, and then there's everything else written
> as an application or an enhancement. Squeak is a livable system
> because of all the enhancements made to it.

Yes, having speech synthesis, gesture recognition and stuff like that is 
really nice.

> Although the original 1.x
> series, which was only useful for exposing people to Smalltalk-80,
> was definitely the result of only a few people, consider first how
> little documentation they managed to produce, and furthermore how
> many decisions they had to make for economy's sake that wound up
> later causing too much contention over design issues. That's the
> aspect that projects based more closely on Tunes' goals have the
> greatest effect upon.

You mean a "do it right" mentality? I feel that this is what Alan Kay 
wants (he keeps pointing out stuff like PIE and Sketchpad that were 
better than what we have today) but the people actually implementing 
stuff seem to prefer quick hacks instead.

> > Ok, let me be more specific: I saw the Slate effort as being about
> > multidispatch without types. Since I think about Tunes as being as
> > serious as possible about types and correctness by proof, these
> > looked like two different directions to me.
> Hm, yes, this something that's largely missing from the basic
> language. While we *do* have a basic type system, and optional type
> declarations, these consist mostly of the core primitive types right
> now, and isn't really a very serious solution. (see
> src/compiler/types.slate in the CVS repository)

Ah - I hadn't seen that. It doesn't seem like a very Tunesy thing to 

> When bootstrapped, we will have the ability to extend this
> declaration system, and I'm hoping to introduce properly an idea
> unifying popular OOP unit tests with axiomatic types. I've been
> working on the collection libraries (well, generally all of the data
> structure libraries) to be type-safe, and for the static delegations
> to have some type-significant meaning.

These are both very interesting efforts. The unit tests thing in 
particular could actually become a much better version of what Eiffel 
has with its preconditions and postconditions. It could give you more 
information about types than simply correctness (see "Abstract Types: 
Interfaces or Protocols" about halfway down in

> Speaking of delegation, we are definitely interested in expressing
> this in a more high-level and perhaps constrainable way. We generally
> agree that delegation slots violate the direct-manipulation idea by
> mixing abstraction levels; the question is what new model to use when
> we have the opportunity (again, when bootstrapped).

We just need a "fence" somewhere so it is clear to the programmer that 
he is now changing things in a new level.

> Slate isn't that different from Self about it, at least not yet. One
> of our MOP priorities are Slot meta-object possibilities, which
> should address this decently. Some possibilities are: assign-once
> slots, slot dependencies, and slots with equationally-bound
> constraints. There are also options for making mutex-style locks on
> slots, but we need to pick a good abstraction for this.

Right, all these things interest me as well. Except for locks: I need a 
parallelism model that can actually be used by a fifth grader (my 
current design it at

> That's how Slate changed to PMD... the previous set of concepts
> behind it were so simple that they made getting back to the level of
> easy comprehensibility too much work.

It certainly seems "as simple as possible" and easily understandable. I 
have been considering this for my next Smalltalk (not the 16 bit one) 
but haven't figured out an efficient implementation yet.

> I suppose my eventual goal is to grow beyond the simple relational
> implementation I had going into something at least as expressive as
> Maude is.

Supposing you have Arrow running in Slate. My question is if the two 
would eventually merge somehow or if Arrow would always be a kind of 
application for doing limited things?

> I've always wondered if there really was a way to express that. Alan
> Kay's biological metaphors or the metaphor that each individual
> object was a whole computer never gave me a sense of definite
> direction that I saw in any of the Smalltalk iterations. Prove me
> wrong, please. :)

A quick overview of the new syntax is now available at
It is meant to be used in a graphical environment.

Given the hardware I want to create after the current generation of 
machines (hint: it is not Von Neuman at all) I really have to take 
Alan's metaphors very seriously. That is why I wasn't happy about going 
back from object=computer to group of objects=computer in my 
parallelism model (I gave the link above). It is a step back, but I 
will never finish the current project without these kinds of 

-- Jecel