[self-interest] Language enhancements

[Jecel Assumpcao Jr]

On Friday 25 June 2004 17:12, Michael Latta wrote:
> The current license basically says do what you want with it so long
> as we do not get blamed.

All versions that Sun has released had a similar license, though the 
early versions had the infamous "advertising clause" (which I don't 
mind at all).

The Self 1.X VMs were never released at all. I don't remember about 2.0, 
but at least I don't have a copy of it. And Self 4.1 was internal to 
Sun four about three years before being finally released under the 
current license.

> >> 1) I am considering making the inheritance of structural slots
> >> declarative.  Rather than listing the copydowns in each child
> >> object, allowing the parent to annotate a slot as copied.  The
> >> child objects would still need to be able to exclude those they
> >> replace with behavior.

This is actually how it is done in the programming environment (you set 
the slots in the parent as "copydown" and they show as pink in the 
outliner) even though saving a module as text creates some code to 
actually implement this imperatively.

> >> 2) I am considering adding an annotation to a slot that will cause
> >> it to be cloned when the object is cloned.
> >>
> >> These ideas come from working with modeling where there is more
> >> declarative work.  The items above would also need syntax to
> >> support textual definition of those aspects.  For example 2 above
> >> could be <slot>+ to indicate aggregation.  The idea is to reduce
> >> errors and reduce code to manage these aspects of a system.

Ok, so you want to control "deep copies". It wasn't clear to me what you 
meant above by "cloning a slot". This is a very interesting issue. When 
you clone a morph, you certainly want to clone its submorphs too.

> >> Let me know what you think, or if there are good reasons to leave
> >> it in code.

It is easy to come up with interesting features that make some example 
or other nicer, as David Ungar always says in his talks. The problem is 
that language complexity grows exponentially since each new feature 
interacts with all previous ones.

Both issues you mentioned can be viewed as particular instances of 
something larger - how can you organize stuff so sometimes you see a 
single object and sometimes you see smaller pieces which can be shared 
in interesting ways?

My first suggestion would be for you to read the Us paper (a subjective 
version of Self): http://citeseer.ist.psu.edu/smith96simple.html

This won't solve your problems, but should help you think in a more 
general way about them.

The "an object is really a tree of stuff and not just the root" thing 
was a major complication for me in parallelizing Self in tinySelf 1 and 
in my current work. Beyond subjects/viewpoints, there is an interesting 
idea I used in a language called NeoLogo which is "roles". I won't go 
into details here, but at first I thought that viewpoints was a good 
replacement for this, but now I see that though very similar they 
actually complement each other.

I would like one solution to all of these problems, and which made the 
resulting language even simpler. Never, ever forget "the power of 
simplicity".

Kyle Hayes wrote:
> > A little off track, but, I'd like to see the following in Self:
> >
> > 1) a drastically simplified VM so that it can be more easily
> > ported. All
> > ports but the Sparc and Mac are a little flaky in my experience
> > (sometimes
> > a lot flaky).  Having a VM that is so difficult to port makes
> > support and
> > expansion of the Self "marketplace" more difficult.

A proper Self implementation should be in Self.

> > 2) move more of the optimization into Self rather than hardcoded in
> > the VM
> > in C++.

See 1 ;-)

> > I like your ideas about the language!  While I like Self's
> > simplicity a lot, it is often nice to have reasonable short cuts
> > for very common idioms
> > like those you've covered above.

Unless you want to use it in a scripting language style (like 3.0 and 
earlier), Self is a language and an environment. We can have as many 
shortcuts as you want in the latter without having to complicate the 
former. The copydown thing is a good example.

-- Jecel