To be accurate, only when functions are able to be manipulated at run time - i.e., are first class objects - may a language support higher order techniques. In C, you can pass in a function pointer as a parameter, but you can't create or manufacture functions on the fly. | [reply] |
In C, you can pass in a function pointer as a parameter, but you can't create or manufacture functions on the fly.
You can, if you have a compiler, system, dlopen, and dlfunc!
| [reply]
[d/l]
[select] |
The first time I read a C program which wrote and executed an awk program to do the 'difficult' string manipulation changed the way that I thought about the limitations of languages.
The need to do tricks like this were the force that drove me towards the 'just write the whole app in Perl' approach.
The most natural way to create a high-performance program may be to write a Perl program that writes a C++ program.
It should work perfectly the first time! - toma
| [reply] |
Not so fast.
In Perl you're not really creating functions at run time (unless you're calling eval). You're creating closures. So what is really needed is to be able to create and pass around closures at run time.
C, of course, does not natively support having closures. But C does support structs, and it really isn't hard to define a struct that consists of a pointer to a function and a pointer to whatever. And then have a function to call the function pointer and pass it the other pointer. Now we have something equivalent to a closure. (Well, it doesn't do its own memory management, but let's not quibble,)
Sure, our functions that can be used that way all have to accept a random pointer to a data structure as an argument, and have to manually unpack their environment from that. It is ugly. (What do you expect from C?) But now you can use functional programming techniques in C.
| [reply] |
The presence of the explicit struct; the necessity of manual assignment of values (as opposed to implicit capture); manual management of the memory involved: none of these can make functional-style code so ugly as the mere fact that C’s syntax provides no device for writing functions anonymously and inline.
Once you combine the latter fact with the faults you mention, you inevitably run into a curious equivalence. Structs with function pointers; to functions written out of line; which accept a pointer to a user data struct: does that not sound oddly familiar? It should: there is no decidable distinction between writing OO-style C and functional-style C. Both involve the exact same mechanics of construction.
Makeshifts last the longest.
| [reply] |
In assembler you can also do OOP, what you expect from assembler?
| [reply] |