Comment by kabdib | Hacker News Reader

Comment by kabdib | Hacker News Reader

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 liked nested functions in Pascal, and put them in D. They turn out to be surprisingly useful:

1. Properly encapsulating their scope, as opposed to having static functions sit awkwardly somewhere else.

2. Factoring out common code within the function.

3. A lot of my need for goto statements vanished with nested functions.

4. Take the address of a nested function, and it serves as a lambda.

5. No need to create "Context" structs to pass local data to them.

6. They replace a lot of what C macros did.

7. They're inlineable, so are not costly.

I use them more and more as time goes by. It's a pity C doesn't have them, they'd fit nicely into the language.

Off-topic, but nested functions are one of my favorite gcc extensions.

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 :-)

They tried to fix that with ISO Extended Pascal, but by then compatibility with Turbo Pascal extensions was more relevant.

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.

In the past I've sometimes used standard C++ local structs to nest functions. E.g.:

    int f()
    {
        struct local {
            static int nested_func()
            {
                return 123;
            }
        };

        return local::nested_func();
    }

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.

There are always alternatives. The issue is how naughty or nice they are.

Good points, all.

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.

Misliked?

Mind blowing factoid: not everybody on the internet is a native english speaker.

Not sure what your point is, but it's a real word :-)

> nested functions in Pascal and D

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.

C# has just implemented nested functions.

There is a nice blog post that concisely explains why local functions are better than lambdas: https://asizikov.github.io/2016/04/15/thoughts-on-local-func...

C#: "Local functions can not be static."

Static nested (i.e. local) functions in D can be static. What that does is prevent the function for accessing locals in the enclosing scope(s).

>3. A lot of my need for goto statements vanished with nested functions.

How does that work? Not immediately obvious to me.

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.

Got it now, thanks. I've used nested functions in Python and they have some good uses. Will check them out in D.

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.

https://stackoverflow.com/questions/4083356/array-begin-from...

And the string length is in the 0 byte, meaning no strings longer than 255 bytes. At least in old Turbo Pascal anyway!

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:

http://docwiki.embarcadero.com/RADStudio/Berlin/en/String_Ty...

In the case of classic Mac OS it was part of the API.

With 640 KB it wasn't as there was a lot of space to have bigger strings.

Besides, there were arrays as well, and TPW had safer strings without that limitation PCharStr.

Oh lordy, I'd forgotten the array index thing. That was painful.

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):

http://docwiki.embarcadero.com/Libraries/Berlin/en/System.Lo...

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.

Turbo Pascal had them.

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:

http://docwiki.embarcadero.com/RADStudio/Berlin/en/Migrating...

Coming from Basic that wasn't a problem.

It always felt quite natural to me.

https://blogs.technet.microsoft.com/srd/2017/07/20/englishma...

I found out that GetString converts a Pascal string to C without a length argument!

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!

I hadn't heard of CFront.

https://en.wikipedia.org/wiki/Cfront

Interesting.

Reply on news.ycombinator.com