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