Hi Neal,
Tennent in his book does directly reject return, break, and continue
using his principle. I speculate that he would also reject exceptions,
but I don't recall him discussing exceptions directly. Tennent rejects
break (and continue and return) on two grounds:
1. The following, break example, is a syntax error outside of a
looping block
break;
Therefore
while ( true ) { break; }
Should also be an error, i.e. enclosing in a block has changed the
meaning of the code (in this case drastically from error to valid).
Note the principle also says you should be able to remove a block, not
just add it.
2. The following, return example, changes meaning when enclosed in a
method (Pascal had inner functions and Tennent primarily used inner
functions to demonstrate his principle - below is in Javanese where
inner methods are allowed)
int outer() { return 1; }
Chances meaning (becomes an error) when enclosed in an inner method:
int outer() {
void inner() { return 1; }
inner();
}
Contrast this with:
int outer() {
outer = 1; // no return statement, Pascal uses method name for
return values
}
Now it doesn't change meaning when enclosed in an inner method:
int outer() {
void inner() { outer = 1; }
inner();
}
Tennent primarily used enclosing statements in inner functions for his
arguments, so the second argument presented above is a typical Tennent
argument (but please forgive the extension to Java for the inner
methods). The key from the second Tennent example is that a name is
given for what you are returning from. So you could use named returns:
int outer() {
void inner() { outer.return 1; }
inner();
}
By the way I don't think that Tennent's principle is always
applicable, for example I like return statements and hence my
suggestion of named returns.
To get back on topic; my point is that using Tennent's principle to
justify adding features to the JVM to support return etc. is a weak
argument because Tennent said you shouldn't have return etc. in the
first place! I am saying that if the only argument for a JVM extension
is based on return etc. and Tennent then I think the JVM should not be
extended.
Cheers,
Howard.
On Oct 30, 10:25 am, "Neal Gafter" <[EMAIL PROTECTED]> wrote:
> On 10/29/07, hlovatt <[EMAIL PROTECTED]> wrote:
>
>
>
> > Tennent's book is quite old and talks about Pascal, I don't recall any
> > specific discussion of exceptions and exceptions were not part of
> > standard Pascal. So my guess is that any form of non-local jumps would
> > not be covered by Tennent directly. The princiople says that the
> > meaning of the code should not change if enclosed in a block, e.g.
> > while loop, but it means any type of block and therefore also a try
> > catch block.
>
> That is not Tennent's Correspondence Principle.
>
> So my reading is that any form of non-block structured jump is
>
> > excluded by the principle, i.e. no return, break, continue, or throw
> > statements. All these have to be simulated with a status variable.
>
> Your reasoning isn't valid (that Tennent applied his principles to analyze
> Pascal, and Pascal doesn't have multiple exit points, and therefore Tenent's
> principles don't support multiple exit points).
>
> Interestingly if an inner class was used instead of a block then a
>
> > control variable could be used and exceptions avoided all together:
>
> If assembly language were used instead of a high-level language, one could
> avoid blocks, inner classes, exceptions, and variables too!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
