Who needs functional programming...

when C has function pointers?

It does not close over the bindings in scope.

>>2
Technically you're correct, but since there are no nested scopes in C and the global scope is, well, a singleton, there's nothing for function pointers to close over in the first place.

https://groups.google.com/d/msg/alt.folklore.computers/rPEZ0AZgdbU/OXCLYD8VBwAJ

72441 45377 99257 21205 70012 42683 03490
10992 77914 73849 35970 84734 27657 28649
50359 17317 03560 98352 40906 07351 70157
39680 20055 85792 06316 25917 75892 08671

http://ai.neocities.org/GIX.html

Function pointers suck.

They suck for expressiveness and safety because there's no way to define a self referential type in C (a function can't return a pointer to a function of the same type). The only workarounds for this are kludges, often involving some form of type erasure (void pointers).

They also suck for performance because they're huge (who needs a value that can cover the full address space - almost nobody; you're just wasting precious cache) and make branch prediction harder than it needs to be (shared code that dererferences externally furnished function pointers can land nearly anywhere, every time).

The only thing they're good for is to save the programmer when they're backed themselves into a corner and need a heaping helping of dynamic binding to get out. Useful, sure; but not the first or best choice.

a function can't return a pointer to a function of the same type

Who cares, nerd?
struct func { struct func *(*func)(void); };

They also suck for performance because they're huge (who needs a value that can cover the full address space - almost nobody; you're just wasting precious cache) and make branch prediction harder than it needs to be (shared code that dererferences externally furnished function pointers can land nearly anywhere, every time).

Use a better compiler nerd, rofl.

>>5

there's no way to define a self referential type in C

That's the old ``worse is better'' in action. Would this slow down the generated code in any way? No, it would probably allow for more optimizations of and across function calls. So why did they do it? Because doing it the right way didn't matter for C's original purpose, which was hacking together an OS for the PDP-11.

function pointers are ok

if you want first class functions program in a language that has them

Who needs function pointers when you can just use the preprocessor?

>>6

struct func { struct func *(*func)(void); };

That's actually not a bad idea at all. Combined with something like the Plan 9 extensions for anonymous struct members⁽¹⁾, you can almost pretend this limitation doesn't exist.

Use a better compiler nerd, rofl.

Not always possible. Even if it is, a good compiler can't save you if your CPU's branch predictor is really weak. Even sophisticated branch predictors will have an easier time if you don't use indirect references.

____
_{[1] https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html}

What a shit thread, functional programming is not about first-class functions, it's about functions being pure. Unnamed functions are so easy to retcon into a language they even managed to put them in Java. First class functions are just as easy.

Turns out the dutch don't do dikes all day long.. when the water is frozen they manage to do some actually usefull stuff: http://eprints.eemcs.utwente.nl/1077/

I don't mean to alarm you, but someone is stealing your threads!

>>11
so ML (and its derivatives), Lisp, and GHC Haskell (unsafePerformIO) aren't ``functional''? And don't say that they're ``mostly pure'' or that impurity is an edge case, it's boolean, either you have it, and you couldn't write an impure function if you wanted to, or you don't, and you can't assume that for all functions, the purity property holds. If you can't assume it holds for all functions, then you generally get a much weaker property: there exist some pure functions, something true of literally every single programming language in existence, including C, Java, etc.

>>13
ML, Lisp, C, Java, and JavaScript: ``All my language has is floating point numbers. Integers are just a special case of floats.''

Haskell: ``My language is purely integral. It has only integers and you can't do floating point numbers. Instead, you use a ``Float Monad'', a special state monad which passes around an exponent.''

Other language: ``There are integer and floating point types, with floating polymorphism. They mostly look the same, but if you use a float anywhere, the whole expression has a float type.''

Huskall did it right.

>>14

C, Java, and JavaScript

Accurate.

ML: Floats and ints are separate types. Converting an int to a float or vice versa is no different to converting either to a decimal string.

Lisp (Scheme): Floats and ints are part of a tower. They get converted automatically in one direction, so to work exclusively with just one type requires a whole new family of specialised arithmetic functions.

>>14

C […]: ``All my language has is floating point numbers. Integers are just a special case of floats.''

What the fuck.

>>17
If you are concerned about the accuracy of the statement, consider how the return type changes when introducing a double into an expression otherwise entirely populated with ints.

>>16-18
>>14 was making an analogy where integers = "pure functions" and floats = IO, you fucking retards.

>>18
The 3rd case applies for C then.

``There are integer and floating point types, with floating polymorphism. They mostly look the same, but if you use a float anywhere, the whole expression has a float type.''

>>19
When you make an analogy using concepts in the same domain, who exactly is the retard?
>>20
That's what I get for only having one postref's worth of backtracking.

your analogy is stupid, you are stupid, please rethink your life choices that led to you post such garbage