I don’t think I quite agree with that characterisation in a few ways:
C has a very, uh, complicated relationship with pointers. There’s a proposal for a provenance model for C pointers going through WG14 at the moment because it turns out that every C compiler has a provenance model, just not the same one. In C, pointers must be derived in some way from the address of an object (global, automatic storage, heap allocation). The ‘in some way’ is open to a lot of interpretation. XOR linked lists are an example of a dual-provenance semantics, the fun things are when the provenance flows outside of the C abstract machine, such as using scanf to recover a pointer value.
Assembly isn’t a language. Assembly for capability machines or segmented architectures have a much stronger distinction between integers and pointers.
Turing machines have a single read head (on single-tape machines, at least), but any point on the tape can be used to store the location of another location on the tape. Turing machines don’t differentiate between code and data, so the read/write head corresponds more closely to the program counter in a register machine than to a pointer.
There is an abstract interpretation of c, and a concrete interpretation; and it is impossible to write c effectively without knowledge of both. Having seen my fair share of meaningless statements such as ‘variables are allocated on the stack’, I am very sympathetic to the view that the abstract model needs to be more prominently taught. And yet, though all concrete models are ill-defined, messy, or unportable, the abstract model is only useful because it maps to concrete models.
Hence, I think ‘pointers go in the array hole’ is a meaningful statement, because it relates to an important and relevant interpretation of c. There are other interpretations which are also important and relevant.
segmented architectures
Most notably (or at least prominently), harvard architectures.
I don’t think I quite agree with that characterisation in a few ways:
C has a very, uh, complicated relationship with pointers. There’s a proposal for a provenance model for C pointers going through WG14 at the moment because it turns out that every C compiler has a provenance model, just not the same one. In C, pointers must be derived in some way from the address of an object (global, automatic storage, heap allocation). The ‘in some way’ is open to a lot of interpretation. XOR linked lists are an example of a dual-provenance semantics, the fun things are when the provenance flows outside of the C abstract machine, such as using
scanfto recover a pointer value.Assembly isn’t a language. Assembly for capability machines or segmented architectures have a much stronger distinction between integers and pointers.
Turing machines have a single read head (on single-tape machines, at least), but any point on the tape can be used to store the location of another location on the tape. Turing machines don’t differentiate between code and data, so the read/write head corresponds more closely to the program counter in a register machine than to a pointer.
Nuance is hard to make pithy!
There is an abstract interpretation of c, and a concrete interpretation; and it is impossible to write c effectively without knowledge of both. Having seen my fair share of meaningless statements such as ‘variables are allocated on the stack’, I am very sympathetic to the view that the abstract model needs to be more prominently taught. And yet, though all concrete models are ill-defined, messy, or unportable, the abstract model is only useful because it maps to concrete models.
Hence, I think ‘pointers go in the array hole’ is a meaningful statement, because it relates to an important and relevant interpretation of c. There are other interpretations which are also important and relevant.
Most notably (or at least prominently), harvard architectures.
Swift/Rust/etc: I have a box called “Optional”. It has a pointer inside it. But until I open the box, the pointer is neither alive nor dead.
FORTH: If I can
@it, it’s a pointer.wow, if you cast things to
char *, they behave like arrays! who knew?