bob wrote:Carey wrote:bob wrote:Tord Romstad wrote:Carey wrote:Show me one perfect computer programming language....
They all have problems. C just happens to have fewer than most, but since it's more widely used, the problems are more visible.
I dislike C intensely, but currently there is no other language which offer the same amount of performance and portability across a wide range of platforms. Technically,
BitC should be able to fill C's niche, and to programmers like me, it would be vastly more comfortable to work with. But of course, it is very unlikely to ever be widely implemented.
And you have to consider C's origins. It was not fully specified in the K&R years. If you wanted to know what something did, you read the book and looked at a few existing compilers.
It was years later when the first standard was done.
Compare that to Fortran or Ada, where the standard was done first and then the compilers were written.
Is that a bad thing?
Or Pascal. The standard is so restrictive and limited you can't write real world programs with it. There is no such thing as portability with it.
Somehow we don't agree on the definition of "portability" then. Pascal is so tightly defined I have _never_ seen a pascal program that compiles and runs on machine X that will not compile and run on machine Y. In fact, the p-code was 100% compatible across platforms, the predecessor of the Java byte-code approach...
Sure, you can do portable toy programs. Like they used to teach in college.
I used to teach a course on designing and writing an assembler. We wrote them in Pascal. I also taught a compiler course and we wrote that compiler in Pascal. It was designed as an academic language that was tightly typed to prevent the kinds of errors people run into with C. As with anything, the more tightly it is constrained, the less useful it becomes. But you could write useful stuff in Pascal...
Everybody says it was designed to be just an academic language, but apparently Wirth disagrees.
He claims he wrote it for real use. And that he expected everybody to write their own libraries.
With the various extensions (UCSD, TurboPascal, etc.) you could indeed write some very useful programs. No question of that.
But not with ISO Pascal. It's such a restrictive and limited standard there's no good reason for it to exist. It's an example of a poor standard.
But beyond that... No, you can't do portable programs. The language was so limited you couldn't open files, you couldn't write data, you had no idea what size the data types were, nothing.
You were not using Pascal then. Opening files was never a problem for any Pascal compiler I used (we started with the UCSD version but most vendors supplied them as well). You might not be able to write portable programs that manipulated bits and such, but many programs don't depend on that and portability for them was perfect.
BINGO!!
UCSD & Turbo Pascal were totally unlike real, official, standard pascal.
Also, an official Pascal standard didn't come about until the early 80s. Long after UCSD existed and even TurboPascal was starting to fade. (They started in 78, and I think it took them 5 years.)
I had a compiler in the early 80s that was nearly standard. It was standard, except for some extensions that were explicitly stated as such and carefully documented, so you wouldn't mistake them as official ISO Pascal.
I also read the specs way back then. (Admittedly I've forgotten most of it since then, since I avoid ISO pascal.)
Trust me, the official ISO Pascal was very different from the Pascal that most people used and liked.
ISO Pascal wasn't p-coded or anything like that. (The original compiler was done on a CDC 6000 series. Same as Slate & Atkin's CHESS 0.5, which is one of the reasons so many people thought Chess 0.5 was an experiment to see if Pascal was suitable for the next generation Chess 5.0 line, which never happened but instead became Slate's NuChess.)
The very popular P4 example implementation of Pascal used p-code (as did P2, which was the basis for UCSD Pascal), but the Pascal standard itself doesn't do p-code.
Very few compilers were ISO Pascal. By that time, Pascal stopped being popular, of course, but they still had to do extensions for portability with TurboPascal or UCSD, etc.
If they had taken UCSD or TurboPascal and made that into an official standard, I think nearly everybody would have been happy. But they didn't and everybody complained. It was so different from what they were used to that nobody wanted it.
Anyway, the point is, ISO Pascal is very different from UCSD or TurboPascal or Vax Pascal, etc.
ISO Pascal is so limited it is essentially useless.
You could end up with REAL's of 4 bytes on one system, 6 bytes on another and 8 bytes on another.
INTEGER could be 4 bytes or 2 bytes.
There was no I/O beyond basic read & write. No files, no random access to those files.
Programs were limited to a single source file. There was no portable way to include another file or link with another module.
To do any sort of realistic program required non-portable stuff.
That is what I was saying.
Plus, nobody really wants to write to official Pascal specs because the type checking is so restrictive you end up jumping through hoops to perform even minor programs.
Just look at Chess 0.5 to see some of the stuff they had to go through to follow strict Pascal type checking. Perhaps a quarter of the program is actually fighting with the type checking.
I once had an official compiler with very minimal extensions. I was able to get a mailbox chess program up and running on it, but it wasn't pretty. And it certainly was minimal. Screen & basic keyboard I/O only.
Perhaps the official standard is restrictive and limited, but the Delphi dialect seems to have become a de facto standard, and is far less restrictive and limited. FreePascal, which claims to support the Delphi dialect, is available on all major platforms.
Or Forth. Which in spite of the standard is still pretty much a language defined as 'implementation defined.'
Yeah. But because all Forth programmers seem to make their own implementation anyway, I don't think anyone cares.
Or C++ team who took sadistic pleasure in massive invention and radical changes at every meeting.
Ugh.
Tord
BTW, the standard for fortran was _not_ done before the compilers were written.
I know. I accidently gave that impression. My fault.
Fortran goes back so far there were no standards beyond the documentation for the compiler itself.
Later standards were done to address changes that were deemed necessary (pointers, etc) and then new compilers were written to meet those standards, but Fortran evolved over many years, and until fortran 77, there was no uniform agreement on many things and vendors were adding things right and left (again pointers comes to mind but there were other things). The standards were written so that new features would be compatible across all compliant compilers. Why could the ANSI C committee not do that same thing? Obviously they could have, but they didn't, for reasons I'll never grasp...
They couldn't for C89. Their goal was different and their charter required them to honor that.
They did for C99. But they were still concerned about backward portability to C89. They couldn't just invent a new language that was totally incompatable.
That makes no sense to me. signed char / unsigned char is already incompatible. What good is a standard that isn't a standard???
Like you said up above about Pascal... The more tightly constrained it is, the less useful it becomes.
Every standard has some ambiguity. Some 'implementation defined' situations.
By the time of C99 they were trying to move people away from using the ambigious data types.
You never knew what size a char or short or int was anyway. (Remember the hassles of going from 16 bit DOS to 32 bits?) A char could be 8 or 16 bits. A short might be 16 or 32. An int could be 16 or 32 or 36 or 64. Or everything could be 32 bits.
Plus you had to deal with wide chars. And multibyte chars that could be variable length.
So 'char' was already a very vague type that had limited usefuleness for portability. (If you were using some hardware that existed at the time, even copying a signed char from one location to another could actually change its bit pattern! That's why the C standard only guarantees unsigned char for copying all the bits. Not signed char or signed int or unsigned int or any other type.)
If you are an english speaking person who works only with ASCII and work only with common hardware, it wasn't a problem. But if you didn't fit into that category, then there were lots of problems. And people were complaining.
Because C was on so many different types of hardware and in so many different languages and so many different character sets, there was no way to work all those in and still maintain backwards compatability.
And backwards compatability is one thing the C standards committee was absolutely dedicated to. They did not want to create a brand new language that can't handle the old language and existing programs.
(They did think about adding some brand new features to C99. For example, some basic classes, done in a more natural way than C++ was doing. But it would have caused too many complications, added some backward incompatability, and taken longer than what they were targeted for. And they felt it would probably end up being features that few would use because they would probably just use C++ instead.)
The point is, even if back in C89 they had defined char to be signed or unsigned, and accepted that it would break lots of programs (and there were people who wished they had), by the time of C99 it was obvious to them and the international programmers that the concept itself of 'char' being both a character and a tiny int was broken.
There was no longer a relationship between a character and a tiny integer. And people were complaining.
It was a merged data type that should never have existed. But K&R C did it, so the damage was done.
If K&R had just done 'char' and 'byte' then all of it would have been avoided. But they didn't.
The best the standard committee could come up with, and encourage portability across a wide range of systems and languages, was do the new data types such as uint8_t, wchar_t and so on.
To specify the language in those non-ambigous data types and try to encourage the users not to use those unknown, unguaranteed types.
It's not a perfect solution, no. And they didn't do it in a perfect way, either.
But with C being on so many platforms (common & uncommon) in so many languages and character sets, simply making 'char' as signed by default would solved very little and complicated things just as much.
It might have made things easier for you as an individual, but it would have caused at least as many problems for many other people. And the bigger problem would have still existed.
The reality is you should no longer be using 'char' for anything but characters. You don't know for sure if it's going to be 8 bits or 16 bits. (Although in the US you can be pretty sure it's going to be 8 bits.)
If you need a small integer, then you should use one of the data types that are guaranteed to be what you expect, regardless of the platform or the speaking language or the character set being used.
You're a bright guy. It's definetly obvious to you there is a portability problem there.
The solution is simple. Don't use 'char' as a tiny integer. Beyond the signness, you just don't know for sure what you'll be getting if somebody takes your program and compiles it some system you don't use.
If you do want to use char as a tiny integer, the signess is easily solved. Explicitly say whether its signed or unsigned. typedef them as UChar and SChar, for example. Or UByte and SByte. Or just go ahead and use uint8_t and int8_t which C99 gives.
Way up above, talking about Pascal, you said
...that was tightly typed to prevent the kinds of errors people run into with C.
Using a 'char' as a tiny integer is one of those kinds of situations.
It's a data type trying to do two different jobs and it no longer works well.
I am not now saying, nor have I ever said, that C89 & C99 were pefect. They aren't. They have problems. (If anybody thinks I have implied they are perfect, I appologize.)
But I do say that the standards committee put a lot of effort into doing the right thing and maintaining portability and backwards portability. If they did something, there was probably a very good reason and not some arbitrary decision.
One of their more famous examples of something not thought out carefully was 'noalias'. (Proposed I think by the Cray guys, but don't hold me to that.) There were some subtle issues they had overlooked and Ritchie himself came to the next meeting and explained it. When they realized it, they voted right then and there to remove it, and then proceeded much more carefully with 'restrict'.
Before they made a decision or a change or an addition, they did consider the effects it would have. Whether it would actually solve anything or not and what kind of side effects it would have.
They deliberately chose not to make the default char either signed or unsigned. Both times.
I think this discussion is getting off Chess quite a bit. And it's getting a bit academic.
If you want to disagree with me, that's fine. If you want to agree, then that's okay too. (If you want to, just do a reply message that says 'I disagree!". That way you can get the last word.)
I'm willing to let it drop, unless somebody just really enjoys the subject and wants to keep talking about it.