51–60 of 78 posts
Earlier quoted context omitted.
Sure, but we're talking about whether or not this particular style of C can be Turing complete and I'm not sure it is, even on a machine with an infinite amout of RAM.
A machine with an infinite amount of RAM can have an infinite stack size.
...and pigs can fly, if you throw them fast enough. This is just an encoding of a Turing-complete language into another, I don't see what's been demonstrated here.
I would say the aspect that defines a functional programming language is the support of higher order functions. I.e. functions that can take functions as arguments and more importantly can return functions as return value.
I'm not that old but I remember that, back in the days, functional meant just that you are able to use plain functions (without objects) and pass them around. By that definition, C is functional language, as scheme or lisp or javascript and many others. I don't know why, but some years ago, "functional programmers" started to change and twist the definition of functional language step by step, until all those languag…
http://conal.net/blog/posts/the-c-language-is-purely-functio...
By Conal Elliot.
Earlier quoted context omitted.
I don't think that solves the problem. Whatever fixed stack size you choose, you still cannot write a program that determines the size of the lists at runtime. A Turing complete system would have to be able to do that. The only way I see is to allocate (almost) the entire machine memory to the stack, create one giant array in that chunk of memory and then put all lists in that single array. That's tantamount to reimp…
Any physical machine cannot be Turing complete because it has a finite amount of RAM.
Earlier quoted context omitted.
Sure, but we're talking about whether or not this particular style of C can be Turing complete and I'm not sure it is, even on a machine with an infinite amout of RAM.
A machine with an infinite amount of RAM can have an infinite stack size.
...and pigs can fly, if you throw them fast enough. This is just an encoding of a Turing-complete language into another, I don't see what's been demonstrated here.
I'm not sure this is even Turing complete considering the limitation he mentions: >The main limitation is that you need to know the size of the return value.
Earlier quoted context omitted.
Yes, but you can't combine function pointers to create and return new functions.
Sure you can - just not anonymously. Kind of like how you can have "higher order functions" and "closures" in Java with anonymous classes - roughly equivalent, but awkward and not quite what the language was designed for. C is probably better in this regard than Java, but the lack of managed memory is a major drawback.
Just not depending on anything in the environment either except globals, which is a huge limitation. So writing a function inc by = \x -> x + by becomes unnecessarily difficult for example.
I would say the aspect that defines a functional programming language is the support of higher order functions. I.e. functions that can take functions as arguments and more importantly can return functions as return value.
As jeremyjh already pointed out, this results in a pretty weak definition. You end up with JavaScript, Ruby, Python, and Objective-C all being lumped as "functional languages", and if you squint a little bit, you can put Java in there too (anonymous inner classes). I think C, C++ and C# could be as well, but I don't know them well enough. So I don't think it's very productive to use a definition like this, but not be…
Same goes for OO, which has something like 9 well-known defining features.
Earlier quoted context omitted.
A machine with an infinite amount of RAM can have an infinite stack size.
C arrays that live on the stack have to be created with a constant size (at least before C99). It's a limitation of the language regardless of any machine or stack size.