4 ms·

> pairs[0sh .. 1sh] # => 'AB' ['AB'], no? Or the letters without []? > This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Muc

> pairs[0sh .. 1sh] # => 'AB' ['AB'], no? Or the letters without []? > This seems kind of annoying to write. But, I swear, it feels so pleasant to read. Much moreso than any language I've used. It's not hard at all to "keep the logic in my head" when I read the above back. Well, yeah, but you conveniently left out index arithmetic :-) If it's only about hard-coded indices, it really doesn't matter, IMO, as long as it's consistent, and you could just use any ordered set of symbols for indexing, and let the compiler figure out the mapping to binary numbers and machine code that's functionally equivalent. The interesting case is when you, as the programmer, want to do arithmetic with indices. Of course, you could have a separate number type for array indices, say. But there really is no way around making its algebraic behaviour isomorphic to 0-based indices, because 1-based arithmetic is hell, and if you do that, it's probably a good idea to use the established names such as "0" or "1" for the established concepts such as "neutral element of addition" or "neutral element of multiplication", in order to avoid confusion.

derefr 10y ago
> ['AB'], no? Or the letters without []? Without. The dyadic arr[range] operator would always return one (unwrapped) element, a bit like how SQL ORMs frequently have a Query#get_one method to match Query#get_all. `letters` was a char[], `pairs` was a short[], so you're grabbing a short by its interval-address (+0 shorts from origin, +1 shorts from origin). (Or, to clarify if you were confused by the not-quite-C pseudocode, by 'AB' I meant the short 0x4142.) > But there really is no way around making its algebraic behaviour isomorphic to 0-based indices Oh, sure, it's "zero-based arithmetic" because we're still fundamentally dealing with offsets (and when you slice the array, you take offsets from the beginning of the slice, etc.) I think it's just better—in some vague human-factors sense—to be forced to mention, in each indexing operation, both where the offset (position of hyperplane separating the element from its previous) and the offset+size (position of hyperplane separating the element from its successor) will land, so that you realize explicitly what two numbers those are in your program, as you write them. Humans—especially beginner programmers—don't intuitively realize that array indexes are offsets. They just want to talk about cardinal-numbered positions, and find themselves unable to, so they guess at a mapping and make mistakes.† This syntax sort of short-circuits that by giving them an indexing operation that doesn't ask them to decide on any cardinal:ordinal mapping at all. It just asks for two numbers that are clearly "offsets of the positions between array elements", rather than offsets (or counts) of elements. But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. > The interesting case is when you, as the programmer, want to do arithmetic with indices. I think—and this I find even weirder to say than my first thought—that it might be good to restrict this "humane" indexing operation from containing compound expressions. Instead of this: foo[(a * 3 + 2)ch .. (a * 3 + 5)ch] ...you'd be forced to write this: offset = a * 3 + 2 foo[(offset)ch .. (offset+1)ch] or maybe the x86 LEA-alike: pos = a * 3 + 2 foo[(pos)ch : 0ch..1ch] This forces the programmer to give a name to the number they're using as the "base" in the indexing operation—which pushes them even further toward noticing when they've borked up the fencepost math. --- † A tangent: "pointers are hard" for beginning programmers because C tries very hard to make array access, and even plain pointer math, "act like" reference-by-cardinal-rank, but then still uses zero-based offsets, munging up the ability to deduce a coherent semantics of pointers as memory-address-valued variables. In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons, that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... but that should be a domain error on the result of the addition, not something you're mathematically unable to express.
- zAy0LfpBZLC8mAC 10y ago
  > But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. Well, I'm not convinced, but who knows? My guess would be that it wouldn't really reduce mistakes much. People would simply memorize the rule that for a single element, you always have to give some index and then follow that by index + 1 --and if the index is computed incorrectly, the result is just the same wrong result as before. You cannot force people to prove that the offset is correct by forcing them to write down the expressions for two values that have to always differ by exactly 1. > In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons Nah, I think that's perfectly sensible, even theoretically. A pointer is a perfectly sensible memory-address-valued variable, it's just that it's not in "machine code addresses", because that is an implementation detail, but rather in "abstract address space addresses", with a separate address space per object (by which I mean an allocated memory region), and obviously, with arithmetic in that abstract space counting in elements of that respective address space's type. Why would counting in bytes make any more sense? The size of a byte (or a char, rather) is mostly an arbitrary implementation detail that abstract code shouldn't be bothered with. BTW, what you write is kindof wrong: As per the abstract definition of the language, nothing is being multiplied by sizeof()s. That tends to be how it's often implemented on the usual platforms, but the abstract definition simply says that arithmetic with pointers works in units of elements, and that consistently: If you subtract pointers, you get the number of elements between them, not the number of bytes/chars/octets/words/whatever between them, the internal value is not really visible anywhere, and could relate to the abstract value in arbitrarily complicated ways anyway (like, you could have pointers that are implemented with tags to differentiate pointers to different machine address spaces and stuff like that). > that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... That's actually not the goal nor the case. Whether a pointer is aligned is an implementation detail, there is nothing in C that would require short objects to be aligned to short boundaries, and what implementations do simply depends on (a) whether the platform can handle non-aligned pointers, and (b) if it can, what makes sense as a matter of weighing performance vs. memory usage. I haven't checked it, but my guess would be that the AVR GCC, for example, does not align anything, because it only needs more memory and makes no difference whatsoever for performance (I think ... maybe I am forgetting something).

derefr 10y ago

> ['AB'], no? Or the letters without []? Without. The dyadic arr[range] operator would always return one (unwrapped) element, a bit like how SQL ORMs frequently have a Query#get_one method to match Query#get_all. `letters` was a char[], `pairs` was a short[], so you're grabbing a short by its interval-address (+0 shorts from origin, +1 shorts from origin). (Or, to clarify if you were confused by the not-quite-C pseudocode, by 'AB' I meant the short 0x4142.) > But there really is no way around making its algebraic behaviour isomorphic to 0-based indices Oh, sure, it's "zero-based arithmetic" because we're still fundamentally dealing with offsets (and when you slice the array, you take offsets from the beginning of the slice, etc.) I think it's just better—in some vague human-factors sense—to be forced to mention, in each indexing operation, both where the offset (position of hyperplane separating the element from its previous) and the offset+size (position of hyperplane separating the element from its successor) will land, so that you realize explicitly what two numbers those are in your program, as you write them. Humans—especially beginner programmers—don't intuitively realize that array indexes are offsets. They just want to talk about cardinal-numbered positions, and find themselves unable to, so they guess at a mapping and make mistakes.† This syntax sort of short-circuits that by giving them an indexing operation that doesn't ask them to decide on any cardinal:ordinal mapping at all. It just asks for two numbers that are clearly "offsets of the positions between array elements", rather than offsets (or counts) of elements. But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. > The interesting case is when you, as the programmer, want to do arithmetic with indices. I think—and this I find even weirder to say than my first thought—that it might be good to restrict this "humane" indexing operation from containing compound expressions. Instead of this: foo[(a * 3 + 2)ch .. (a * 3 + 5)ch] ...you'd be forced to write this: offset = a * 3 + 2 foo[(offset)ch .. (offset+1)ch] or maybe the x86 LEA-alike: pos = a * 3 + 2 foo[(pos)ch : 0ch..1ch] This forces the programmer to give a name to the number they're using as the "base" in the indexing operation—which pushes them even further toward noticing when they've borked up the fencepost math. --- † A tangent: "pointers are hard" for beginning programmers because C tries very hard to make array access, and even plain pointer math, "act like" reference-by-cardinal-rank, but then still uses zero-based offsets, munging up the ability to deduce a coherent semantics of pointers as memory-address-valued variables. In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons, that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... but that should be a domain error on the result of the addition, not something you're mathematically unable to express.

zAy0LfpBZLC8mAC 10y ago
> But even for experienced programmers who understand that indexing operations are pointer offset math, such an indexing-by-continuous-slicing scheme is potentially still a bit helpful, somewhat like being asked to write out a deductive proof for a hand-wavy argument: it makes you aware of when you've made a leap of logic that has no rule allowing you to make it. Or, in this case, it makes you aware of what element you're actually capturing with your hand-wavy math. Well, I'm not convinced, but who knows? My guess would be that it wouldn't really reduce mistakes much. People would simply memorize the rule that for a single element, you always have to give some index and then follow that by index + 1 --and if the index is computed incorrectly, the result is just the same wrong result as before. You cannot force people to prove that the offset is correct by forcing them to write down the expressions for two values that have to always differ by exactly 1. > In C, when you add an (ordinal!) integer to a pointer, it multiplies that integer by the sizeof() the pointer's referent type because it wants you to model the pointer as being an iterator-handle for a collection of things, rather than just being a memory-address-valued variable. It makes sense, for practical reasons Nah, I think that's perfectly sensible, even theoretically. A pointer is a perfectly sensible memory-address-valued variable, it's just that it's not in "machine code addresses", because that is an implementation detail, but rather in "abstract address space addresses", with a separate address space per object (by which I mean an allocated memory region), and obviously, with arithmetic in that abstract space counting in elements of that respective address space's type. Why would counting in bytes make any more sense? The size of a byte (or a char, rather) is mostly an arbitrary implementation detail that abstract code shouldn't be bothered with. BTW, what you write is kindof wrong: As per the abstract definition of the language, nothing is being multiplied by sizeof()s. That tends to be how it's often implemented on the usual platforms, but the abstract definition simply says that arithmetic with pointers works in units of elements, and that consistently: If you subtract pointers, you get the number of elements between them, not the number of bytes/chars/octets/words/whatever between them, the internal value is not really visible anywhere, and could relate to the abstract value in arbitrarily complicated ways anyway (like, you could have pointers that are implemented with tags to differentiate pointers to different machine address spaces and stuff like that). > that you can't create a short︎＊-typed variable containing a non-short-stride-aligned memory-address... That's actually not the goal nor the case. Whether a pointer is aligned is an implementation detail, there is nothing in C that would require short objects to be aligned to short boundaries, and what implementations do simply depends on (a) whether the platform can handle non-aligned pointers, and (b) if it can, what makes sense as a matter of weighing performance vs. memory usage. I haven't checked it, but my guess would be that the AVR GCC, for example, does not align anything, because it only needs more memory and makes no difference whatsoever for performance (I think ... maybe I am forgetting something).