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