Objective C blocks

[Tim Rentsch]

[closures as call-back functions]

Closures are more elegant, but ultimately anything you can do with a
closure you can do with a function pointer and a data pointer.

Ultimately anything you can write in C you can write on a
Turing Machine. Are you saying anything more than that it's
possible to compute any computable function in any Turing
complete language?

Function pointer plus data pointer is not as useful or as
usable as closures if the type of the function pointer is
fixed and it takes no arguments, to name just one example.

 

[Nobody]

[closures as call-back functions]

Closures are more elegant, but ultimately anything you can do with a
closure you can do with a function pointer and a data pointer.

Ultimately anything you can write in C you can write on a
Turing Machine. Are you saying anything more than that it's
possible to compute any computable function in any Turing
complete language?

Function pointer plus data pointer is not as useful or as
usable as closures if the type of the function pointer is
fixed and it takes no arguments, to name just one example.

The type of the function pointer is always fixed; C doesn't support
parametric types.

All it comes down to is that, if you write a function that uses a function
pointer, it should be paired with a data pointer. Libraries which use
callbacks extensively invariably do this. Unfortunately, the ANSI/ISO C
folks screwed the pooch with qsort() and bsearch() (it could be
useful for atexit(), but there are alternatives; I can't see that
it would be particularly useful for signal()).

 

[lawrence.jones]

All it comes down to is that, if you write a function that uses a function
pointer, it should be paired with a data pointer. Libraries which use
callbacks extensively invariably do this. Unfortunately, the ANSI/ISO C
folks screwed the pooch with qsort() and bsearch() (it could be
useful for atexit(), but there are alternatives; I can't see that
it would be particularly useful for signal()).

That particular pooch was screwed long before there were any ANSI/ISO C
folks.

 

[Tim Rentsch]

[closures as call-back functions]

Closures are more elegant, but ultimately anything you can do with a
closure you can do with a function pointer and a data pointer.

Ultimately anything you can write in C you can write on a
Turing Machine. Are you saying anything more than that it's
possible to compute any computable function in any Turing
complete language?

Function pointer plus data pointer is not as useful or as
usable as closures if the type of the function pointer is
fixed and it takes no arguments, to name just one example.

The type of the function pointer is always fixed; C doesn't support
parametric types.

I think you've missed the meaning of what I was saying.
What I meant was, if the type of the function parameter expected
can't be changed to accommodate an additional data pointer
argument.

All it comes down to is that, if you write a function that uses a function
pointer, it should be paired with a data pointer. [snip]

It's usually possible to do that when writing new code.
Sometimes it isn't when trying to retrofit existing code
(as you point out). Having real closures could make
both problems go away.

 

[Nobody]

All it comes down to is that, if you write a function that uses a function
pointer, it should be paired with a data pointer. [snip]

It's usually possible to do that when writing new code.
Sometimes it isn't when trying to retrofit existing code
(as you point out). Having real closures could make
both problems go away.

But having "real closures" typically just amounts to redefining "function
pointer" to mean a (raw) function pointer paired with a data pointer.

Actually creating new functions at run-time in a compiled language is
somewhere between difficult and impossible (modern OSes may disallow
generating code at run time as a safety measure).

 

[Tim Rentsch]

All it comes down to is that, if you write a function that uses a function
pointer, it should be paired with a data pointer. [snip]

It's usually possible to do that when writing new code.
Sometimes it isn't when trying to retrofit existing code
(as you point out). Having real closures could make
both problems go away.

But having "real closures" typically just amounts to redefining "function
pointer" to mean a (raw) function pointer paired with a data pointer.

Actually creating new functions at run-time in a compiled language is
somewhere between difficult and impossible (modern OSes may disallow
generating code at run time as a safety measure).

No kidding, somewhere between difficult and impossible...
How do you suppose all those compiled languages that
have closures manage to do it?