related projects

[Brian T Rice]

On Wed, 26 Feb 2003, Jecel Assumpcao Jr wrote:

> On Sunday 23 February 2003 19:16, Brian T Rice wrote:
> > On Sun, 23 Feb 2003, Jecel Assumpcao Jr wrote:
> > 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.

I suppose so, but I wouldn't point out PIE and Sketchpad as the best of
what was lost.

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

Nope, it's entirely pragmatic. Generally, the Tunesy thing we intend to do
requires us to deal with programs in an abstract manner, allowing
annotations to be built without special syntax. So expect interesting
things after the bootstrapped system has been built out into something
semi-comfortable.

> > 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
> http://www.lsi.usp.br/~jecel/tech.html).

I know I've read that before, but it's probably been some years. Anyway,
yes that's the kind of thing we're hoping for.

> > 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 http://www.merlintec.com:8080/software/9).

Well, we're still fishing for a good high-level parallelism model (the
low-level one has been worked on but isn't set in stone).

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

Eventually, they should merge in some way, with Arrow becoming a general
pervasive utility for developing information transformations and
translations, as well as providing the nuts and bolts for an inference
system. However, this requires some fancy partial evaluation work and even
more work on relating the different ways of formalizing arrows, so who
knows when/if it will be feasible.

> > 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
> http://www.merlintec.com:8080/software/4
> It is meant to be used in a graphical environment.

This appears to be requiring context-free grammars. This kind of syntax
generality is why I've been looking into Maude's MetaParser system (see
http://cliki.tunes.org/Syntax%20in%20Maude). Right now I'm translating a
Smalltalk parser-generator to Slate just to get LR1 and LALR1 handling,
and it's not attractive at all, although better than it was for Smalltalk.

But to get the MetaParser usage, you have to implement Maude's semantics
to some extent, so eventually the object-oriented approach has to yield
somehow. I suppose this is where I should tie things in with Arrow, but
I'm not sure.

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

Actually, I think it makes more sense.

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