Anonymous functions in C.

[jacob navia]

Gnu C features some interesting extensions, among others
compound statements that return a value. For instance:

({ int y = foo(); int z;
if (y>0) z = y; else z=-y;
z;
})
A block enclosed by braces can appear within parentheses
to form a block that "returns" a value. This is handy
in some macros, or in other applications.

Actually this construct is nothing more (and nothing less)
than anonymous functions.

Anonymous functions could be really handy in call to qsort,
for instance, where just writing an expression could allow
the compiler to expand the anonymous function at each point of
call (as an inline function) within the qsort algorithm.

This, and other extensions are published in a document
"Potential Extnsions for Inclusion in a revision of
ISO/EIC 98/99" available at

http://www.open-std.org/jtc1/sc22/wg...docs/n1229.pdf

That is the official standard site.

Other Gnu extensions are mentioned in that document, like typeof
for instance, an extension that also lcc-win32 implements.
jacob

[Keith Thompson]

jacob navia <ja***@jacob.re mcomp.frwrites:

Gnu C features some interesting extensions, among others
compound statements that return a value. For instance:

({ int y = foo(); int z;
if (y>0) z = y; else z=-y;
z;
})
A block enclosed by braces can appear within parentheses
to form a block that "returns" a value. This is handy
in some macros, or in other applications.

Actually this construct is nothing more (and nothing less)
than anonymous functions.

Anonymous functions could be really handy in call to qsort,
for instance, where just writing an expression could allow
the compiler to expand the anonymous function at each point of
call (as an inline function) within the qsort algorithm.

No, GNU C's compound statements are not anonymous functions, because
they don't take arguments. How would you write a call to qsort()
using a compound statement in place of the compar argument? How would
the compound statement obtain the values to be compared?

I suppose GNU C's compound statements could be extended to act like
anonymous functions, but that's not what's being proposed.

This, and other extensions are published in a document
"Potential Extnsions for Inclusion in a revision of
ISO/EIC 98/99" available at

http://www.open-std.org/jtc1/sc22/wg...docs/n1229.pdf

That is the official standard site.

Other Gnu extensions are mentioned in that document, like typeof
for instance, an extension that also lcc-win32 implements.

This would be more appropriate for comp.std.c. I have some comments
on the document; if you post there, I'll reply.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

jacob navia said:

<snip>

Other Gnu extensions are mentioned in that document, like typeof
for instance, an extension that also lcc-win32 implements.

If your articles were not so often thinly-veiled advertisements for your
product, perhaps people might take them a little more seriously.

Note that C does not have anonymous functions. If you want to add
anonymous functions to standard C, comp.std.c is the appropriate
newsgroup in which to suggest it.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <-Z************** *************** *@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>Note that C does not have anonymous functions. If you want to add
anonymous functions to standard C, comp.std.c is the appropriate
newsgroup in which to suggest it.

But if you want to discuss what anonymous functions might be like, how
they would fit in with the rest of C and so on, without considering
whether it is appropriate to standardise them, then comp.lang.c seems
a reasonable choice.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>No, GNU C's compound statements are not anonymous functions, because
they don't take arguments. How would you write a call to qsort()
using a compound statement in place of the compar argument? How would
the compound statement obtain the values to be compared?

>I suppose GNU C's compound statements could be extended to act like
anonymous functions, but that's not what's being proposed.

Anonymous functions are almost always going to be *nested* functions,
which opens the whole can of worms concerning non-local variables.
Can these functions refer to, and modify, variables in the containing
function? What happens if you return the functions to outside the
scope of the containing function?

GNU C already has nested (non-anonymous) functions, so they must have
addressed these questions.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Heathfield]

Richard Tobin said:

In article <-Z************** *************** *@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>>Note that C does not have anonymous functions. If you want to add
anonymous functions to standard C, comp.std.c is the appropriate
newsgroup in which to suggest it.

But if you want to discuss what anonymous functions might be like, how
they would fit in with the rest of C and so on, without considering
whether it is appropriate to standardise them, then comp.lang.c seems
a reasonable choice.

Would I be right in thinking that the GNU syntax for assigning a value
to a compound statement could be adopted (and whether that's desirable
or not is not a question I am addressing here) without actually
breaking any existing code?

For the record, AIUI the GNU syntax for this is that the compound
statement ends in a single expression whose value is taken as the value
of the whole statement, as the following code fragment (which is not
valid C) illustrates:

double area = { double a = r * r * pi; a; }

That's a lousy example, though, because it's so pointless. I spent a few
moments trying to think up a genuine use for these things, and didn't
manage it. Of course, that doesn't mean there isn't one.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <uI************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>Would I be right in thinking that the GNU syntax for assigning a value
to a compound statement could be adopted (and whether that's desirable
or not is not a question I am addressing here) without actually
breaking any existing code?

As far as I'm aware.

>double area = { double a = r * r * pi; a; }

That's a lousy example, though, because it's so pointless. I spent a few
moments trying to think up a genuine use for these things, and didn't
manage it. Of course, that doesn't mean there isn't one.

I imagine that one reason why uses of this are not obvious is just
that in C (unlike Lisp) it's not traditional to write things as nested
multi-line expressions, and that in turn is because at present you
can't generally do it. Allowing compound statements to return values
(and of course allowing them to appear in expressions) would make C
into an "expression language", and it would then be able to adopt the
idioms of such languages.

Without going that far, one obvious use is in macros, since it allows
you introduce new variables in the macro expansion. Of course, you
then run into the question of what's a safe name for those variables
(in Lisp, you traditionally use gensym to generate a variable name,
but that requires a more powerful macro language). Many of the macro
uses can be more cleanly solved with inline functions, but others
depend on being able to access variables that aren't arguments to the
function or macro.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:
[...]

Without going that far, one obvious use is in macros, since it allows
you introduce new variables in the macro expansion. Of course, you
then run into the question of what's a safe name for those variables
(in Lisp, you traditionally use gensym to generate a variable name,
but that requires a more powerful macro language). Many of the macro
uses can be more cleanly solved with inline functions, but others
depend on being able to access variables that aren't arguments to the
function or macro.

I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Keith Thompson wrote:

ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:
[...]

Without going that far, one obvious use is in macros, since it allows
you introduce new variables in the macro expansion. Of course, you
then run into the question of what's a safe name for those variables
(in Lisp, you traditionally use gensym to generate a variable name,
but that requires a more powerful macro language). Many of the macro
uses can be more cleanly solved with inline functions, but others
depend on being able to access variables that aren't arguments to the
function or macro.

I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

#define my_abs(x) ({ int y = x; y 0 ? y : -y; })

would fail if called as my_abs(y).

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>I don't think variable names are an issue. A compound statement
creates a new scope, even if it's the result of a macro expansion.

But because names in a new scope can shadow outer ones, you have the
problem of inadvertent "variable capture", for example:

#define macro(x) {int t = (x)*2; ...}
...
int t;
macro(t+4);

There are obvious conventions to reduce the problem, but these are
likely to fail if you might have nested macro calls.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.