That is, the deref operator can take either an l-value or an r-value as an argument, and is certain to return an l-value as a result. (2/2)

@EricLippert, I follow. A pointer-value to main memory doesn't have to be stored in main memory itself, it can be stored in a register (or maybe, elsewhere). Whereas a pointer-value when dereferenced must, by definition, be a field in main memory. In C, registers themselves are not explicitly addressable or assignable by the programmer - they're compiler-managed. What confused me was the terminology "produces a variable" - it's obvious now that what this means is akin to "bring into scope a field that is guaranteed to be explicitly addressable". (1/2)

@EricLippert, are we talking about the l-value/r-value distinction? Otherwise, I'm not following why the field/variable containing the initial (un-dereferenced) pointer-value could not also be stored to?

The nature of a message pump is to act as a concentration point for various external messages and then distribute them internally, and a switch statement is specifically intended for situations in which there are a significant number of cases, so there is nothing at all untoward about a switch statement inside a message pump that has a large number of cases.

@EricLippert, could you pad that line of thinking out a little more? If I understand correctly, you're refering to the distinction between fields (a place for storage) and the contents of those fields (the "value", or the data stored at that place). In computing, there is no reality of either one without the other. But if the word "pointer" refers to the content, and the word "field" refers to place, I struggle to understand why a deref of a pointer (i.e. content) "produces a variable" (i.e. a field), rather than producing more content?

@supercat, all you're doing is identifying the efficiency of the algorithm or mechanism associated with pointers as we know them. I don't doubt that there can be systems of addressing devised far less efficient than what we currently know. But there still has to be such a system, however inefficient and at whatever level, in order to implement basic operations of a general purpose computer.

As for this pointer thing, I see instruction sequences and jumps (and therefore a method of addressing the destination) as being fundamental to how certain behaviours would often be conceptualised and expressed in natural language, and the computer as merely automating (and intensifying the systematic, mechanical aspects of) this. So when you tell me it's not necessary, you're implicitly challenging the tenets of a practice far bigger and older than computer programming languages. Writing and following a series of instructions, was not first invented with the computer. (3/3)

I'm sure we've had some sort of deeper discussion before about computing or programming languages, and there's some kind of difference in our broader intellectual behaviour or culture with which I do not just disagree, but to which I am positively hostile - a difference which is not specific to you or even to those found in the field of programming, but notable wherever study becomes rarefied. In a programming context, I find the words "(do/don't) need to know" (when talking about the knowledge of anything but a person) seems to be a strong indication that this difference is present. (2/3)

@IMSoP, programming languages can differ because they make certain things easier or harder for the programmer, or for people who are allied or auxiliary to the same work (including educators or academics who have to handle and reproduce the conceptual content, or compiler writers and hardware designers whose conceptualisations need to be apt and internally consistent across a wider scope than just the language itself), not because different programming languages all have fundamentally different facilities or restrictions. (1/3)

@Barmar, with "memory safety", a number of risks arise not so much from the use of pointers per se, but from safety being forgone in the name of simplicity or speed of execution. And a number of other risks, which would be called "referential integrity" issues in a database context, also carry over into the realm of custom addressing schemes which replace raw pointers, if the safety of the scheme is again forgone in the name of simplicity or speed of execution.

And the idea of stopping at the first/nearest case of duplicate addresses, you see that with segmentation and near/far pointers. (2/2)

@IMSoP, I just don't see why these differences are fundamental. Main memory addresses are sequential because nobody could see any other design choice to be sensible or desirable, not because it is mechanically impossible to have a computer with gaps in the addresses. When addressing with strings and line labels, there is incomplete coverage because it is unnecessary work for the programmer to write code that achieves complete coverage (when he actually jumps only to a very few key places), not because it is impossible to do so. (1/2)

@IMSoP, there's really no fundamental difference between a "search pattern" and an "address" in this context. An address doesn't "represent a location", it represents information necessary to find a location. In a computer, each memory location is circuit-switched at the hardware level - that switching is the "finding" for native addresses. You are just introducing an explicit scheme in software where the finding itself is explicit in the software algorithm rather than in the underlying workings of the hardware. This is why I say, you're just swapping the familiar for the less familiar.

@IMSoP, if you allow pointers to represent values larger than the valid address space, that too would result in an error - that is what you're doing by allowing arbitrary strings but only defining some of them as valid places. You could enhance further with some crazy, non-sequential mapping. I also don't understand what you mean by "the implementation doesn't need to know where the label occurs" - it looks the location of label up on each jump. As I say, you're just proposing innovations from the familiar forms of indirection via addressing, to the less familiar.

@supercat, you're just substituting more complicated and less familiar systems of addressing. It still fundamentally works so that a place in the code is identified by representation - a pointer equivalent - and something occurs by which execution proceeds to that place - a jump equivalent. I don't think this technique is specific to computing (which merely has a highly systematic and essential manifestation of it) or other mechanical automations.

@supercat, I must admit I don't quite understand the detail of what you describe, because my understanding of the if block is that it is itself a conditional branch to a storage address. You seem to be saying the if and endif statements in your language perform an unconditional operation, but that the else statement becomes the focal point for a conditional operation - in which case we've just moved the issue around, not purged any unnecessary concept.

@osa1, as well as passing a comparison function at construction time, ultimately you could just design the entire collection bespoke to incorporate the relevant comparison function in a fixed way, or you could fall back on using plain arrays and separate insertion/retrieval methods that work on the array and enforce/employ the desired constraints as part of their workings. It isn't always necessary, or desirable, to attach the algorithms directly to the data.