C closures & lexical scoping

K

Khookie

Woah... is it just me or do C programmers don't bother talking about
how cool C can be (compared to Lisp, Haskell, etc.) - functionally
speaking?

// Lexical scoping - via nested functions
#include <stdio.h>

int main() {
int x = 10;

// lexical scoping
static void test() {
x = 123;
}
test();

printf("%d", x);
return 0;
}

// Closures
#include <stdio.h>

int triple(int num) {
return num * 3;
}

int square(int num) {
return num * num;
}

int main() {
int x = 10;

int (*func)(int);

func = square;
printf("%d\n", func(5));

func = triple;
printf("%d\n", triple(5));

return 0;
}

Chris
 
R

Richard Tobin

Woah... is it just me or do C programmers don't bother talking about
how cool C can be (compared to Lisp, Haskell, etc.) - functionally
speaking?
Well...

// Lexical scoping - via nested functions

Oops, C doesn't have nested functions. Gcc has them as an extension.
// Closures
#include <stdio.h>

int triple(int num) {
return num * 3;
}

int square(int num) {
return num * num;
}

int main() {
int x = 10;

int (*func)(int);

func = square;
printf("%d\n", func(5));

func = triple;
printf("%d\n", triple(5));

return 0;
}

I don't see any closures there, just pointers to functions. Without
nested functions, there's nothing interesting to close over.

-- Richard
 
C

Chris Dollin

Khookie said:
Woah... is it just me or do C programmers don't bother talking about
how cool C can be (compared to Lisp, Haskell, etc.) - functionally
speaking?

// Lexical scoping - via nested functions

/Standard/ C doesn't have nested functions. (Even if it did, I expect it
would have them BCPL-style -- no access to non-static outer locals.)

Note also the significant restriction of these GCC-specific closures: you
can't export them out of the defining function:

If you try to call the nested function through its address after the
containing function has exited, all hell will break loose.

[The text is from
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Nested-Functions.html

which was the first hit for the Google string "gcc nested functions".]

A functional programmer will sneer at this feeble attempt at higher-order
programming.
 
C

cr88192

Mark Bluemel said:
What about all us dysfunctional programmers?

sitting around scoffing at the idea of the compiler silently inserting
runtime calls, and other things, whenever we use certain language
features...
 
C

Chris Dollin

Mark said:
What about all us dysfunctional programmers?

It's imperative that you assign pure-functional programmers to the
right category, otherwise they won't be able to effect you.

IO, IO, it's off to work we go ...
 
M

Mark Bluemel

Chris said:
It's imperative that you assign pure-functional programmers to the
right category, otherwise they won't be able to effect you.

IO, IO, it's off to work we go ...
I'm oriented to object to your suggestions...
 
J

jacob navia

cr88192 said:
sitting around scoffing at the idea of the compiler silently inserting
runtime calls, and other things, whenever we use certain language
features...

Yeah, for instance
long long a,b,c;
....

c = a/b;

This generates a function call in C due to operator overloading...
Division is overloaded and works with long long types, but in a
32 bit system that means a function call
 
R

Richard

cr88192 said:
sitting around scoffing at the idea of the compiler silently inserting
runtime calls, and other things, whenever we use certain language
features...

I don't understand. It can do just that.
 
P

Philip Potter

jacob said:
Yeah, for instance
long long a,b,c;
...

c = a/b;

This generates a function call in C due to operator overloading...
Division is overloaded and works with long long types, but in a
32 bit system that means a function call

Not necessarily. It could easily mean an idiomatic sequence of machine
instructions (similar in concept to a C macro) instead.
 
R

Richard Heathfield

Philip Potter said:
jacob navia wrote:

Not necessarily. It could easily mean an idiomatic sequence of machine
instructions (similar in concept to a C macro) instead.

Or it could simply be translated to a native division instruction, on
machines that have such a thing. Nothing in the rules prevents this.
 
C

Charlton Wilbur

K> Woah... is it just me or do C programmers don't bother talking
K> about how cool C can be (compared to Lisp, Haskell, etc.) -
K> functionally speaking?

Because we've seen what happens in comp.lang.lisp, which is all about
how cool Lisp is and how misunderstood Lisp programmers are, and how
ANY DAY NOW the great unwashed masses are FINALLY going to realize
just how cool Lisp is and abandon all other programming languages.

Scarcely a parenthesis to be found.

And we're spending so much time repeatedly explaining to Jacob Navia
the concept of "topicality," and how he'd get better responses to his
posts if he posted them where they were on topic, that we just can't
muster the energy for any more foolish advocacy.

Charlton
 
P

Philip Potter

Richard said:
Philip Potter said:


Or it could simply be translated to a native division instruction, on
machines that have such a thing. Nothing in the rules prevents this.

The phrase "32 bit system" is a woolly one, but I took it to imply that
the machine did not have a long long-sized division instruction.

Phil
 
J

jacob navia

Philip said:
The phrase "32 bit system" is a woolly one, but I took it to imply that
the machine did not have a long long-sized division instruction.

Phil

I just wanted to point out the basic unity between operators and
functions. An operator can lead to a function call when an operation
is absent in the real machine. In a 32 bit system precisely most of
the time there is no 64 bit division. (Actually I have never seen a 32
bit system with native 64 bit integer division...)

Of course it can be inlined.
 
J

jacob navia

Charlton said:
K> Woah... is it just me or do C programmers don't bother talking
K> about how cool C can be (compared to Lisp, Haskell, etc.) -
K> functionally speaking?

Because we've seen what happens in comp.lang.lisp, which is all about
how cool Lisp is and how misunderstood Lisp programmers are, and how
ANY DAY NOW the great unwashed masses are FINALLY going to realize
just how cool Lisp is and abandon all other programming languages.

Scarcely a parenthesis to be found.

And we're spending so much time repeatedly explaining to Jacob Navia
the concept of "topicality," and how he'd get better responses to his
posts if he posted them where they were on topic, that we just can't
muster the energy for any more foolish advocacy.

Charlton

Yes, you are spending way too much time bashing navia as it seems.

You would better keep quiet then, and apply your own advice.
 
R

Richard

Charlton Wilbur said:
K> Woah... is it just me or do C programmers don't bother talking
K> about how cool C can be (compared to Lisp, Haskell, etc.) -
K> functionally speaking?

Because we've seen what happens in comp.lang.lisp, which is all about
how cool Lisp is and how misunderstood Lisp programmers are, and how
ANY DAY NOW the great unwashed masses are FINALLY going to realize
just how cool Lisp is and abandon all other programming languages.

Scarcely a parenthesis to be found.

And we're spending so much time repeatedly explaining to Jacob Navia

Who is "we"? The royal "we"?
 
P

Philip Potter

jacob said:
I just wanted to point out the basic unity between operators and
functions. An operator can lead to a function call when an operation
is absent in the real machine. In a 32 bit system precisely most of
the time there is no 64 bit division. (Actually I have never seen a 32
bit system with native 64 bit integer division...)

Of course it can be inlined.

In which case why make it a function call in the first place? The thread
about the comparison between operators and function calls is over.
 
K

Kaz Kylheku

Woah... is it just me or do C programmers don't bother talking about
how cool C can be (compared to Lisp, Haskell, etc.) - functionally
speaking?

The set of C programmers who

- are interested in Lisp and Haskell, but
- seriously misunderstand lexical closures, and who
- don't know what is or isn't a GCC extension

is probably vanishingly small.
// Lexical scoping - via nested functions
#include <stdio.h>

int main() {
int x = 10;

// lexical scoping
static void test() {
x = 123;
}

Function nesting is a GCC extension, not standard C.

More importantly, it doesn't implement first class lexical closures.
It has ``downward funargs'' only, like Pascal.

True lexical closures means being able to do something like this:

static int (*test(void))(void)
{
int local = 42;
int nested(void)
{
return local;
}

return &nested;
}

int main(void)
{
int (*func)(void) = test();
printf("%d\n", func());
return 0;
}

The output is 42, because in this imaginary C dialect, &nested creates
a closure instead of just a regular function pointer. A closure is an
object which contains not just the address of the function, but also
the function's captured lexical environment in which the ``int local =
42'' binding is in effect. That environment survives the termination
of the test() call, which is why when we call func(), it returns the
value 42.

The above is not permitted by the GCC extension. The GCC manual says
that ``all hell will break loose''.
 
C

CBFalconer

Khookie said:
Woah... is it just me or do C programmers don't bother talking
about how cool C can be (compared to Lisp, Haskell, etc.) -
functionally speaking?

// Lexical scoping - via nested functions
#include <stdio.h>

int main() {
int x = 10;

// lexical scoping
static void test() {
x = 123;
}
...

Illegal. C doesn't allow nested functions.
 
C

cr88192

Richard said:
I don't understand. It can do just that.

often cases, yes.

none the less, people tend to dislike this kind of thing in C land (even as
such, it happens sometimes), albeit it is a very common occurance in most
non-C languages (where there are hidden runtime calls pretty much
everywhere...).

now, adding lexical scoping, ... would require this.
write a nested function, get a function pointer. oh no, a function call...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top