5 ms·

I still wonder why C still does’t have lambas implemented by standard. I understand its a quite slow moving language but it would make programming in it mich ni

I still wonder why C still does’t have lambas implemented by standard. I understand its a quite slow moving language but it would make programming in it mich nicer (see C++11) Are there anh underlying ‘issues’ with lambdas, I wonder?

Gibbon1 7y ago
Having kicked this around I think two problems. One: Compiler development is driven by the C++ standards committee. And they all hate C and wish it would die already. More to the point things you would do to make C a better more powerful language are orthogonal to the direction C++ is being pushed. Two: Being tied to C++ also means being tied to the same ABI as C++. And improvements to the C language probably would need some extensions to the ABI. Three: I can't wrap my head around this but a lot of people are extremely hostile to attempts to extend and improve C.
- jcranmer 7y ago
  > One: Compiler development is driven by the C++ standards committee. And they all hate C and wish it would die already. The latter statement is not true. But it is true that most of the evolution of C/C++ is driven by the C++ committee, with the C committee mostly adapting features from C++ and very little innovation in C being adapted for C++. (As one C++ committee member confided to me, the C committee does have a bit of a tendency to completely screw things up when the C++ committee liaisons leave the room). But there is still coordination and cooperation between the committees--for example, the recent proposals to replace the current EH model in C++ includes a coordinating proposal to modify the C ABI to provide access to a Result-esque exception model. > Two: Being tied to C++ also means being tied to the same ABI as C++. And improvements to the C language probably would need some extensions to the ABI. The C ABI desperately needs extensions anyways, especially because it is the de facto platform ABI and languages usually only support FFI features using the C ABI. The biggest missing features here are SIMD vector support and multiple return value support.
  - Gibbon1 7y ago
    I apologize for the slight against the C++ standard people. I do like your comment about the ABI needing to be extended to improve FFI features. I feel that way too. Also think that a clean (non clunky) method for FFI is exactly what C has needed for a long time.
- klingonopera 7y ago
  Regarding three, I believe it's because C ultimately aims to be the most low-level, high-level abstraction of machine code. Stray too far from that, and you're already in C++ territory. Except for multi-core/-threading support, I can't really think of anything that has changed in the past 25 years to add to this, in my opinion, essentially near-perfect language.
  - fao_ 7y ago
    Every single SYSV x64 ABI platform supports at least two uint64_t return values, which are the registers rdi and rax (Actually it might be rbx, I haven't done assembly for a while). So C is behind of the curve. C is considered to be "High level assembly", up until it isn't. To be honest, YASM and other assemblers do "high level assembly" much better. C is a simple, flexible low-level language. There is a feeling about C that I do not get from other languages, a specific way of thinking and a trend towards simplicity of feature (Ignoring GNU) that other languages (including rust) do not encourage or notice. It would be nice to see it importing some of the type semantics of ML and OCaml.
    - saagarjha 7y ago
      > Every single SYSV x64 ABI platform supports at least two uint64_t return values, which are the registers rdi and rax (Actually it might be rbx, I haven't done assembly for a while). For integer returns, System-V uses rax/rdx.
      - fao_ 7y ago
        Ah! Yes, of course :)
jjtheblunt 7y ago
Perhaps because Go does this properly, where by properly I mean that you can have both stack and heap allocations of scope local variables, depending upon their needed availability for functions within the scope and dissociation , from the scope, of their lifetimes? In particular, the Go compiler performs escape analysis to determine where variables must be allocation, in honor of upward funargs.
- wahern 7y ago
  Go also has no way to catch memory allocation failure. Many things become easier when you can pretend memory is infinite, especially from a language design standpoint. As C++ has been contemplating moving away from exceptions, they've effectively been forced to choose between concise language abstractions or strict memory management. They seem to be moving toward the former, which is to say C++ may soon begin to behave like Go, Perl, and other high-level languages--OOM will simply crash your application.
  - jcranmer 7y ago
    > As C++ has been contemplating moving away from exceptions, they've effectively been forced to choose between concise language abstractions or strict memory management. They seem to be moving toward the former You don't need exception handling to handle memory allocation failure: just make your allocator return null (that's what new (nothrow) X does, after all). The question of how to handle allocation failure is easily the single most divisive question presented in the proposal, and in the face of stark division, status quo usually wins the day.
    - deleted 7y ago
      [deleted]
jcranmer 7y ago
> Are there anh underlying ‘issues’ with lambdas, I wonder? A lambda object is intrinsically an object with an unnameable type and an overloaded call operator. C doesn't have any mechanisms for parameterizing function bodies over types, or even any mechanism for defining a variable without declaring its type (although one is suggested for C2x). Without such mechanisms, it's impossible to actually use a lambda.
- saagarjha 7y ago
  > A lambda object is intrinsically an object with an unnameable type and an overloaded call operator. This sounds like a really restrictive, C++-centric way of defining lambdas…
  - jcranmer 7y ago
    Not really. It's true for any language where types have statically-shaped memory layouts, and where names are statically bound. Lambdas need to bind their names to locations; if this is to be done statically, then the bound names need to packed into some reference type. The type of the bound name environment cannot be named, because it is dependent on what specifically the environment is naming. Languages that fall into this category would include C, C++, Java, C#, and Rust. By contrast, languages such as Python or JavaScript that rely on dynamic name binding have implicit environment objects attached to their objects that allow different lambdas to share the same type, since the function body gets to acquire a map that it can ask for the bound names.
    - saagarjha 7y ago
      > the bound names need to packed into some reference type Exactly, and that's how we refer to them. We already do the same for arrays–it would be overly pedantic to refuse to call an address/size pair an array because it doesn't actually contain the elements it refers to, just as statically-typed languages with lambdas are actually just passing pointers around. C could do this too–we'd just need sugar that would convert lightweight lambda syntax into code somewhere that would have the same type as a function pointer.
0x09 7y ago
Apple did submit a proposal based on the then-new blocks extension in 2010: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf There was an analysis of this and the C++11 lambda specification done shortly after at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1483.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1483.htm, but it was inconclusive and there doesn't seem to have been any followup since then.

Gibbon1 7y ago

Having kicked this around I think two problems. One: Compiler development is driven by the C++ standards committee. And they all hate C and wish it would die already. More to the point things you would do to make C a better more powerful language are orthogonal to the direction C++ is being pushed. Two: Being tied to C++ also means being tied to the same ABI as C++. And improvements to the C language probably would need some extensions to the ABI. Three: I can't wrap my head around this but a lot of people are extremely hostile to attempts to extend and improve C.

jcranmer 7y ago
> One: Compiler development is driven by the C++ standards committee. And they all hate C and wish it would die already. The latter statement is not true. But it is true that most of the evolution of C/C++ is driven by the C++ committee, with the C committee mostly adapting features from C++ and very little innovation in C being adapted for C++. (As one C++ committee member confided to me, the C committee does have a bit of a tendency to completely screw things up when the C++ committee liaisons leave the room). But there is still coordination and cooperation between the committees--for example, the recent proposals to replace the current EH model in C++ includes a coordinating proposal to modify the C ABI to provide access to a Result-esque exception model. > Two: Being tied to C++ also means being tied to the same ABI as C++. And improvements to the C language probably would need some extensions to the ABI. The C ABI desperately needs extensions anyways, especially because it is the de facto platform ABI and languages usually only support FFI features using the C ABI. The biggest missing features here are SIMD vector support and multiple return value support.
- Gibbon1 7y ago
  I apologize for the slight against the C++ standard people. I do like your comment about the ABI needing to be extended to improve FFI features. I feel that way too. Also think that a clean (non clunky) method for FFI is exactly what C has needed for a long time.
klingonopera 7y ago
Regarding three, I believe it's because C ultimately aims to be the most low-level, high-level abstraction of machine code. Stray too far from that, and you're already in C++ territory. Except for multi-core/-threading support, I can't really think of anything that has changed in the past 25 years to add to this, in my opinion, essentially near-perfect language.
- fao_ 7y ago
  Every single SYSV x64 ABI platform supports at least two uint64_t return values, which are the registers rdi and rax (Actually it might be rbx, I haven't done assembly for a while). So C is behind of the curve. C is considered to be "High level assembly", up until it isn't. To be honest, YASM and other assemblers do "high level assembly" much better. C is a simple, flexible low-level language. There is a feeling about C that I do not get from other languages, a specific way of thinking and a trend towards simplicity of feature (Ignoring GNU) that other languages (including rust) do not encourage or notice. It would be nice to see it importing some of the type semantics of ML and OCaml.
  - saagarjha 7y ago
    > Every single SYSV x64 ABI platform supports at least two uint64_t return values, which are the registers rdi and rax (Actually it might be rbx, I haven't done assembly for a while). For integer returns, System-V uses rax/rdx.
    - fao_ 7y ago
      Ah! Yes, of course :)

jjtheblunt 7y ago

Perhaps because Go does this properly, where by properly I mean that you can have both stack and heap allocations of scope local variables, depending upon their needed availability for functions within the scope and dissociation , from the scope, of their lifetimes? In particular, the Go compiler performs escape analysis to determine where variables must be allocation, in honor of upward funargs.

wahern 7y ago
Go also has no way to catch memory allocation failure. Many things become easier when you can pretend memory is infinite, especially from a language design standpoint. As C++ has been contemplating moving away from exceptions, they've effectively been forced to choose between concise language abstractions or strict memory management. They seem to be moving toward the former, which is to say C++ may soon begin to behave like Go, Perl, and other high-level languages--OOM will simply crash your application.
- jcranmer 7y ago
  > As C++ has been contemplating moving away from exceptions, they've effectively been forced to choose between concise language abstractions or strict memory management. They seem to be moving toward the former You don't need exception handling to handle memory allocation failure: just make your allocator return null (that's what new (nothrow) X does, after all). The question of how to handle allocation failure is easily the single most divisive question presented in the proposal, and in the face of stark division, status quo usually wins the day.
  - deleted 7y ago
    [deleted]

jcranmer 7y ago

> Are there anh underlying ‘issues’ with lambdas, I wonder? A lambda object is intrinsically an object with an unnameable type and an overloaded call operator. C doesn't have any mechanisms for parameterizing function bodies over types, or even any mechanism for defining a variable without declaring its type (although one is suggested for C2x). Without such mechanisms, it's impossible to actually use a lambda.

saagarjha 7y ago
> A lambda object is intrinsically an object with an unnameable type and an overloaded call operator. This sounds like a really restrictive, C++-centric way of defining lambdas…
- jcranmer 7y ago
  Not really. It's true for any language where types have statically-shaped memory layouts, and where names are statically bound. Lambdas need to bind their names to locations; if this is to be done statically, then the bound names need to packed into some reference type. The type of the bound name environment cannot be named, because it is dependent on what specifically the environment is naming. Languages that fall into this category would include C, C++, Java, C#, and Rust. By contrast, languages such as Python or JavaScript that rely on dynamic name binding have implicit environment objects attached to their objects that allow different lambdas to share the same type, since the function body gets to acquire a map that it can ask for the bound names.
  - saagarjha 7y ago
    > the bound names need to packed into some reference type Exactly, and that's how we refer to them. We already do the same for arrays–it would be overly pedantic to refuse to call an address/size pair an array because it doesn't actually contain the elements it refers to, just as statically-typed languages with lambdas are actually just passing pointers around. C could do this too–we'd just need sugar that would convert lightweight lambda syntax into code somewhere that would have the same type as a function pointer.

0x09 7y ago

Apple did submit a proposal based on the then-new blocks extension in 2010: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1451.pdf There was an analysis of this and the C++11 lambda specification done shortly after at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1483.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1483.htm, but it was inconclusive and there doesn't seem to have been any followup since then.