At 12:47 PM 10/26/99 , Marc Stiegler wrote:
>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?
[+] Yes, losing confidence is definitely 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.
[+] Confirmed.
Except that you forgot the ": void" on moveDistance, which, I gather from the rest of your note, was intentional, or is the question you were actually asking about above. In the current/Ping proposal, this would indeed be a syntax error.
>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 :-)
[+] It would be good to check.
>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.
[-] Say what! Write "Lambda Abstraction" on the wall 100 times.
Why should functions have any less access to mutable state than objects? How does having 1-run-method vs multiple methods effect what state they have? For an example of a stateful void-revealing function, look at the "cancel" function inside the smart contract for the covered call option at http://www.erights.org/elib/capability/ode/ode-bearer.html .
>In saying
>voids are rare, are you looking at examples with lots of functions and few
>objects?
[-] No, but I may be programming in a more side-effect-free fashion.
>Whether the default-to-void can be made to work or not, I find this syntax
[+] I feel the same way.
I expect an initial explanation for the novice may say merely
but you're the explanation expert. What should we say?
>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.
Write ": any" when you want to reveal a value and ": void" when you don't.
We'll explain later.
Cheers,
--MarkM