Lambda the Ultimate

Everything you need to know about 'C can be found at Poletto's tcc page I linked to in the story; in particular for trying the language out, that tcc doesn't target x86, isn't currently maintained, and that 'C isn't supported, so far as I know, by any other compiler.

The best paper for introducing the language is:

‘C: A Language for High-Level, Efficient, and Machine-Independent Dynamic Code Generation (1996). Dawson R. Engler, Wilson C. Hsieh, and M. Frans Kaashoek. In Proc. 23rd POPL conference.

It would be excellent if someone were to take tcc under their arm and target x86, or add 'C support to another compiler...

...Clang and LLVM would seem to be natural building-blocks for a modern re-implementation of `C.

...Clang and LLVM would seem to be natural building-blocks for a modern re-implementation of `C.

I certainly thought of this, although I guess there would be more work to support 'C for Clang than to add x86 as a target for VCODE, the VM behind tcc, because the runtime for 'C has to be able to dynamically compile C code, and the tradeoffs characterising a good dynamic compiler are quite different to those for a good static compiler.. VCODE appears to do well, according to the discussion in:

Dawson Engler (1996). VCODE: a retargetable, extensible, very fast dynamic code generation system. In Proc. conf. PLDI '96.

There actually was an x86 implementation for VCODE at one time.

I don't think VCODE is all that different from GNU Lightning. The latter supports x86 and x86-64 on svn, so it's definitely out there.

Incidentally, the GNU lightning manual says VCODE "directly inspired gnu lightning", for avoiding an intermediate representation.

A problem with VCODE -- bad enough that I felt the PLDI committee was asleep at the switch on that paper -- was that the "11-12 instructions per target instruction" was nonsense. That number assumed no buffer overrun check. But that issue aside, VCODE was good work.

When I looked at GNU lightning, it did seem to me that the register models were a bit different, and that the GNU lightning approach might not be as amenable to fast+good code generation.

For those interested, description of the feature here.

C++0x will, AFAIK, support every useful programming-language feature available to a multi-paradigm, impure language. They really need to learn when and where to stop.

One minor disadvantage with nested functions as defined by GNU C is that they sometimes cause some common syntax errors - a missing closing curly bracket, for instance - to be reported far away from the actual source of the error and in a way that may be difficult to understand, even if nested functions are never used.

While I agree that Gcc's nested functions are nice, they do make the code less portable, and sometimes considerably less efficient. The reason is that on may platforms, expensive cache flushing instructions - sometimes even system calls! - are inserted where the trampolines are generated, to guarantee cache coherence.

On platforms where C function pointers do not point to the code directly but to a descriptor (a small structure containing a code pointer and one or more data pointers, typically to constant pools), this is not a problem because only a descriptor needs to be generated, no executable code. This is of course (more or less) how blocks in Clang work.

That is not true sorry, C still evolving and almost everything it's made in C, as OS's kernels, Web server's, Networking Systems, Games, Office suit's, Desktop's Managers, mobile phones, Embedded Systems(wash machines, satellites, cars, GPS's), Programming languages, Compiler's, etc.

I'm not sure why people look at C++, I was a C++ programmer but I don't do it anymore, it's an abomination of programming language and too complex for mortals.

C is much more simple to understand and program, it's compact and it have the power and with closures will rock so I think C still evolving, About OOP it is not a panacea, Anyway you can do OOP with C if you really need it or take Java or Python or even Lisp with CLOS it is much better solution and more healthy.

Regards.

The style of the above post is unacceptable on LtU.

Regardless of whether or not C should even have a stack, it shouldn't have automagic migration from stack to heap combined with reference counting -- there are alternatives and programmers should be free to pick among them and implement what they need.

All that's really needed for the essence is a structure-like family of types whose pointers can be cast to function pointers and back again, combined with a way to write anonymous functions in the scope of the closure.

I agree with both these points; I'm sorry to say, though, that I can't follow your illustrative pseudocode. Could you explain what exactly is meant to happen when I make a declaration of the form "struct foo_closure ...", and what role the instance a_cl is meant to play?

I agree with both these points; I'm sorry to say, though, that I can't follow your illustrative pseudocode. Could you explain what exactly is meant to happen when I make a declaration of the form "struct foo_closure ...", and what role the instance a_cl is meant to play?

Sorry, I hoped that would be clear and I also made a mistake.

The pseudo-code fails to use a_cl. A draft did use a_cl but I edited out all but that declaration. So it is a dead variable. a_cl is just an accidental red herring and we can ignore it. Very sorry.

The other question: what does it mean to declare a structure "struct foo int (*) (int x)": that was what I was trying to show by illustration.

Essentially, the function prototype added after the structure type name indicates that the structure begins with an implicit field, dubbed "()" as in "result.() = ...". The implicit field contains a pointer to code.

Suppose we are given a pointer to such a structure. In the pseudo-code, the expression "&test" is such a pointer. We can use that pointer in two ways illustrated by "test->y" to refer to the closed over value of of y and "test(42)" to call the code pointed at by the implicit ".()" field passing the pointer "&test" as an implicit paramter.

Before I posted this reply, user "naasking" made the comment just below. He's got it right (and I've a reply to his comment that I'll post in a moment). This *does* basically represent a change in calling conventions in C but the change isn't so bad... it's an upwards-compatible extension, so to speak.

-t

I don't see how this would work. The struct arguments must be passed to the function pointer unless you're using code generation to propagate the struct arguments into the function body at the time of definition.

Otherwise, all closures require an additional parameter, the environment, where ordinary functions don't. Unless you're suggesting that C change all functions calls to be called with an extra environment parameter, and ordinary function pointer just pass an empty environment. Not sure that would fly with most C users.

Yes, I'm suggesting a change to the calling convention and this new implicit paramter. I also suggested ( :-) that C would be *even better* if we also eliminated the implicit stack pointer parameter. So, I'll take one new implicit param in the calling convention and happily give up the one that's already there. Hmm. Darn it, you've given me an idea.... [to go work on, not burble about here, today].

I never claimed that most C users would be instantly excited by this :-)

-t

Ah, so this calling convention is only for calls via function pointers then? I can see difficulties with repeated closure application since C allows arbitrary mutation of arguments. If taking a function pointer implicitly allocates a frame for all of its arguments, then partial application also becomes doable with only a type coercion. There are perhaps difficulties with pointer arguments to stack allocated data though. It does have some interesting possibilities.

[Edit: I meant partial application, not currying.]

I'm not certain I get you naasking but we can make things more concrete:

A decl like "struct foo int (*) (int)" describes a structure with a code pointer in the ".()" field, plus any additional fields described in the structure body.

Suppose I have a variable x declared "struct foo x;". Then "&x" is a pointer to the stack or heap or global variables -- wherever x is declared. That pointer can be used in ordinary ways like "x->y" to refer to the "y" field of the structure.

The pointer "&x" can be cast to a function pointer of type "int (*) int". When calling a function through that pointer, the ".()" field of the structure is used to find the function to actually transfer control to and the structure pointer itself ("&x") is added as an extra parameter. So, the code pointed to has, in some sense, the type "int (*) (struct foo *, int)".

The simplest calling convention change is to say that for all normal functions (not closures) an expression like "&fn" doesn't return the address of the code directly -- it returns a pointer to a static, constant structure associated with the function fn. That static constant struture has a type like: "struct fn_type int (*) (int) {};" In other words, it is a closure with nothing closed over -- just the code pointer.

So, yes... you can do partial application. Yes, there are perhaps difficulties with poitner arguments to stack allocated closures.

The mechanism is "just enough" to give the essence of closures (through C eyes) but not so much as to impose memory mgt. policy etc. It's "just enough" that if it were present people would be *scrambling* for something better than CPP as fast as they could. :-)

-t

The way I imagined it (not in the context of C), the implicit context would be either a pointer to the stack or a pointer to a heap-allocated region. The allocation would occur when the function pointer escapes the current function scope.

In either case data would be laid out the same way in memory.