[CerryuDu]

From the introduction, your paper seems like a counterproposal: support closures, just not the way others propose. But the paper seems to accept that closures / nested functions, supported at the language level directly, are a "good thing" for C specifically. I disagree with that. When and how has it become the consensus?

[uecker]

At the moment there is no consensus for anything related to this. But most people agree that closures are a good thing because they make certain reoccurring programming patterns safer and easier to write. Why do you disagree?

[CerryuDu]

Thanks for the answer.

I disagree because I've seen closures shine (in OCaml) and suck terribly (in C++). Same concept, extremely different programming experience and debuggability. Syntax matters, language psychology matters. Closures naturally and obviously suit programming languages that are genuinely functional, or at least manage memory transparently for you. C is neither, and so "alloca", "defer", the cleanup attribute, closures -- all stick out sorely. The whole selling point of C is explicitness. The tedium of C is the price we pay for the great control that C offers us with a relatively simple vocabulary. I couldn't be more content with that deal.

C++ is impossible for any single person to learn, there is so much insanely complicated implicit behavior in it. C can mostly be learned by a single (persistent) person, but it's been getting harder.

I don't want C to be fashionable, or attractive. I want it to remain minimal. If someone feels hamstrung by it, there are so many other languages to choose from. I simply want the particular tradeoff that C offers (or used to offer) to remain in existence. And that is what's been going away, with each issue of ISO C being the only official standard (obsoleting/superseding all earlier issues of the standard).

Why give people closures or "defer" or ... whatever ... when they can't even remember the concept of the usual arithmetic conversions? Which has been standard since C89? Have you met a "practitioner" (= any C programmer with no particular interest in the standard proper) that could explain the effective type rules? Why make it more complicated?

I apologize -- I guess this is just my semi-diplomatic way to say, "please, get off my lawn". (Not to you personally, of course!) I'm very sorry.

EDIT: for more of the same sentiment, see the reddit thread: https://old.reddit.com/r/programming/comments/1pk3whx/the_co...

[uecker]

> I disagree because I've seen closures shine (in OCaml) and suck terribly (in C++).

Well, I also do not want to see C++ style closures in C and I fully agree about your point regarding control and explicitness. I also agree that some of the initiatives we see now are regrettably motivated by the attempt to make C fashionable, and sometimes by poorly adopting C++ features.

Yet, I think nested functions fit C perfectly way and I use them for a long time in some projects. They exist in very similar languages (PASCAL, Ada, D, ...) and even in C's ancestor ALGOL. This also shows that this type of nested functions are also not a functional programming concept. There is not really anything to learn, as syntax and semantics follow very naturally from all existing rules and the improvement in code quality for callbacks or higher-level iteration over data types is very real. I agree that it gets much more complicated once you treat them more as objects that can escape their original function, pointing this out is what I tried t o do with my paper.

The usual arithmetic conversion have seen unfair criticism in my opinion. Effective types rules are mess, to some degree also because compilers invented their own rules or simply ignore the C standard. But this is a different topic. From a programmer's point of view, the rule that you just access each variable should have one type that is used consistently is enough to know to stay on the safe side.

[dfawcus]

The other example of nested functions which you've not mentioned was in Metaware High C.

There they allowed nested functions, but also what they termed "full function values", being a form of fat pointer. Certainly I came across it in High-C v1.7 in 1990, and the full manual for an earlier version (1.2?) from around '85 can be found on Bitsavers.

It had a syntax like:

    extern void Quick_sort(
      int Lo, int Hi, int Compare(int a, int b)!,
      void Swap(int a,int b)!
    );

    static Sort_private_table() {
      Entry Entries[100];
      int Compare(int a,int b) {
        return Entries[a] < Entries[b];
      }
      void Swap(int a,int b) {
        Entry Temp = Entries[a];
        Entries[a] = Entries[b];
        Entries[b] = Temp;
      }
      ...
      Quick_sort(1,100,Compare,Swap);
    }

The above is an extract from their language reference, which you can find here:

https://archive.org/download/Yoshizuki_UnRenamed_Files__D-V/...

[dfawcus]

Note - as far as I can see, it has similar behaviour to what you propose with _Wide for a wide pointer. Just that it is existing practice, from 40 years ago.

I believe the High-C compiler with this support is still available, for modern embedded CPUs.

[uecker]

Yes, I know about High-C although I did not know that it still exists. Thanks!

[CerryuDu]

Thanks!