[self-interest] Language enhancements

[Michael Latta]

I read the paper on perspectives.  It has some interesting ideas, but 
from my perspective the concluding sections seem to say that it failed 
to solve the problems it set out to solve.

The use of perspectives to solve security was clearly not a solution as 
they worked through that one.  The use of perspectives for creating 
private interfaces only worked in the absence of other perspectives, 
which seems to be true in the multi-user and multi-view cases as well.  
I would make the following changes to their approach and see if the 
result was an improvement:

1) Allow access to "context" provided by enclosing activations.
2) Allow fuzzy dispatch (you think you see one object, but there is a 
constellation of objects that cooperate to respond to the message.  The 
parts of an object could be managed in a way similar to the layers in 
the paper, but would allow "perspective" to be taken from the context, 
or elsewhere, and would allow multiple active perspectives to influence 
the dispatch.

The suggestion that extending the language requires thought and 
experimentation I wholly agree with.  Peer review of the proposed 
changes will also be important.  The subjectivity idea has merit as a 
way to mange complexity.  The COM idea that you must ask an identity 
for a perspective is similar, but would need a contextual frame of 
reference to match up.

Michael



On Jun 25, 2004, at 4:21 PM, Jecel Assumpcao Jr wrote:

> 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
>
>
>
> Yahoo! Groups Links
>
>
>
>
>