@Jamie,
@Marco,
Thank you for the alternatives you provided/mentioned.
@Handoko
Many users from other languages found Pascal is great and they want to use it seriously. But they already have written many codes in their previous language. If they can't port their old codes to Pascal, it may become a barrier for them to use Pascal.
Exactly!. Thank you for stating the obvious which seems to be not quite obvious to some.
I read the thread and saw many suggestions for this issue. Sorry, but it looks ugly to me. I love the simple and clean syntax of Pascal.
Pascal's clean syntax is one of its nicest features. There is usually a clean/Pascal way of implementing a feature found in another language. A little pondering usually helps get there. What's important is the desire and dedication to implement it nicely, that's what will make a difference.
But think the other side, if Pascal can be easily to port from other languages, it will be a great advantage.
Not only a great advantage for the Pascal language but, also for those who use it.
@SymbolicFrank
If you really want to program in Pascal like in C, use pointers. Don't rape the language.
Not only is that rather dramatic and over the top, the construction "<vartype> <array[]>" is in C, precisely to be able to obtain a pointer to the desired location within the struct without having to declare a space-consuming field to obtain it.
C and C++ also have lots of exceptions for many things. But it was popular because it was short and cryptic. It looked like a magic formula, for the uninitiated. Very macho.
I believe there is some [added word] truth to that but, the reason some people use C is because, whether cryptically or cleanly, there is usually a way to tell the compiler what you want and the compiler will usually generate decent code for it. That is a _big_ advantage. In the case of Windows specifically, the API is spec-ed in C. That means that, so far, the only way to get access to the full API definition is by using C/C++. Sometimes just that is enough to use C/C++ instead of Pascal/FPC. When one is writing a program, the objective is to write the program, not to have to translate function headers and structs from C to Pascal - which in most cases is fairly quick but sometimes the Pascal translation is something that had to be shoe-horned because the language lacks some type description facilities.
The two things C and C++ have inherited form this, are a fascination with speed and that it is really easy to fuck up. It's much harder to do it right.
There is definitely some truth to that but, it's got its pros and cons. A well optimized program that is snappy is often a pleasure to use (provided it's not riddled with bugs as a result of some ill-conceived optimizations.)
Correctness is not a requirement of the language.
You're right. Correctness is a requirement of the _programmer_. That said, it is true that C offers a very limited amount of help in that area. That's one of the areas they _greatly_ improved in C++. Type checking in C++ is at least as good as in Pascal.
And you guys want to add the worst things from C to Pascal, simply because C can do that. You want less restrictions, because it allows macho programming. And make it much easier to fuck up.
Not only that isn't the case, it is completely over the top. Adding simple things like a zero-size field to use as a reference in a struct/record is not unclean in any way. On the contrary, having that results in code that is much cleaner than the un-intuitive pointer manipulation you have to do when the feature is not available.
The bottom line is this: producing correct programs is the responsibility of the programmer,
not the compiler's. A compiler should provide as many clean constructs as possible to enable the programmer to describe data succinctly and accurately.
The compiler should help find errors, not get in the way of programming.
While C and C++ (especially Microsoft and LLVM) try to make C and C++ much, much stricter, to prevent all that. They would rip all that out in an instant, if it wasn't for backward compatibility.
They are making it stricter for the compiler to be able to flag potential programming errors but, they are _not_ restricting what the compiler can do. On the contrary, constructs such as "array[]" are fairly new and they are a much cleaner way to provide an address to access the field than using "array[ANYSIZE]".
General comment:
From the posts I've read in the forum, I get the impression there are a significant number of Pascal programmers averse to using pointers and variable size structures. That seems to have been encouraged by the compiler's effort to hide pointer dereferences. Makes programming "cushy" but, ultimately, it's not a good thing because the "programmer" isn't aware of what is _really_ going on.
A lot of programs can be written without using pointers and/or variable sized structures but, there are programs where _not_ using pointers and/or variable sized structures results in code that is more complicated, usually very wasteful of memory and just as often far from performing as well as they could. For the user of such a program, that results in an experience that usually leaves something to be desired.
Lastly ...
It would be nice if FPC supported the "array[]" construction.