D. Tweed wrote:
Yes, I guess it's time for a confession: I'm making a rather sweeping assumption that the patterns in which I do and don't program are in some way `average' or `typical', even though they probably aren't. For instance, I don't even use patterns like `a[b++]=c;' just because it requires too many `mental cycles' for me to figure out what's going on when I reread the code; most other C programmers probably would use that construct, I expect. Having said that, within this sort of style I find that I don't really (have to) go beyond the idea of a machine with a store of named variables, some of which are actually arrays or have other structure, and tend to use the simple rule `if you assign/read outside array bounds or to a pointer location which does not map within a store defined variable/variable array, the program may (in a way which is so dependent on history as to be effectively non-determinisitic) either place gibberish in any other stored variable cell, return gibberish, return sensible values and have no observable ill effects or seg-fault'.
My reaction to that is: you are not programming in C. If you restrict yourself to nice subsets of a programming language, then obviously your programs will satisfy better properties. Viewed in this way, Haskell is a (completely different) subset of C. But of course you lose the opportunity for the compiler and standard tools (which includes the standard semantics) to take advantage of these nicer properties, and are justified then in complaining to the language designers, "Hey, why did you put all this cruft in there? I don't need it, and it makes it harder to use the language!" The point of having a language, IMO, is that its laws govern, _universally_, all the programs you can write in it. Otherwise you would just say, "Yeah, C is really hard to reason about, but if you consider all my C programs _individually_ the sublanguages they are written in actually satisfy nice properties." So, in the limit you might specialize your `language' differently to every single program you write. By that token, then, all programming languages become equal, and we have reduced this discussion to triviality. I am not denying that you can have a nice imperative language (although I think that `just' a global store is too unstructured to support good metaproperties for reasoning). I think I even said something to that effect, that it's not the paradigm which matters, but rather the existence of nice properties, or effectively simple semantics, as you said. But C is not such a language. --- Frank Atanassow, Information & Computing Sciences, Utrecht University Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791