[comp.lang.misc] Passing Values Through a "goto"

vg@csri.toronto.edu (Victor Greenberg) (01/07/89)

karl@haddock.ima.isc.com (Karl Heuer) writes:
>Let's try to define EC, an extension of C with the property that every
>statement is an expression, yet retaining the property that every expression
>has a type.  All constructs with no reasonable value definition become void
>expressions.
>...

I once designed an expression-based variant of C called "D".
This language supported "compound expressions" of the form:
	( [expression|declaration] ; ... ; expression )
The final expression yields the result.
This means you can embed declarations within expressions:
	( int i = getint(); i * i )

A compound expression with no declarations has the form:
	( expr1; expr2; ...; exprn )
and yields exprn as its result.  This means that the "," operator is
unnecessary, as ";" can be used in its place.

A compound expression with a missing result expression has a value of
type "void".  Eg:
	( expr1; expr2; expr3; )
This means we don't need C's compound statements enclosed in {}, we
can use parentheses instead.

[None of this is new.  Algol 68 already does all of the above.  I wish
 C were as well designed.]

>Passing values through a goto doesn't seem to work well, since a label by
>itself is not a valid statement.  Well, I guess we could say that a labeled
>null statement has the value of the statement preceding the goto, but that's
>stretching the idea a bit too far, I think.

Although goto is questionable as a language feature, it isn't hard to
generalize for use in an expression based language.  Instead of labelled
statements, you want labelled *expressions*.  For example:
	printf("%d\n", foo:(a+b) * c)
In the above fragment, (a+b) is a sub-expression with the label "foo".
When this fragment is executed normally, the value printed is (a+b) * c.
However, elsewhere in the program, you can write:
	goto foo(x)
This will jump into the middle of the call to printf, and the value
printed is x * c.

Doug Moen.

rcd@ico.ISC.COM (Dick Dunn) (01/12/89)

Karl Heuer wrote:
> >Passing values through a goto doesn't seem to work well, since a label by
> >itself is not a valid statement...

Victor Greenberg responded:
> Although goto is questionable as a language feature, it isn't hard to
> generalize for use in an expression based language.  Instead of labelled
> statements, you want labelled *expressions*...

Another way to think of this is to consider assembly language; let's assume
it's for a stack-based processor just to make it easier.  At the point of a
label, you need to know that the stack has a particular configuration no
matter how you get to that label.  It is equivalent to having a particular
type associated with the label...and, in fact, one could imagine performing
a coercion on the values "sent" to the label.  This is akin to the
balancing coercion required in a conditional expression--and, in fact, if
you think of the conditional-jump implementation of a conditional
expression, you can see the balancing taking place in the generated code.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Worst-case analysis must never begin with "No one would ever want..."

rpw3@amdcad.AMD.COM (Rob Warnock) (01/14/89)

By the way, the programming language "MARY" had exactly this type of
"value-carrying" goto about a decade ago...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403