Artlav wrote:
Totally agree. I miss them quite often, and my own compiler is not up to speed yet...
You're writing a Pascal compiler? Nice.
Quote:
Kevin wrote:
arrays need to be declared with their size instead of deriving it from the initialiser list
+1
To be fair, though, that would probably the kind of syntax extension that the FPC developers would be likely to accept for the native FPC modes if someone provided a patch.
Quote:
Kevin wrote:
The other one is that the compiler isn't really meant for making changes to or even writing your own system unit. If a compilerproc is missing or has the wrong interface, you usually get a fatal internal error with a number and no useful message. Next thing is grepping the compiler source for the number and checking what was really missing. That's not quite how I'd like the error handling to be.
Hm? Never had that problem.
Won't it just fail to compile with "fpc_so_and_so not found" error?
Maybe they actually improved it? I haven't updated my cross compiler from 2.4.x yet.
onlyonemac wrote:
Funny how everyone missed my new big point of the functions/procedures thing in Pascal.
Because it's actually a minor detail. In C, you replace int with void; in Pascal, you replace function with procedure. There needs to be a way to say that there is no return value and I wouldn't call one or the other inherently better.
C avoids the procedure keyword, but introduces a void type instead, which is a rather strange type and comes with more inconsistencies. First of all, most people don't even think you can declare void variables at all (and in fact some got mad at me and told me it doesn't make any sense when I said that "extern const void" is the correct type for a symboll declared in the linker script). That's not quite correct, but there is no way to
define a void variable or to have a void literal. This results in special syntax for void functions: Because you'll have a hard time finding anything void that you could return, "return" changes its syntax to work without a return value. And at the end of the function, it can even be left out. If this isn't inconsistent, what would be? (It's convenient, though, so I don't mind...)
You also have functions that are declared to take a void argument (which is the only way to declare a function without arguments), but then they work without being passed anything. In fact, it's even an error if you're bold enough to take the prototype literal and pass something "extern const void"!
Quote:
Another thing that results from this, too, is that in C the return value of a function can be dumped, whereas in Pascal a "function" is required to have somewhere to return its value
For all I know, this is not true, at least not in modern Pascal dialects.
onlyonemac wrote:
Yeah but C has been kept up to date. Pascal has had a few attempts at being updated, none of which really flow on from the original language in the same way that C has been slowly built up and had new features integrated in an elegant way.
Actually, to me modern Pascal dialects like ObjFPC fit very nicely into the original language. C appears to have had the larger changes, where even basic parts of the syntax have been deprecated (but are still supported by current compilers): Think of K&R style function declarations, including functions with no specified argument list and/or return type, implicit function declarations...
Artlav wrote:
The only difference i see is that in C the return statement is a result+exit combined, while in pascal it's two separate pieces.
Actually, FPC gives you the choice. It supports the short exit(0); syntax, which I use most times. But there are still cases, as you mention, where the old Pascal syntax is more convenient and I'm happy to use it in those cases.