6 ms·

Hmm, I am not sure what to think. I read through it, but C being able to call C++ functions and handle errors would be nice. However, it does add things to bot

by anfilt 8y ago

Hmm, I am not sure what to think. I read through it, but C being able to call C++ functions and handle errors would be nice. However, it does add things to both languages, and I generally think it's best to avoid adding things at all costs. It just makes things more complicated.

bluGill 8y ago
Some complexity is good and some is bad. In this case I would call it good - it makes the language more complex, but as a implementor of programs my code becomes simpler because a slightly more complex language makes my code simpler for an overall win.
- anfilt 8y ago
  I tend prefer minimalism. I tend to find a lot software abhorrent for complexities and bloat. Heck even standards keep getting more bloated. Also kinda wish the terminals/consoles were treated more of a first class citizen. However, so much stuff expects a GUI. Heck, I am not even that old only 26. Heck, if I could just use text based browser in the console, I probably would very rarely start up my desktop environment. Speaking of minimalism one of my favorite ISA's are OISCs. CISC vs RISC pff OISC man. Particularly Transport Triggered since it actually lends it's self to compile time parallelism pretty well. It's also the only type to have a processor built. It's kinda like a data flow machine but is not. https://en.wikipedia.org/wiki/One_instruction_set_computer#Transport_triggered_architecture_2 https://en.wikipedia.org/wiki/One_instruction_set_computer#T...
pjc50 8y ago
It also allows taking away a feature that requires complexity: POSIX errno, which is a thread-local variable.
xenadu02 8y ago
It trades false simplicity (errno) for explicit yet bounded implementation complexity, yielding a much simpler model for the programmer to actually use. There may be a fatal flaw but at first glance I like it.
- int_19h 8y ago
  IMO the biggest advantage of this proposal is that it'd make error reporting part of the C ABI, which still is - and is likely to remain - the common base for all kinds of FFI.
  - earenndil 8y ago
    Most languages will probably still do their own error reporting, so it will arguably not do very much, except make extra work for language maintainers to make their own error reporting coexist with the c type.
    - naasking 8y ago
      They already need to do that with errno, and this proposal would make error handling simpler, so it still seems like win.
    - int_19h 8y ago
      The point is that right now, that error reporting usually ends at the FFI boundary. But with this thing, it could be propagated across the boundary, in a standard way that the other side hopefully has a meaningful projection for. And if you cross the boundary twice (back and forth), and nothing in between handles the error, then it can even be propagated across both boundaries in a way that allows the original error to be preserved or reconstituted. So you could e.g. throw Python exceptions across C++ stack frames and catch them on the other side - and C++ would correctly execute destructors etc.

by anfilt 8y ago

bluGill 8y ago

Some complexity is good and some is bad. In this case I would call it good - it makes the language more complex, but as a implementor of programs my code becomes simpler because a slightly more complex language makes my code simpler for an overall win.

anfilt 8y ago
I tend prefer minimalism. I tend to find a lot software abhorrent for complexities and bloat. Heck even standards keep getting more bloated. Also kinda wish the terminals/consoles were treated more of a first class citizen. However, so much stuff expects a GUI. Heck, I am not even that old only 26. Heck, if I could just use text based browser in the console, I probably would very rarely start up my desktop environment. Speaking of minimalism one of my favorite ISA's are OISCs. CISC vs RISC pff OISC man. Particularly Transport Triggered since it actually lends it's self to compile time parallelism pretty well. It's also the only type to have a processor built. It's kinda like a data flow machine but is not. https://en.wikipedia.org/wiki/One_instruction_set_computer#Transport_triggered_architecture_2 https://en.wikipedia.org/wiki/One_instruction_set_computer#T...

pjc50 8y ago

It also allows taking away a feature that requires complexity: POSIX errno, which is a thread-local variable.

xenadu02 8y ago

It trades false simplicity (errno) for explicit yet bounded implementation complexity, yielding a much simpler model for the programmer to actually use. There may be a fatal flaw but at first glance I like it.

int_19h 8y ago
IMO the biggest advantage of this proposal is that it'd make error reporting part of the C ABI, which still is - and is likely to remain - the common base for all kinds of FFI.
- earenndil 8y ago
  Most languages will probably still do their own error reporting, so it will arguably not do very much, except make extra work for language maintainers to make their own error reporting coexist with the c type.
  - naasking 8y ago
    They already need to do that with errno, and this proposal would make error handling simpler, so it still seems like win.
  - int_19h 8y ago
    The point is that right now, that error reporting usually ends at the FFI boundary. But with this thing, it could be propagated across the boundary, in a standard way that the other side hopefully has a meaningful projection for. And if you cross the boundary twice (back and forth), and nothing in between handles the error, then it can even be propagated across both boundaries in a way that allows the original error to be preserved or reconstituted. So you could e.g. throw Python exceptions across C++ stack frames and catch them on the other side - and C++ would correctly execute destructors etc.