Prof A Olowofoyeku (The African Chief) wrote:
To say it again, I think it's quite impertinent to create a mutilated form of the language and claim that the result is the real language.
I don't think that Borland ever claimed that their Pascal was "the" Pascal.
As I said in the part you deleted, "I'm not sure if Borland actually made this claim". So maybe only (many of) their users are to blame (including myself, some years ago).
Is the following code "Pascal" or not?
program foo (input, output); type bar = record bar1 : integer; bar2 : char; end; type mybar = (here, there, where); Var b1 : mybar; b2 : bar; begin with b2 do begin bar1 := 10; bar2 := 'C'; {do whatever} end; end.
(Actually, it isn't according to ISO 7185, since there must be only one type declaration part, but it's easy to resolve, of course. And it's allowed in EP.)
All versions of Delphi and BP compile it. If they do, then they are "Pascal" compilers.
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
(Hint: The code is both valid C and sh syntax, using some tricks. ;-)
Is this phrase Spanish? "Me gustaria tomar flan". Yes, it is. Of course it isn't all the Spanish that exists, but no-one can say that it is not Spanish because it doesn't contain subjunctives or the whole of the Spanish vocabulary.
Your analogy has (at least) two flaws. First, the difference between natural and formal languages that I've already mentioned. Secondly, the difference between one example and whole language. The fact that BP and Delphi can compile some valid Pascal programs does not mean that they're a complete Pascal compilers (as the humorous example above hopefully shows; likewise, I wouldn't claim that I speak Spanish if I understood that sentence).
Actually, the standard makes quite details provisions what a conforming compiler ("processor") must and may do. Nobody denies that BP fails to satisfy some of the requirements.
: This International Standard specifies the semantics and syntax of : the computer programming language Pascal by specifying requirements : for a processor and for a conforming program.
So, again, you can compile some conforming programs, but BP is not a conforming "processor". (BTW, GPC isn't either, but we do acknowledge the deviations as bugs and don't try to talk them away.)
Therefore I conclude that BP and Delphi are "Pascal", albeit incomplete implementations with extensions.
I might agree to this. However, it's a very wide description. For sufficiently large values of incomplete and sufficiently many extensions, every C compiler is an incomplete implementation of Pascal with extensions. ;-)
If you want to have a single VCL and RAD tool, written in Pascal, and you don't want to reinvent it again and again for your C++ compiler, you have no option but to allow C++ to compile Pascal.
Yes, you have. Simply allow C++ to access Pascal routines (same as most Pascal compilers can call routines written in other languages). There's no need for the C++ compiler to compile the Pascal code.
There is a need if you do not want to restrict your C++ users to precompiled Pascal libraries. What if they want to change something in the VCL (or 3rd party) sources, to fix a bug, or for whatever other reason? This would be impossible if they couldn't then recompile the sources.
Then Borland should simply ship the Pascal compiler together with the C++ compiler. (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 still hold that it's not necessary to mix the languages for any such reason. (And again, that's quite exactly what GNU does, so I think I have some experience in this area ...)
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?
Yes, it is a bit silly. I guess the closest thing to it that I can think of is varargs in C. This is their way of supporting variable numbers (and types) of parameters. It is controversial whether that should ever be supported. But once you decide to support it, you are already extending the language - and I guess it's then up to you how you do it.
Anything they do in their compiler is up to them, but we may still discuss whether or not it's done well. Extending the syntax is always a rather heavy "cost" and should be well justified, especially when there's an easy alternative available. In this case the alternative would be a protected (EP) or const (BP), conformant (SP) or open (BP) array of `Void'. So the only thing new would be a `Void' type, but that's merely a new predefined identifier (which, of course, should be redefinable, so it won't disturbe anyone who doesn't want to use it in this meaning, and would allow parsing even when one doesn't know what it means), and maybe some predefined routines to work with the `Void' type (inquire the real type and retrieve the values etc.) i.e.
protected array [a .. b: Integer] of Void { EP }
or
const array of Void { BP }
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. Why don't you present some actual code which is clearer or better understandable due to these controversial features like overloading, `()' etc.? (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. Making the easy things easier and the difficult things more difficult doesn't seem like a good strategy on the whole.)
Even if I don't see the point of them, people don't normally add pointless features to their software, even if others can't see what that point is.
I could say a lot about this, but it would really get off-topic ...
Frank