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/wg14/www/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]

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/wg14/www/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.

 

[Richard Heathfield]

jacob navia said:

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

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

 

[Richard Tobin]

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

 

[Richard Heathfield]

Richard Tobin said:

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

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

 

[Keith Thompson]

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.

 

[Guest]

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]

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

 

[jacob.navia]

Richard Tobin a écrit :
The expressions take arguments from the local context, as far as the
implementation of gNU is concerned.

This is not fully anonymous functions but a step in that direction.

Yes, it is not, but could be.

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.

As far as I remember their implementation is similar to pascal.
Nested functions take the environment where they are defined.

 

[Michal Nazarewicz]

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.

AFAIK, those statements where introduced to allow #defining /inline/
functions, like:

#define max(a, b) ({ int _a = (a), _b = (b); _a < _b ? _b : _a; })

 

[jacob.navia]

Richard Tobin a écrit :

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

There is only one solution:
make real anonymous functions with arguments, etc.

How would they look like in C?

 

[Richard Heathfield]

Michal Nazarewicz said:

AFAIK, those statements where introduced to allow #defining /inline/
functions, like:

#define max(a, b) ({ int _a = (a), _b = (b); _a < _b ? _b : _a; })

Well, this is another lousy example (sorry, Michal!) because it can be
done so easily in standard C:

#define max(a, b) (((a) > (b)) ? (a) : (b))

I'm sure this proposed new syntax must have a use, but I'm still
struggling to find one.

 

[jacob.navia]

Richard Heathfield a écrit :

Well, this is another lousy example (sorry, Michal!) because it can be
done so easily in standard C:

#define max(a, b) (((a) > (b)) ? (a) : (b))

I'm sure this proposed new syntax must have a use, but I'm still
struggling to find one.

Your example evaluates at least one argument twice. The example with the
GNU syntax doesn't.

Please read the contributions in this same thread

 

[Michal Nazarewicz]

Michal Nazarewicz said:

Well, this is another lousy example (sorry, Michal!) because it can be
done so easily in standard C:

#define max(a, b) (((a) > (b)) ? (a) : (b))

And what about:

int i = 1, j = 0;
int k = max(++i, j);

 

[Richard Heathfield]

jacob.navia said:

Richard Heathfield a écrit :

Your example evaluates at least one argument twice. The example with
the GNU syntax doesn't.

That is certainly true, but irrelevant unless the caller is abusing the
preprocessor by using macro arguments which oughtn't to be evaluated
more than once. If the motivation for anonymous functions is simply to
make it possible to abuse the preprocessor in comfort, then I don't see
the value. No doubt there are better uses.

 

[Richard Heathfield]

Michal Nazarewicz said:

And what about:

int i = 1, j = 0;
int k = max(++i, j);

Understood (multiple eval), but frankly I wouldn't go adding an entire
new language feature just to make extra work for myself when I can
already write this as:

int i = 2, j = 0, k = 2;

and in any case, the C community already knows not to risk such
expressions as yours when using macros. Are we going to muddy the
waters by introducing a language feature which makes it okay sometimes,
provided you're careful in the #define?

I don't see that as a win.

 

[Michal Nazarewicz]

Richard Heathfield a écrit :

jacob.navia said:

That is certainly true, but irrelevant unless the caller is abusing the
preprocessor by using macro arguments which oughtn't to be evaluated
more than once.

AFAIK that was the reason this syntax was introduced in GCC (though I
may be wrong).

If the motivation for anonymous functions is simply to
make it possible to abuse the preprocessor in comfort, then I don't see
the value. No doubt there are better uses.

Certainly it wouldn't make sens to introduce anonymous functions just
to allow abusing preprocessor as we have inline functions in C99.

IMO there's not much use for them anyway. The only thing I can think
of is:

qsort(array, sizeof array / sizeof *array, sizeof *array,
({ some kind of strange syntax }));

and it's not like one uses callback functions every 10th line of code.

 

[Richard Heathfield]

Michal Nazarewicz said:

Certainly it wouldn't make sens to introduce anonymous functions just
to allow abusing preprocessor as we have inline functions in C99.
Agreed.

IMO there's not much use for them anyway. The only thing I can think
of is:

qsort(array, sizeof array / sizeof *array, sizeof *array,
({ some kind of strange syntax }));

Interesting. Perhaps something like this:

{ :formal parameter list: { body goes here } value; }

and it's not like one uses callback functions every 10th line of code.

Yeah, this does look like a solution looking for a problem.