Expression Based Language
Eric S. Raymond
eric at snark.UUCP
Thu Jan 5 12:31:04 AEST 1989
In article <9310 at ihlpb.ATT.COM> nevin1 at ihlpb.UUCP (55528-Liber,N.J.) writes:
>This (using expression forms) won't work too well in (full) C. The problem is
>that pure expression-based languages (like LISP) tend to be typeless as well.
>Having to return a specific data type severely limits the usefulness of making
>control-flow constructs (if, switch, for, etc.) expression-oriented.
To see that this is false, try a simple thought experiment. Imagine that you
have modified your C compiler so that the language now has two new properties;
1. Every block contruct { <st1>; <st2>; .... <stn> ;} returns, as an assignable
rvalue, the value of the nth statement <stn>.
2. The for, while, do, and case constructs return the value of the last block
executed before termination; that is, the value of the last *statement*
executed before termination.
Voila! Expression-oriented C. Trivial to implement, and *incredibly* useful
(if you've ever written LISP you know why). Look at what we could *drop* from
the language -- the sequential-execution comma and ?: operators, for starters.
If you're willing to break some old code, try thinking of function-argument
comma as an aggregation operator...then consider what foo = {4, 5, 2} might
mean for foo of type, say, (int [3]). First class vector arithmetic, anyone?
Now think about the possibilities for natural expression of parallelism in
expressions like {foofunc(), 66, p + q}.
These are *my* impossible dreams for the future of C. Hey, Bjarne -- any
chance you might want to include 1 and 2 above in some future C++ ;-)?
--
Eric S. Raymond (the mad mastermind of TMN-Netnews)
Email: eric at snark.uu.net CompuServe: [72037,2306]
Post: 22 S. Warren Avenue, Malvern, PA 19355 Phone: (215)-296-5718
More information about the Comp.lang.c
mailing list