[self-interest] Language enhancements

[Ian Woollard]

Michael Latta wrote:

>I am considering creating a VM for Self with some language extensions
>
Me too. Except I have some cute probably non backward-compatible changes.

> and would like comments:
>
>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.
>
>2) I am considering adding an annotation to a slot that will cause it 
>to be cloned when the object is cloned.
>  
>
Yup *very* good move.

Other ideas I've had include:

a) *optional* typed function calls (i.e. functional programming, pretty 
much). This allows different functions to be implemented differently 
based on the 'class' of their callers. This reduces the complexity of 
function. The type can be a class, or transitive parent(s).

b) optional parameters

c) privacy (children can't see the parents private slots)

d) children inheritance (you can inherit off your children- and they 
supercede any slots in self or parents without error- also in that case 
they would have access to private slots in self, but not children)

e) optionally executed block slots in functions

Whys:

a) IMO it improves the code, used carefully; and *only* where appropriate.

b) I've used java, which doesn't have it, and I've looked at scripting 
languages that do have it; the scripting languages are easier to use, 
and remember the APIs for, and shorter code; the language improves

c) this is a sufficient condition for securing Self (currently it has 
*no* security!)

d)  this is spectacularly useful for some things, noteably implementing 
state machines; I'm *very* sure it's incredibly useful for some other 
things too.

e) simplified syntax of ifTrue: statements, shortcircuiting and: or:  
statements etc.

>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.
>
>Let me know what you think, or if there are good reasons to leave it in 
>code.
>
>Michael
>  
>