related projects (was: good books)

[Brian T Rice]

On Sun, 23 Feb 2003, Jecel Assumpcao Jr wrote:

> On Thursday 20 February 2003 22:37, Brian T Rice wrote:
> > On Thu, 20 Feb 2003, Jecel Assumpcao Jr wrote:
> > > [silly Tunes, Squeak/Merlin is for kids!]
> > Alternatively, our
> > end users could be "web designers" who simply use our system (along
> > with the appropriate number of bridges to existing systems) as an
> > extended, more dynamic version of the world-wide web. Basically, we
> > will *not* win over C programmers or perl hackers until we have a
> > full system, so there's little point in trying. But out-doing Squeak
> > in the systems, semantics, and user interface would be possible. The
> > premise of Tunes is that we could do this with far fewer people than
> > it takes to work on Squeak, for example.
>
> How many people do you think made Squeak? I would say it was basically
> Dan Ingalls and John Maloney in the first phase, and Andreas Raab in
> the second. I hope I am not being horribly unfair here, but that was my
> impression.

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

> And Squeak has the problem of a huge legacy it must be compatible with,
> so doing neat stuff is really hard. Putting modules in GNU Smalltalk is
> trivial compared to the effort that went into the failed Squeak 3.3.

Which is part of the reason for Slate's existence as it is now: being at
least marginally-compatible with existing systems (Smalltalk, Self, Lisp)
while more expressive and less complicated in hopefully the right ways.

> So I agree - Tunes doesn't need a large group to exist.
>
> > I haven't been exposed to any of these books. Hopefully a "catalog"
> > of Slate libraries can be generated somewhat automatically.
>
> The source files and comments are already a great start. They are very
> readable.

Great!

> > > [relation between Slate, Arrows and Tunes?]
> >
> > Slate's an intermediate platform for Tunes, at least in my view of
> > things. The interfaces work will go into this as well as the
> > libraries and the run-time. None of the code we're writing for Slate
> > is "Tunes code" as such: it will eventually need to be extended
> > again. But it represents an intermediate point for Smalltalk, Lisp,
> > and some less-expressive systems between them and Tunes, and so at
> > least tells us how code has to change.
>
> 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)

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.

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

> > The technical objection to the Self model for Tunes is simply its
> > statefulness (not state per se, but the way it's expressed), the
> > irregular grammar, and the system model.
>
> I didn't notice between the way Slate and Self express statefulness, but
> wasn't really paying attention. In the other aspects, my own work now
> differs more from Self than Slate does. I have to write this up on my
> swiki so people can see what I am doing.

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.

As for visibility of changes, Slate needs a site update of a decent order
as well.

> > As for Arrow, I am trying to resurrect my code for that, but it won't
> > load in to newer Squeaks unless I discard all those damned class
> > comments I wrote for it. Anyway it'd be more expressive/ible in
> > Slate.
>
> I can still run Squeak 1.3 when I need to :-) Do you think it would be
> worth having a Slate version of Arrow before you have a GUI?

That's a great question. The presence of the Connectors package makes my
GUI work a lot simpler, but even with the GUI, in Squeak I'm not sure how
much I could express before running into a serious complexity limit. I
would prefer to reflectively hack Slate and re-implement the Connectors
system in Slate's GUI and build within that. So I need to figure out what
the priorities are here.

> > The relation to Tunes is mostly as a theory, and is missing as
> > much in its plan for operation as Tunes is, except that Arrow has
> > fewer concepts or rather structural requirements to support. This
> > property means that I don't have to worry about "what a Context is"
> > or "what kinds of meta-objects should be supported and how", because
> > the model is so much simpler that there's no language concept to
> > potentially stand in the way of getting the information annotation
> > you want done. The disadvantage is that the basic idea has no real
> > language concepts as such to explain it.  :)
>
> Einstein said "make things as simple as possible, but no simpler."
>
> To figure out what that is, I like to build things so simple that they
> no longer work in practice (a microprocessor with just one instruction,
> for example), learn as much as I can from it and then throw it away and
> start with something more reasonable.

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.

Arrow will likely change quite a bit. Even if I kept it in Squeak, a lot
of what it needed for implementation is now provided as the Closure
Compiler and the safety and eventual-sends semantics borrowed from E.
Porting it to Slate/PMD would at least express the design more clearly,
but the real changes would involve making a working concept that does what
I wanted Frames to do, which was essentially to provide a linguistic
environment for it.

Also, a lot of the work in ensuring safety WRT state that I want to do in
Slate will help out, as well as the slot meta-objects. Also the much much
more expressive and polymorphic data structures libraries help out quite a
bit in allowing a separation of implementation from strategy.

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.

> > So that's my outline. There's a lot to work out, and I can't say for
> > sure how much Self/R is closer to Tunes than Self, but Slate
> > definitely picked up some ideas from it, and may continue to do so.
> > (We don't even have a real MOP at the moment, so there's a lot of
> > room for expansion there.)
>
> There is a lot that I have worked out but haven't written down yet. A
> new syntax, meta-object architecture, lots of hardware stuff that is of
> no interest to Tunes, etc. I am changing the name from Self/R to Neo
> Smalltalk since I feel we are getting closer and closer to the core of
> what Smalltalk is all about even as it looks less and less like
> Smalltalk-80.

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

> Right now I am bootstrapping a really small implementation of the
> language on a 16 bit microprocessor, so the details that I owe you all
> will have to wait a little longer.

Okay. Good luck.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/