At 09:04 PM 10/12/98 -0700, Sheldon Nicholl wrote:
I really feel like I'm going out on a limb by saying this, but I think Smalltalk would be a better language if non-local returns were removed entirely. They cause trouble all across the board, from the Debugger to the VM to beginning Smalltalkers trying to learn the language.
Interesting idea, but could you get away with it?
I think so. First, let me clarify my proposal: redefine the meaning of ^ to be a local return (thisContext sender), not a non-local return (thisContext home sender), and use continuations for non-local stuff. I consider the use of exceptions here (or similar mechanisms) a distant dark-horse alternative, to be used only if no one wants to use continuations. That is, exceptions should be used for exceptions, not to get non-local returns.
For example, would the following be illegal
stream atEnd ifTrue: [^self] ...
1 to: 3 do: [:x | (self foo: x) ifTrue: [^self] ...]
[x < 4] whileTrue: [(self foo: x) ifTrue: [^self] ...]
I'll be a bit slippery here and give four alternative proposals, ranked in increasing order of preferability:
(1) The Status-Quo Solution (2) The Language Realignment Solution (3) The Clean Programming Solution (4) The Continuation Solution
(1) The Status-Quo Solution: Since all of them use constructs like whileTrue:, ifTrue:, and so on which are always inlined, the reinterpretation of ^ as a local return will work since these constructs don't create a context. Not seriously recommended.
(2) The Language Realignment Solution: We admit that the automatic inlining of these constructs (ifTrue:, etc.) by the compiler constitues the legislation of them as built-in constructs like other languages, such as Pascal (if-then, etc.). No message is sent, no context is created, they can't be browsed on, can't be traced, the code in their methods is not executed, can't be changed, and so on. Just like language constructs.
The outcome of this is to realign the language by creating special constructs for them which are recognized by the Compiler. That is, we only change the front-end syntax; what comes out the end in bytecode will hardly change, if at all. Once they become special constructs, blocks are unnecessary, so the reinterpretation of ^ as a local return works naturally.
(3) The Clean Programming Solution: I feel like I'm being a bit unfair here, since most of the examples given above seem more like theoretical expressions than examples of actual use, but I'll take them as they stand.
The examples also allow me to add to the list of troubles caused by non-local returns: "questionable" style.
stream atEnd ifTrue: [^self]
Why not just say:
stream atEnd ifFalse: [...the rest of the method...]
or maybe better:
stream atEnd ifFalse: [self doTheRest]
I think I can answer this question: because it looks terrible. I'll admit I've used it countless times, but almost always with a twinge of conscience.
But we can't let imperfections in the syntax of the language push us into a questionable programming practice.
1 to: 3 do: [:x | (self foo: x) ifTrue: [^self] ...]
My gut reaction here would be to try using a detect: e.g.,
(1 to: 3) detect: [:i | self foo: x ...]
I can't think of a time over the last couple of years (at least) when I've had to use anything but a detect: to get the effect of jumping out of a loop prematurely. And detect: can be rewritten to avoid the non-local return. Or if you want something more general, how about something like
aCollection do: iterationBlock until: exitBlock
which does the iterationBlock until exitBlock becomes true.
[x < 4] whileTrue: [(self foo: x) ifTrue: [^self] ...]
This one is a bit bizarre, since I can't think of an example in the image where one needs to jump out of the body of a while loop. My feeling is that the receiver of whileTrue: should be powerful enough to detect any escape conditions. So why not move (self foo: x) into the receiver block?
(4) The Continuation Solution. This is the original proposal, to use continuations for non-local movements. So in those rare cases when it really is appropriate to jump further than one's sender, the machinery is there, and it's clean every time.
glenn
--Sheldon
P.S. Getting back to Tim Rowledge's original comment:
Unwind support is needed to handle the case of a non-local return merrily skipping past your unwind protection block, leaving your files open, sockets flailing or other catastrophes imminent. A non-local return can jump from one context back up to another without passing Go, thereby causing untold trouble. The VM mod would scan up the stack from source to target, checking for marked contexts on the way; any marked context found woud be sent a suitable message, somewhat like #cannotReturn:
I just want to plead that in case something like this is adopted, that it be done at the image level. It involves far too many operations, way too much intelligence for something that should be in the VM, which should consist of simple clean primitives only. Unwinding is something that a programmer may want to modify, which is another argument for putting it in the image.