Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

[Vincent Lefevre]

On 2015-04-13 06:57:00 +0200, Christian Jullien wrote:
> Good luck for nested function implementers that (as is Lisp :o) will
> want to make this code working!

Despite some users want C to be like LISP here, it must not be like in
LISP. In C, a function is not an object, thus in particular, you have
no closures in C. And introducing nested functions (as in GCC) won't
change that. And one doesn't want closures anyway as they would yield
an incompatibility with ISO C when writing (using global variables
and functions):

int i = 17;
int foo (void) { return i; }

Here one mustn't assume that 17 will be returned. The value of an
external variable inside a function body is the value at the function
call (or the modified value by the function itself if the variable is
modified by the function), not the value when the function was
defined like in LISP.

> typedef int (*fp) (uint32_t i);
> 
> int
> callback(fp fn, uint32_t i)
>       fn(i);{
> }
> 
> uint32_t
> isEven(uint32_t i) {
>       uint32_t odd(uint32_t i) {
>               if (i == 0) return 0;
>               if (i == 1) return 1;
>               retrun even(i - 1);
>       }
>       uint32_t even(uint32_t i) {
>               if (i == 0) return 1;
>               if (i == 1) return 0;
>               retrun odd(i - 1);
>       }
>       callback(even, i);
> }

There are several typos. There's also the fact that even() is not
declared. You need to add:

  auto uint32_t even(uint32_t i);

before the definition of odd(). After this being fixed, I don't see
any problem. This is not like if you were using lexical scoping to
access variables defined in isEven (in your example, the variable i
is passed as an argument to odd() and even(), so this doesn't
introduce a problem). But using lexical scoping after the function
exits would be a programming error (like with GCC's specification
of nested functions), just like:

int *foo (void)
{
  int i;
  return &i;
}

> C is not prepared to support nested function unless you rewrite whole
> calling convention mechanism that will break all known libraries.

I think that the main problem is that there are several ways to
specify nested functions. GCC has its own specification. Perhaps
other compilers that also support them as an extension have a
different one. In any case, the use of nested functions is rather
limited as non standard.

FYI, GNU MPFR uses nested functions when some specific feature
(logging) is enabled, but only because of other C extensions
implemented by GCC and compatible compilers, like destructors.

I would say that nested functions *alone* are not very useful, and
to make them useful in practice would be to implement other GCC
extensions, but this is much more work.

-- 
Vincent Lefèvre <address@hidden> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)