peter@ficc.ferranti.com (Peter da Silva) (11/20/90)
I've been skipping most of the articles in this thread, but the following sentence brings up an interesting thought... In article <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> gl8f@astsun9.astro.virginia.edu (Greg Lindahl) writes: > If you study this example, you'll see ways in which C can be changed > to make it more useful for a wider class of problems. My initial reaction to most of the problems with C that people bring up is "yep, probably right... but how do you fix the language without either changing it into something almost, but not quite, entirely unlike C or by making the coder's job immensely harder?". C is not going to go away any time soon. Like Fortran, it's widely available and there is a great deal of uniformity among the runtime libraries thanks to the relatively clean UNIX programmer interface they're modelled on. If you're writing a program you want to run on more than one platform, and it's not an engineering/science support program, about the only choice is C (or, maybe one day real soon, C++: but coding in C++ is like coding in Ratfor). How would you fix C without breaking a lot of C code? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mjs@hpfcso.HP.COM (Marc Sabatella) (11/21/90)
>How would you fix C without breaking a lot of C code?
One "solution" would just be to say "switch to C++", but I assume you mean
something less dramatic.
At the risk of fanning the old comp.lang.c wars, add "noalias".
Whether or not "alias" would be more natural is moot if we don't want to break
existing code. Similarly, the simple change of having array parameter
declarations recognized as entities which cannot be aliased to other array
parameters would break existing code.
Allow portable constructs (non-portable #pragma's aren't good enough) to
declare when functions have no side effects - or what I think is an equivalent
statement, that the function is purely number-theoretic over its arguments and
return value. Compilers that can make this determination themselves get bonus
points.
This would make a very good start.thomasm@llama.Ingres.COM (Tom Markson) (11/21/90)
In article <QG279:@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I've been skipping most of the articles in this thread, but the following >sentence brings up an interesting thought... > >In article <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> gl8f@astsun9.astro.virginia.edu (Greg Lindahl) writes: >> If you study this example, you'll see ways in which C can be changed >> to make it more useful for a wider class of problems. > >My initial reaction to most of the problems with C that people bring up >is "yep, probably right... but how do you fix the language without either >changing it into something almost, but not quite, entirely unlike C or by >making the coder's job immensely harder?". C is great. We all love C. But a time comes when you say "Modifying C is not the answer". If one modifies C, trivial changes may be made without breaking a lot of code (like adding a raise to the power operator). But if you want to do something more major (like adding exceptions or something equally major), your only two solutons are to: 1. add it in a way not to break everything else, 2. hack C so that the change will break existing code. In the latter case, you lose the advantage of modifying C (Why modify C if what you end up with is no longer C?) And in the former case, if you attempt to slide a major construct into C in a way as to not break existing code, you will end up with a hacked up, ugly, and probably ineffective implementation of your construct. Languages must move on. If C had attempted to be 100% compatible with BCPL, it would not be as clear and powerful a language as it is. The real solution is to start over and design something you feel solves the problems you encounter or corrects percieved deficits with C. If there are things in C you like, take them. The nature of programming languages is that they borrow from each other. Tom Markson Unix Systems email: thomasm@llama.rtech.com Ingres Corp phone: 415-748-250
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (11/21/90)
In article <1990Nov20.220526.24202@ingres.Ingres.COM> thomasm@llama.Ingres.COM (Tom Markson) writes: >C is great. We all love C. But a time comes when you say "Modifying C >is not the answer". Well, if you avoid being overly general, what does C need to deal with this example of code that messes with arrays? foo( float *a, float *b, float *c, float *d, int n ) { int i; for( i = 0 ; i < n ; i++ ) { c[i] = a[i] + b[i]; d[i] = a[i] - b[i]; } Now, normal C has two big problems with this code: 1. Most programmers would do strength-reduction by hand and obscure what is going on. This makes the compiler's job much more difficult. 2. It's difficult to analyze and prove that the store to c[i] won't stomp on a[i] or b[i], so they have to be re-loaded for the second loops statement. This case is rather simple; most of the time the index values are more complex. What does C need? Well, if I could declare that a, b, c, and d were arrays of size n, the compiler would have all the info it needs to do a *simple* run-time check for aliasing, no matter how nasty the index expressions are. And it would optionally be able to insert bounds-checking, should I want it. Such a change wouldn't break existing code. However, to get the performance benefit, programmers would have to avoid obscuring arrays. In the good old days, you had to be obscure to be fast. In the brave new world, things are different. Of course, I'd also want true N-dimensional arrays and a stronger library. This is only a first step. The major question is: would you end up with a simple language at the end? I hope that the end product would be easier to optimize, but it would certainly be bigger than before. > The real solution >is to start over and design something you feel solves the problems you >encounter or corrects percieved deficits with C. I'm stuck using lots of machines, and it would be expensive for me to write compilers for all of them. Your real solution is great for research, but not so great if you're an end-user.
hp@vmars.tuwien.ac.at (Peter Holzer) (11/21/90)
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes: >What does C need? Well, if I could declare that a, b, c, and d were >arrays of size n, the compiler would have all the info it needs to do >a *simple* run-time check for aliasing, no matter how nasty the index >expressions are. Should that look like foo( float a[n], float b[n], float c[n], float d[n], int n ) ? Neat idea. Although it will promote the pointer/array confusion even further. It is already hard enough to explain to C-beginners why `int f (int * a)' is the same as `int f (int a [])' but `extern int * b' is not the same as `extern int b []'. IMHO argument rewriting should be abandoned in some future version of C (together with old-style declarations and definitions) > And it would optionally be able to insert >bounds-checking, should I want it. Some compilers (e.g. Saber C) do that even now. I suppose every pointer is really a tripel (address, lowest valid address, highest valid address) to them. >Of course, I'd also want true N-dimensional arrays In what sense are C arrays not true n-dimensional? >and a stronger >library. Me too. Especially file, process and exception handling is rather weak. I understand that the people working on the standard wanted to create the greatest common denominator, but there should at least be a set of optional functions defined for rather common actions as * changing the working directory, * executing another program, * disable specific exceptions (FP overflow comes to mind), * indexing files (IMHO one of the main reasons why COBOL is still successfull is the fact that it has STANDARDIZED indexed files). Apart from that many library functions do not quite what you want (eg. strncat) or are not consequent in their parameter ordering (The stdio family). >library. This is only a first step. The major question is: would you >end up with a simple language at the end? I hope that the end product >would be easier to optimize, but it would certainly be bigger than >before. There were K&R-C compilers that ran perfectly well in 64k Text and 64k Data+Stack. GCC already needs a few megabytes. >> The real solution >>is to start over and design something you feel solves the problems you >>encounter or corrects percieved deficits with C. >I'm stuck using lots of machines, and it would be expensive for me to >write compilers for all of them. Your real solution is great for >research, but not so great if you're an end-user. Extending C is not easy either. Whenever I write a C program people come running complaining that they cannot compile it. Most compilers called 'cc' are not C compilers nowadays, but compile the language that was called C 10 years ago. I do not expect non-conforming compilers to disappear for at least another 5 years (We will probably have the next standard by then so there won't be any conforming compilers again :-) -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
peter@ficc.ferranti.com (Peter da Silva) (11/22/90)
In article <1990Nov20.220526.24202@ingres.Ingres.COM> thomasm@llama.Ingres.COM (Tom Markson) writes: > C is great. We all love C. But a time comes when you say "Modifying C > is not the answer". Well, that's the point, isn't it. I tend to agree with you (and I'd use Modula-3 or Concurrent Euclid or whatever if I could get a good compiler with good runtime). But there are always people who want to fix C (hell, I'm one of them sometimes :->... mainly because I like the look of the language... it's purty... but not like that) and I'd like to find out what it is they want to do. Short of creating a new language! (that's one of the reasons I created alt.lang.cfutures in the first place) -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com