Pascal used var parameters rather than pointers into the stack and supported nested subroutines with lexical scope, limiting them to being passed as downward funargs to ensure safety, and it barely missed requiring tag checks on variant record access (an omission Wirth bitterly lamented). Pascal had pointers, but they were strictly for heap-allocated objects, not var parameters or array iteration. In standard Pascal, array size was part of the array type, so you couldn't write functions that operated on arrays of unknown size, because bounds checking of array accesses would have otherwise required passing an additional length word.
That's why the string type in TeX is an index into a humongous string pool array.
I think this illustrates how the philosophy of Pascal differed from that of C.
These are indeed the places where Apple extended their version of Pascal. C-style calling convention support, pointer arithmetic, much better I/O, and a host of things I can't remember. Suffice to say that when I started working at Apple (towards the end of the Pascal era) I was pretty comfortable, even though I'd been doing mostly C for a long time. This was definitely not the language we had to use in college.
(No tagged unions, though. Systems guys are allergic to 'em, apparently).
Apple also added object-oriented features, but I don't count those as addressing anything borken or awkward in the base language.
Well, in the base language you couldn't store function pointers in variables or record fields, since they might refer to nested subroutines that included a context pointer to their parent subroutine stack frame, and invoking them after it had returned would be catastrophic. This “downward funargs restriction” made OO-style programming in standard Pascal very difficult in a way that it isn't in standard C. So I think the OO features, too, aimed at a weakness of the base language—but I admit I never looked at Apple's version.
These are not closures, they're still strictly nested and on the native stack, so the usual crashes happen if you execute a callback to something that has gone out of scope.
Remind me to tell you about "Fork Queues", a solution we had on the Newton for dealing with multiple entities that all wanted to have the main event loop (of which you could really only ever have one, but we cheated).
