[self-interest] Language enhancements

[Michael Latta]

I will read the paper for sure.

I am no hurry to add features to Self.  You are correct that adding 
features to satisfy examples is a bad methodology for language design.  
Just look at UML 2.0 for an example.

I would say however that simple is not enough, it must be simply 
elegant.  The simplicity must solve a number of issues.  I am sure you 
had this in mind as well.  Just as Self can meet all the needs of class 
based inheritance without needing all the attendant infrastructure or 
restrictions, it would be better to have a simple elegant solution to 
many problems such as cloning of trees of objects, and adding 
transactionality to objects, and concurrency control, etc.  I may end 
up landing on something more akin to aspects than any specific 
features.  At this early stage it is still mostly an adventure, the 
result of the journey can not yet be predicted.

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