Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

Who needs functional programming...

Name: Anonymous 2015-07-27 20:45

... when C has function pointers?

Name: Anonymous 2015-07-27 20:54

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

Name: XML makes Java the 2015-07-27 21:34

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

Name: Anonymous 2015-07-27 22:58

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

Name: Anonymous 2015-07-28 0:53

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

Name: Anonymous 2015-07-28 2:46

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

Name: Anonymous 2015-07-28 4:12

>>6
Yes, thanks.

Name: Anonymous 2015-07-28 7:15

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

Name: Anonymous 2015-07-28 10:03

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

Name: Anonymous 2015-07-28 17:26

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

Name: Anonymous 2015-07-28 17:35

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

Name: Anonymous 2015-07-28 18:09

>>10
Use macros to create the structs automatically.

Name: Anonymous 2015-07-28 18:25

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

Name: Anonymous 2015-07-28 18:46

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

Name: Anonymous 2015-07-28 20:24

In the end it's just easier to use

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

and cast the return value.

Name: Anonymous 2015-07-28 20:43

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

Name: Anonymous 2015-07-28 20:56

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

Name: Anonymous 2015-07-28 21:07

>>16
This is undefined behavior.

Name: Anonymous 2015-07-28 21:22

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

Name: Anonymous 2015-07-29 1:25

I wish I had a copy of the see standard.

Name: Anonymous 2015-07-29 3:35

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

Name: Anonymous 2015-07-29 7:42

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

Name: Anonymous 2015-07-29 9:32

>>22
Explain golang.

Name: Anonymous 2015-07-29 10:32

>>19
Thank you, now I am enlightened.

Name: Anonymous 2015-07-29 17:46

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

Name: Anonymous 2015-07-29 17:50

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

Name: Anonymous 2015-07-29 17:50

>>25
People are using C when they should be using Pascal, Fortran, PL/I,
Did you copypaste this from a 20 year old BBS?

Name: Anonymous 2015-07-29 18:02

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

Name: Anonymous 2015-07-29 19:53

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

Name: Anonymous 2015-07-29 20:12

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

Name: Anonymous 2015-07-29 20:58

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

Name: Anonymous 2015-07-29 21:17

bump for dubs

Name: Anonymous 2015-07-29 21:39

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

Name: Anonymous 2015-07-30 15:32

>>30
JavaScript and PHP are, in fact, strongly typed.
Did you write that with a straight face? I doubt so.

Name: Anonymous 2015-07-30 15:56

>>34 u hav bean troll'd m8 XD

Name: Anonymous 2015-07-30 16:59

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

Name: Anonymous 2015-07-31 19:42

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

Name: Anonymous 2015-07-31 21:34

bits is bits, dolt

Name: Anonymous 2015-07-31 22:43

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.

Name: Anonymous 2015-08-01 6:00

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

Name: Anonymous 2015-08-01 10:51

Who needs functional programming?
You do, that's who.

Name: Anonymous 2015-08-01 15:28

>>40
By your definition, FIOC and Lithp are statically typed since you could write a method to replace the assignation operator that aborts when data of another type is stored in the same variable.

Why even have this discussion if you're not even comparing languages by their defaults? That would be as dumb as claiming Javashit is strongly typed and Lisp-like just because Typescript and Clojurescript exist.

Don't change these.
Name: Email:
Entire Thread Thread List