This apparently wasn't a popular post, but it makes an important point: for abstractions to be useful, the user must know or be able to look up their precise semantics, and that requires more than a name, as illustrated by the range function here. This is generally well-understood by the people who write software for making software, but not so much in applications-level programming.
Or something like a public forum or google exists, and lots and lots of people continue to hack and talk about things in order to fuzzily define what they think the author meant by a certain term, in the case that it's meaning was lost, relabeled, mistranslated, or otherwise changed somewhere along the way of technological development.
If you understand mostly what everything else is in a system, then people basically swarm around the behavior of something undefined in order to fuzzily define it. It sticks and it does not stick - it depends on whether programmers rewrite the system or the word is forgotten about on some super secure layer of abstraction, or whether it's the word that everyone is teaching and talking about and naming things after.
I don't think words can really express this process, it's pervasive and paradoxical to it's description. You have to assume you understand everything else, before you can label something truly new. Otherwise it's just the same amorphous blob, and the labels keep swapping, and no concepts are really applicable, because they are only observable from a macroscopic perspective of abstraction, except when they are being used, right there in front of the code. It's always the same balance of 'i know some stuff' and 'i don't know some stuff'.
-Is- it well demonstrated here? I think everyone would understand what 'range' means pretty quickly, just by executing it. I can see someone saying "I don't get 'foldl'" (or even worse, foldl vs foldr), and really -meaning- it, but regardless of whether range(1, 2) gives me [1] or [1, 2], I'm pretty sure people would 'get' it just by trying a few examples in the console/shell.
Yes, it is a clear example of an abstraction with semantics not fully explained by the name, and your solution of testing it does not contradict this point.
More importantly, your solution doesn't scale to more complex abstractions, or to more complex properties, such as whether it is thread-safe or what exceptions it could throw. Plenty of bugs result from mistaken assumptions about such things, or simply by overlooking them.
