GNU Pascal Compiler Released For Mac OS X 77
MacDaffy writes "Kudos to Adriaan Van Os: He has produced a 'second prerelease' of the GNU Pascal compiler for Mac OS X. Work actively proceeds on porting the Carbon Pascal Interfaces for use with it (longtime Macintosh Pascal guru Peter N Lewis has already gotten a great start on this). Thanks to Adriaan, Peter, and Bill Catambay of Pascal Central for helping take Pascal on Macintosh into the future."
Waiting for carbon bindings (Score:3, Informative)
I guess I'm not the only one, and there probably is a fair amount of old pascal code that is waiting to be ported to OS X. If the carbon bindings are ported, recompiling should be reasonably easy.
Great ... (Score:2, Informative)
Seriously, I started out programming for the Classic Mac OS in Pascal ages ago, but haven't touched it recently; with all the C, Java, etc. tools now available for OS X Pascal has been, quite correctly, left by the wayside. It feels kind of archaic to me now, and I gather I'm not alone
-- shayborg
Re:What is really wrong with it? (Score:5, Informative)
Some of it is simply fashion: as C grew in popularity, it simply overtook Pascal in the new APIs that were developed. Once Pascal interfaces to the Mac OS became second-class citizens, there was no reason to favor it.
Another part of it is that Pascal was originally a teaching language, meant to indoctrinate structured programming. It deliberately tries to hide machine or OS-level reality with an idealized abstraction. It was not meant as a flexible all-purpose language like C. You couldn't write an OS kernel in Pascal very easily. One specific area in which it lacks flexibility is type conversion. For pointer or scalar (enum & integer) types, it really wants you to pick one type and stick with it. Good for enforcing discipline on software engineering students learning to design structured data types, poor for hackers who need to deal with the not-so-disciplined reality.
Another area where it lacks is file I/O. The standard doesn't really define byte-level results of its file operations, so reading/writing files compatible with other languages/API's depends on vendor extensions, which aren't uniform.
Similarly for structure layout. Although it isn't 100% defined, you can usually convince any C compiler on a given platform to agree with any particular arrangment of bytes in a structure. It's much harder with Pascal. This means that no matter what your OS, C code can be written mostly independent of compiler vendor, or at least with the nastiness hidden in header files.
Pascal also has a pretty inflexible (perhaps a bit clumsy) structure for writing your own libraries (units). In C implementations, you write a bunch of routines, a header file for users to #include, and make a
There are also a couple of omissions. I believe many implementations did not allow functions to return structure types. That's what drove me to C from Pascal many years ago. I believe arbitrary length arrays are also a bit clumsy to work with (not like C where you can have null-terminated arrays and use pointer arithmetic to navigate). Polymorphic types & pointers are clumsier in Pascal (no void* to ignore the differences when you want to.)
In general, Pascal works fine if you are writing a single application that requires only interfaces & libraries that your compiler vendor knew about. TeX by Knuth is an example. His programs (at least of that era) are monoliths, not collections of libraries and interfaces. You need to tweak a few routines to work with a particular vendor/platform, and that's only because Knuth very consciously made it that way.
Once you start working with libraries from multiple sources, the Pascal model begins to strain.
The Pascal folks would say that "Extended Pascal" plus OS-specific extensions in most compilers allow you to overcome all of these. But the extensions only happened after C began spreading like a virus, helped by its exposing all the weaknesses in Pascals that lacked full extensions.