Who needs functional programming...

... when C has function pointers?

Because pointers are "too complicated and dangerous" for the average programmer. That's also why they create so many levels of abstraction: basically people is stupid so they need lisp and haskell

so you manually perforn closure conversion and i can't even guess what you propose to replace GC with?

>>3
In C you don't need ``closures'' because there is something much, much more versatile: the file scope. This tool is so powerful that one could write any type of software entirely using global variables.
GC? HIBT? IHBT.

http://i.imgur.com/DWrI2JY.gifv MFW when I realized the same C header file could be implemented by two different source files interchangably, switched by the compiler invocation

>>5
lmaoooooo that reaction image is really epic image/b/oard /b/ro xDDDD rofl
epic MFW meme bro ;)

>>6
Yes, thanks.

>>1
C function pointers are hobbled by the language's feeble type system. You can't define a function in C which returns a pointer to another function of the same type. Thus you can't even implement a simple state machine without stupid hacks to escape the type system (adding some sort of lookup table or switch statement to translate state codes to functions is the usual workaround).

C doesn't even have a generic function pointer type on all implementations (all the world is not POSIX, where void * will work fine).

>>8
Shouldn't this work fine?
struct fp
{
struct fp *(*func)(void *);
};

C doesn't even have a generic function pointer type on all implementations

I fail to see how a generic function pointer would be of use, but you can always return a void * that you then cast into a pointer to a struct that contains the function pointer you want.

>>9
devil almighty, why hadn't I thought of that? Oh wait, because then I'd have to create a new struct for every different cast. The problem is FUBAR in C

>>7
You're welcome. Now check my dubs.

>>10
Use macros to create the structs automatically.

>>9
You can compile and load code in runtime in C too, together with the preprocessor, to have your program just as flamboyant as you like it.

>>12
It just doesn't work for the case I have in mind. I know what you're talking about, but in the end, it rounds down to me having to identify the different sorts of functions that can exist in the source explicitly.

In the end it's just easier to use

void* (*fp)(...);

and cast the return value.

>>8

C doesn't even have a generic function pointer type on all implementations

void (*)()
// or anything really
any function pointer can be cast to any other function pointer and back again, and it shall be equal to the original pointer.

>>16
That's cause C is untyped. Not unityped like Phython or Rabbi or Scheme, but untyped like fucking assembly.

>>16
This is undefined behavior.

>>18
§ 6.3.2.3
``A pointer to a function of one type may be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer.´´

I wish I had a copy of the see standard.

>>20
http://www.open-std.org/jtc1/sc22/wg14/www/standards.html

The latest publically available version of the C11 standard is the document WG14 N1570, dated 2011-04-12. This is a WG14 working paper, but it reflects what was to become the standard at the time of issue.

>>9,15-17,19
If you have to use void *, or cast, you have expressly admitted that the type system is insufficient. The implication that relying on totally unchecked runtime type conversions is acceptable for such a basic language feature is just insane, especially given that the language spec permits implementations to do literally whatever they feel like doing if the programmer attempts to perform an illegal conversion.

>>22
Explain golang.

>>19
Thank you, now I am enlightened.

>>22
You missed the point of C.
C is an untyped language with optional types on top. C evolved from the untyped BCPL and B languages. This type became C's int. literally whatever they feel like doing means what the underlying hardware actually does.
Compilers use this to do optimizations because C is being used as a general purpose language when it's not. C isn't meant to be easily optimizable. C is not Fortran. It's meant to make it easy for you to write the optimizations in your own code.
C was invented for writing kernels and drivers in Unix, without needing much assembly, so converting integers to and from pointers is easy. You need the same things when making a garbage collector, for example.
People are using C when they should be using Pascal, Fortran, PL/I, or many other languages. These languages are more easily optimizable than C (without breaking the semantics of your code), compile to native code without a large runtime, and don't have GC either.

>>25
C is weakly typed, not ``untyped language with optional types on top'', what kind of dick are you? sage.

>>25

People are using C when they should be using Pascal, Fortran, PL/I,

Did you copypaste this from a 20 year old BBS?

>>26
It isn't weakly typed, it's strongly typed but only when you want it (and untyped otherwise). E.g. C will not auto-coerce a long to a double (as a weakly typed language would), but will allow you to reinterpret a long as a double (as untyped languages do).

>>28

C will not auto-coerce a long to a double (as a weakly typed language would)

If the range of long is less than the range of double, why would this be "weakly typed" at all? It seems like you don't even know what that means. Also, C will do this.
Unless you're using "coerce" to mean something else.

>>28
Weak typing is when you can throw away the type of a value, like void*.
There's no way to reconstruct the original type. In C, it's impossible to know whether it originally pointed to a single byte or an array of 1000 pointers to floats.
If you can turn the pointer to a byte into a pointer to an array of 1000 pointers to floats, you are using weak typing. There's no guarantee that they are all valid pointers to floating-point numbers at that location.
If it's impossible to throw away the type of a value and a type guarantees that the value always belongs to that type, the language is strongly typed.
JavaScript and PHP are, in fact, strongly typed. They just have strange and unintuitive definitions for the built-in operators.

>>30
No, weak typing is when values have types but the language inserts all sorts of implicit conversions in an attempt to guess the programmer's intentions. C's ability to cast to *void is 1) explicit, so definitely not weakly-typed 2) defeats the very point of types.

Being able to reinterpret the bits of a value however you want is lack of typing, not weak or strong typing. Types were invented for holding information how any given bitstring is to be interpreted. C allows you to sidestep this and reinterpret any bit string (e.g. a pointer or a floating-point number) however you want. This means it ultimately has no types, neither weak ones nor strong ones.

JavaScript and PHP are, in fact, strongly typed

Nope, at least not completely strongly typed, and since they're so weak in the spots that matter most, they are, for most intents and purposes, weakly typed.

bump for dubs

>>31

weak typing is when values have types but the language inserts all sorts of implicit conversions

This is a redefinition by "scripting language" programmers to distinguish their language from Perl, not the original meaning of the term.
Weak means types can be lost or thrown away. Period.

C's ability to cast to *void is 1) explicit

It is implicit, which is one of the incompatibilities with C++.
Besides, explicit and implicit have nothing to do with strong or weak typing at all. Even Coq has implicit conversions and nobody would say it isn't strongly typed.

2) defeats the very point of types.

From a strongly typed point of view, the only type C has is unsigned char. (This might help you understand the difference between strong and weak types.)

This means it ultimately has no types, neither weak ones nor strong ones.

Close, but it only has one type: unsigned char.

Nope, at least not completely strongly typed

It's impossible to throw away the type of a value. They have no conversions either (since they have only one strong type, that's absurd). The "conversions" are really a dispatch hidden inside the built-in operators.

>>30

JavaScript and PHP are, in fact, strongly typed.

Did you write that with a straight face? I doubt so.

>>34 u hav bean troll'd m8 XD

>>25
You missed the last 25 years of evolution in C compilers. The old K&R thinking by analogy to BCPL died the day ANSI finalized C89; maintaining differently is superstition.

Modern optimizing compilers will happily break code that invokes undefined behavior. Compiler writers have very little patience with users who argue correctness based on some naive mapping to a particular architecture's machine model, rather than the abstract machine defined by the language standard.

>>33
OK. Time for some wikifaggotry:

Note that some of these definitions are contradictory, others are merely orthogonal, and still others are special cases (with additional constraints) of other, more "liberal" (less strong) definitions. Because of the wide divergence among these definitions, it is possible to defend claims about most programming languages that they are either strongly or weakly typed.
Java, C#, Ada and Pascal are sometimes said to be more strongly typed than C

So the claim that C is weakly typed is, indeed, arguable. However, what is not arguable is that C is untyped, because it fully fits this bill:

Assembly language and Forth have been said to be untyped. There is no type checking; it is up to the programmer to ensure that data given to functions is of the appropriate type. Any type conversion required is explicit.

There is no type checking void * values in C: it is up to the programmer to ensure that data given to functions is of the appropriate type. Thus, C is untyped, with optional static typing (whether it is strong or weak is up to debate).

bits is bits, dolt

There is no type checking void * values in C: it is up to the programmer to ensure that data given to functions is of the appropriate type. Thus, C is untyped, with optional static typing (whether it is strong or weak is up to debate).

This is the most stupid argument I've ever heard, please stop posting.

>>34
JavaScript and PHP are strongly typed.
2 is a number and "2" is a string. Bash, which is "stringly typed" (statically and dynamically unityped), treats them both as strings. The + operator does different things depending on the dynamic types of its operands. If these languages happened to use different symbols for each case of the + and == operators (and all the other operators), it would still be possible to write your own function that checks the dynamic types of its arguments and does the same thing as JavaScript's and PHP's built-ins.
You're caught up on the "built-in" aspects of these operators. In Scheme, + is just a procedure. It can be replaced by a procedure that has (as close as possible to) JavaScript semantics.
Think of + as someIdiotsIdeaOfWhatAdditionMeans. You can write your own addNumbers and concatenateStrings in JavaScript if you like and they can throw exceptions when values of the wrong types are passed in. You just can't give them the + syntax.