C closures & lexical scoping

[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

[Richard Tobin]

In article <6e************ *************** *******@e6g2000 prf.googlegroup s.com>,
Khookie <ch********@gma il.comwrote:

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

[Richard Heathfield]

Philip Potter said:

jacob navia wrote:

<snip>

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

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

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Charlton Wilbur]

>>>>"K" == Khookie <ch********@gma il.comwrites:

KWoah... is it just me or do C programmers don't bother talking
Kabout how cool C can be (compared to Lisp, Haskell, etc.) -
Kfunctionally 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
--
Charlton Wilbur
cw*****@chromat ico.net

[Philip Potter]

Richard Heathfield wrote:

Philip Potter said:

>jacob navia wrote:

<snip>

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

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

[jacob navia]

Philip Potter wrote:

Richard Heathfield wrote:

>Philip Potter said:

>>jacob navia wrote:

<snip>

>>>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
instruction s (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.

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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Charlton Wilbur wrote:

>>>>>"K" == Khookie <ch********@gma il.comwrites:

KWoah... is it just me or do C programmers don't bother talking
Kabout how cool C can be (compared to Lisp, Haskell, etc.) -
Kfunctionally 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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Richard]

Charlton Wilbur <cw*****@chroma tico.netwrites:

>>>>>"K" == Khookie <ch********@gma il.comwrites:

KWoah... is it just me or do C programmers don't bother talking
Kabout how cool C can be (compared to Lisp, Haskell, etc.) -
Kfunctionally 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"?

[Philip Potter]

jacob navia wrote:

Philip Potter wrote:

>Richard Heathfield wrote:

>>Philip Potter said:
jacob navia wrote:
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
instructio ns (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.

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.

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.

[Kaz Kylheku]

On Dec 12, 2:28 am, Khookie <chris.k...@gma il.comwrote:

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))(v oid)
{
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''.