• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: Chip Morningstar Next in thread: Mark S. Miller

The discussion has been sufficiently articulately theoretical, I lost confidence I knew what would happen if you didn't put a guard of any kind on the method--is that a syntax error?

Taking Ping's ":" proposal and seeing where it goes, does this work?

define carMaker new(x,y) : any {

define car {

        to getX : any {x}
        to getY : any {y}
        to moveTo(newX, newY) : void {
            x := newX
            y := newY
        }
        to moveDistance(distanceX, distanceY) {
            x += distanceX
            y += distanceY
        }

This is really mostly a confirmation I understand Ping's proposal.

Markm, unlike you, my visceral sense of the frequency with which I wind up having
void methods is pretty high (though I suppose it makes sense to look at Edesk and see what really happens if we need to argue this to the ground :-) So in the above example, one of the 2 void methods has no guard, and it defaults to void.

As far as the frequency of voids is concerned, I also observer that functions--single-method objects with only the default "run" method--will indeed just about never be void since there's no state to change. In saying voids are rare, are you looking at examples with lots of functions and few objects?

Whether the default-to-void can be made to work or not, I find this syntax pleasing enough, given the extra functionality it enables, namely the type checking. Certainly the type checking will be handy for security auditing. On the other hand, I would wish we didn't have to introduce the type-mechanism on the first page of the intro to E, but so it goes. On the third hand, a lot of people will actually find it attractive to have type checking on the first page, though it does complexify the first examples.

--marcs

> MarkM sez:
> >What do you get when you cross Chip's "^" syntax with Bill & Norm's
memories
> >of Algol68? A more expressive way to say whether a value is returned.
> >
> >To start with the punch line, here's the old getterSetterPair() example
> >http://www.erights.org/elib/capability/ode/ode-objects.html#facets
rewritten
> >using the syntax I'm proposing:
> >
> > define getterSetterPair(value) ^any {
> > define getter() ^any { value }
> > define setter(newValue) ^void { value := newValue }
> > [getter, setter]
> > }

>

>


> >1) Guarding a return value

> >

>
>


> >2) Guarding a variable definition.

> >

>

>
>

[ Next ]
• [ Previous ] In reply to: Chip Morningstar Next in thread: Mark S. Miller