I joined Apple in 1987, about the time they started ditching Pascal in favor of C. C++ (in the form of CFront) was just starting to be a thing.
Apple's Pascal had been extended to the point where there were few true differences between it and C, other than
- strings with busted semantics (size being part of the type being a huge mistake, leading to a proliferation of types like Str255, Str32, Str31, Str64, etc). I should add that C's strings were semantically busted, too, and in more dangerous ways. No way to win :-)
- nested procedures (not terribly useful in practice, IMHO)
- an object syntax, used for Object Pascal and MacApp (a complete, though large and somewhat slow app framework).
- some miscellany, like enums and modules
Apple extended Pascal pretty extensively, adding pointer arithmetic, address-of, variant functions calls, and a bunch of things I've forgotten. I could write some Pascal, then write some C, and squint and they'd look pretty much the same. Most people shrugged and wrote new code C if they were able, and then moved to C++ when CFront became usable.
I think I misliked Pascal's nested procedures because they weren't true lambdas; once the outer procedure returned, the inner procs were no longer callable (just one contiguous stack, right?). Early-on, using C++ lambdas, I found myself making the same mistake in a design for some asynchronous completion stuff. Embarrassing; C++ and Pascal are not JavaScript/Lisp/Scheme/Smalltalk :-)
You can assign a c++ lambda into an object for later use, you just have to be careful about capture by reference and capturing pointer types... But the capture using the copy constructor is handy here, eg. you can copy a shared_ptr and get reference counted captures...
It's funny in this way how c++ lambdas lead to very c++ specific issues and uniquely c++-ish solutions. I think the wackiness of the closure capture mechanism is the best example of this I can think of.
I discovered with C and C++ compilers, if an extension was added that was not in the Standard, nobody would use it - not even the people who requested the extension. It wasn't like the Pascal community, where nobody would use the compiler unless it had a boatload of extensions :-)
I think you're onto something (about C extensions). There was a time, before clang became default on osx, when Apple deprecated nested functions (and perhaps others) in their version of gcc, and afaik no one complained. So I may well be one of the very few. Oh well.
I've done that, too. It's clumsy and only does half the job (doesn't provide access to locals). At some point one just gets tired of the workarounds :-)
It's probably a bit late for this reply, but... Another clumsy workaround is to use operator(). Again, standard C++ and this one has access to local variables:
int g()
{
int x, y;
struct local {
int & a_;
int & b_;
local(int & a, int & b) : a_(a), b_(b) {}
int operator()()
{
return a_ + b_;
}
} nested(x, y);
x = 99; y = 1;
return nested();
}
assert(g() == 100);
Nested functions are good if you have no alternative. If you use them as lambdas or a means of code folding, (both of which don't exist in older IDEs and compilers) you will have to keep jumping around in code in order to follow the logic. That is a very tiring thing to do, especially if you just switched jobs.
A lot of the goto's were used to use a common sequence of code followed by a return. With nested functions, the nested function contains the common sequence of code, and you just:
T common() { ...common sequence of code... }
...
return common();
instead of:
goto Lcommon;
...
Lcommon:
... common sequence of code ...
return result;
Got it now, thanks. But, this (the "return common();") could be done even if the function "common" was not nested within the current function, but defined outside of it, right? So what is the benefit of defining "common" as a nested function? Is it because it then has access to, and can use, variables defined in the outer function?
Yes, you can do it that way. But then you'll need a "context pointer" to pass references to the locals it'll need, and the function will need to be located "someplace else", meaning it is not encapsulated.
I've done that for years with C and C++. Nested functions are so much nicer and clearer.
Or just have first class functions, and prototype based inheritance. Way more flexible and powerful than class based inheritance. See JavaScript 5 as an example, ask Crockford.
Speaking of few differences from C and busted string semantics: my least favorite thing about Pascal is that strings and some types are 1-indexed, but dynamic arrays are 0-indexed.
And an annoying difference between the desktop and mobile compilers for Delphi is that on desktop strings are 1-indexed as they've always been but on mobile strings are 0-indexed:
The Low and High compiler intrinsics make array indexes easy to deal with. You don't need to care about the indexing to iterate over the array. You just go from Low(array) to High(array):
I don't remember if Apple Pascal had those intrinsics or not. But I never saw any code that used them, and I read most of the Pascal code base for MPW and a bunch for the OS.
Yes, this is not a limitation in Free Pascal or Delphi. The ShortString type still exists and is limited to 255 bytes. But the AnsiString, WideString, and UnicodeString types are variable length and can be up to 2 gigabytes:
strings with busted semantics (size being part of the type being a huge mistake, leading to a proliferation of types like Str255, Str32, Str31, Str64, etc). I should add that C's strings were semantically busted, too, and in more dangerous ways. No way to win :-)
I think trading some programmer inconvenience for a world with no buffer overruns would have been a good thing, in retrospect!
Apple's Pascal had been extended to the point where there were few true differences between it and C, other than
- strings with busted semantics (size being part of the type being a huge mistake, leading to a proliferation of types like Str255, Str32, Str31, Str64, etc). I should add that C's strings were semantically busted, too, and in more dangerous ways. No way to win :-)
- nested procedures (not terribly useful in practice, IMHO)
- an object syntax, used for Object Pascal and MacApp (a complete, though large and somewhat slow app framework).
- some miscellany, like enums and modules
Apple extended Pascal pretty extensively, adding pointer arithmetic, address-of, variant functions calls, and a bunch of things I've forgotten. I could write some Pascal, then write some C, and squint and they'd look pretty much the same. Most people shrugged and wrote new code C if they were able, and then moved to C++ when CFront became usable.