3 ms·

It is a little unfortunate that one of the few (or only) underlying abstraction of the machine that C chose to leave out was that of coroutines. I find this rat

by srean 12y ago

It is a little unfortunate that one of the few (or only) underlying abstraction of the machine that C chose to leave out was that of coroutines. I find this rather ironic because I have been told that PDPs, the virtual machine model that C is based on, had instruction level support for exchanging control very efficiently. I have also heard that VMs like LLVM aren't that good at portably exposing efficient exchange of control between stack frames (please correct me if I am wrong here). Since C is the implementation medium for many other languages coroutines did not get as much visibility as it should have. I can only speculate why C left it out. Perhaps it was felt that it wont port too well outside of the PDP family. The other reason could be that coroutine as an abstraction completely leaves out how they ought to be scheduled. Perhaps they did not want to flesh out a schedule that would be portable everywhere. It is not a very satisfactory explanation because C wasnt that shy to leave things undefined. I think the only way to get an answer to this question is to go to the source, that would be Ken Thompson or Brian Kernighan.

jeffreyrogers 12y ago
It may be because of implementation complexity? C was designed with the compiler writer in mind (which is why so many things are undefined... to make it easier for compiler writers), so if co-routines are hard to implement then that might be an explanation. Anyways that's mostly pure speculation on my part.
- srean 12y ago
  ...but thats the thing, on the PDP the crux of it was essentially one instruction. May be the worry was that porting this to other architectures of the time wasnt feasible or easy.
  - ANTSANTS 12y ago
    My guess is that, in light of the insanely limited memories of the machines they were working with, they had to leave out any feature that wasn't absolutely necessary. Maybe the benefits of coroutines weren't as obvious then, or maybe they didn't seem to mesh well with the rest of UNIX ("why not just fork") Then, when UNIX and C exploded into far bigger things than they had probably ever dreamed of, it was too late. I think C would be a very different language if you had explicitly given Dennis Ritchie the task of writing the eternal lingua franca of programming with at least 80's-level computing resources at his disposal, but that's history for you.

by srean 12y ago

jeffreyrogers 12y ago

It may be because of implementation complexity? C was designed with the compiler writer in mind (which is why so many things are undefined... to make it easier for compiler writers), so if co-routines are hard to implement then that might be an explanation. Anyways that's mostly pure speculation on my part.

srean 12y ago
...but thats the thing, on the PDP the crux of it was essentially one instruction. May be the worry was that porting this to other architectures of the time wasnt feasible or easy.
- ANTSANTS 12y ago
  My guess is that, in light of the insanely limited memories of the machines they were working with, they had to leave out any feature that wasn't absolutely necessary. Maybe the benefits of coroutines weren't as obvious then, or maybe they didn't seem to mesh well with the rest of UNIX ("why not just fork") Then, when UNIX and C exploded into far bigger things than they had probably ever dreamed of, it was too late. I think C would be a very different language if you had explicitly given Dennis Ritchie the task of writing the eternal lingua franca of programming with at least 80's-level computing resources at his disposal, but that's history for you.