Prof A Olowofoyeku (The African Chief) wrote:
Is the following code C or not? All versions of Bourne compatible shells can run it and produce the expected output. If they do, then they are C compilers (or maybe C interpreters). ;-)
#include <stdio.h> #define echo int main () { printf ( #define exit "\n"); return 0; } echo "Hello, world!" exit
Just betrays the C origins of the Bourne and similar shells.
Actually, it doesn't. Though they have some similarities, I didn't make use of them here. The trick is that a leading `#' is a comment in sh, but a preprocessor directive in C, so I could define some macros etc. which contain most of the C code, which is simply ignored by sh.
I hope these explanations make the example clearer. It does not reveal any substantial similarity of sh and C. I didn't manage to produce a file that would be both valid Pascal and C, but that's just "coincidence". Even if I would, that wouldn't mean anything, in particular it would not prove that every Pascal compiler is a limited C compiler and vice versa.
Single programs don't mean anything. That's why the standard doesn't list a few hundred example programs and says, a compiler which compiles those is a confirming Pascal compiler. Instead, it describes the syntax and semantics very explicitly and detailed (though not always very clearly WRT to the language used ;-).
(That might be a question of licensing, but if the current C++ compiler can compile Pascal, every user of that compiler effectively has a Pascal compiler now, so it wouldn't make much of a difference.)
I haven't tried to produce .exes with the emasculated versions of Delphi binaries, but I suspect that it wouldn't work, and that you can only compile units with them. So they are not of much use other than to produce .DCUs for the C++ compiler to use.
OK, so I conclude (again ;-) that the actual C++ compiler does not have to compile Pascal code.
BTW, interesting that you bring up this point in this context. What if the users want to fix a bug in the compiler? Does Borland supply the source code of the compiler then?
Nope. Why would they?
Of course, I didn't expect otherwise. But since you made a point that programmers should be able to fix bugs in the VCL -- if they're just a little less lucky, the bug is in the compiler, and they can't fix it, either. So this argument is rather weak.
[...]
I am not sure that there is a consensus on that point (or that there can be). Delphi code seems very clear and eminently readable to me (and no doubt to many others). The extensions do not make the code any less clear or readable to me.
Honestly, I'm quite tired of hearing these general and unspecific claims.
Nothing general or unspecific about that I said! I merely articulated my experience when examining source code.
Sorry, but just saying "my experience is so" is general and unspecific. I can believe you or not, but there's nothing in the statement that enables me to decide for myself whether it's true, or whether any existing feature might be suitable just as well (or even better).
Why don't you present some actual code which is clearer or better understandable due to these controversial features like overloading, `()' etc.?
I never said that it was clearer or better understandable. I said "The extensions do not make the code any less clear or readable to me".
"i := foo();" is just as clear and readable to me as "i := foo;"
"Just as clear" doesn't exactly justify messing with the syntax. It should be substantially clearer/powerful/readable/...
Some might say that it is more readable (I express no opinion on that point - but Waldek indirectly alluded to this) because, in the former, it is clear that "foo()" is a function/method - but in the latter, "foo" might be a variable/field, or a function/method.
That might be a point, but this difference has already been blurred by properties AFAIUI.
(I mean real understandability -- it might be easier at first sight to read some code where "everything" is called, say, `Read' -- one will think, oh yeah, that's reading something, very clear. But if you really want to understand what's going on, you'll have to figure out which routine/method is called in which case, and I don't see how overloading will help there.
I can. If you have:
Procedure Read (x:string);overload; Procedure Read (x, y:integer);overload; Procedure Read (x:string; y:integer; z:Double);overload;
It would be quite obvious which of these is being called, when the parameters passed are examined.
That's a rather easy example. It gets more confusing if you have the same number of arguments, but different types.
Frank