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