3 ms·

The reason this is a really good idea is because is sometimes needed in the real world and with PNVI-ae-udi is just works. Also the alternative models have hor

by uecker 2y ago

The reason this is a really good idea is because is sometimes needed in the real world and with PNVI-ae-udi is just works. Also the alternative models have horrible semantics, e.g. either because you have provenance via integers (where algebraic properties of mathematics breaks) or because you get really subtle semantics that is hard to reason about (all the angelic / demonic indeterminism ideas).

tialaramex 2y ago
Are you telling me that, if you could start over somehow, you'd suggest K&R should specify PNVI-ae-udi ? Or do you mean (which I accept) only that well, too bad, PNVI-ae-udi is the best we could do with C given where we started from 20+ years ago? I actually think there's yet significant risk that this is swamped by the "Bag of bits" people despite all your hard work. There are plenty of WG21 submissions whose subtext can be read that way, they want their "high level assembler" and they don't care that it's a myth and can't be made real, they're not taking "No" for an answer. So, congratulations on the TS.
- uecker 2y ago
  I actually think PNVI-ae-udi is pretty good semantic model for a systems programming language, considering that it is the essentially only reasonable model on how to combine abstract pointers with low-level integer based pointers in a way that makes it work well. I am not entirely sure I would allow one-after points if I were to design a language from scratch, but I haven't made up my mind about it.
  - tialaramex 2y ago
    While it makes sense that you landed on PNVI-ae-udi for C because of its prior baggage, I don't see how this makes a good choice for a language without that baggage. For one thing, I'm pretty sure systems languages don't need to combine these two ideas at all. In C there's a single pointer type and so it has both uses too bad, but in a hypothetical new language you don't need to do that and I think it would be clearer not to.
    - uecker 2y ago
      I am not sure what you mean by "baggage", "two ideas" etc. If you boil it down to how computers work and want to have an abstract pointer model at the same time, there is not much design space left.
      - tialaramex 2y ago
        The good news is that you already listed the two separate ideas. In C you need to have a single type which embodies both contradictory ideas, but that's actually a choice, albeit one it's far too late for C to change now. The fact that choices you made in the past can't subsequently be changed is baggage. Even if you decide tomorrow that this was a waste of your time and you should never have worked on the provenance problem, you can't have that time back. [that's an example of personal baggage, in the case of C the early choice to only have the single type for both purposes is the baggage]

by uecker 2y ago

tialaramex 2y ago

Are you telling me that, if you could start over somehow, you'd suggest K&R should specify PNVI-ae-udi ? Or do you mean (which I accept) only that well, too bad, PNVI-ae-udi is the best we could do with C given where we started from 20+ years ago? I actually think there's yet significant risk that this is swamped by the "Bag of bits" people despite all your hard work. There are plenty of WG21 submissions whose subtext can be read that way, they want their "high level assembler" and they don't care that it's a myth and can't be made real, they're not taking "No" for an answer. So, congratulations on the TS.

uecker 2y ago
I actually think PNVI-ae-udi is pretty good semantic model for a systems programming language, considering that it is the essentially only reasonable model on how to combine abstract pointers with low-level integer based pointers in a way that makes it work well. I am not entirely sure I would allow one-after points if I were to design a language from scratch, but I haven't made up my mind about it.
- tialaramex 2y ago
  While it makes sense that you landed on PNVI-ae-udi for C because of its prior baggage, I don't see how this makes a good choice for a language without that baggage. For one thing, I'm pretty sure systems languages don't need to combine these two ideas at all. In C there's a single pointer type and so it has both uses too bad, but in a hypothetical new language you don't need to do that and I think it would be clearer not to.
  - uecker 2y ago
    I am not sure what you mean by "baggage", "two ideas" etc. If you boil it down to how computers work and want to have an abstract pointer model at the same time, there is not much design space left.
    - tialaramex 2y ago
      The good news is that you already listed the two separate ideas. In C you need to have a single type which embodies both contradictory ideas, but that's actually a choice, albeit one it's far too late for C to change now. The fact that choices you made in the past can't subsequently be changed is baggage. Even if you decide tomorrow that this was a waste of your time and you should never have worked on the provenance problem, you can't have that time back. [that's an example of personal baggage, in the case of C the early choice to only have the single type for both purposes is the baggage]