when you JOIN 5.5 with 4.8, you get 5.54.8, definitely not a number.
or, if bignums is enabled and you JOIN 1/2+4/3i with 5/2+7/9i, you get 1/2+4/3i5/2+7/9i. again, not a number.
Yes, what of it? Maybe you are trying to create a version number for a piece of software. If you are trying to combine two numbers, and you want the result to be a number, and you're not sure the numbers are positive integers, then you'd be well advised to use a numeric operator rather than a text operator. But the job of a programming language isn't to prevent you from doing silly things. It's to enable you to do whatever you want, silly or otherwise.
This is the problem: that is correct only on numbers.
I'm not worried about <is [] a [number v]> but <is [] a [string v]>
I don't know if we're going to reach a meeting of minds on this topic. My guiding principle is that the purpose of computer science is to hide from human beings the inner workings of computers. To the extent possible, the story we tell users should reflect mundane reality. So for example, if you write down 001 on a piece of paper and ask a random person in the street what it is, they'll say it's the number 1. Or maybe they'll say it's the number of the first secret agent licensed to kill. But nobody who isn't a computer programmer will say "Oh, that's a character string."
I'm guessing that the reason this obvious truth doesn't feel true to you is that you've had the misfortune to be exposed to a programming language that uses the + operator to mean string concatenation. That is a very, very bad choice in designing a programming language.
It's fine to extend the domain of operators. But you have to do so in a way that's consistent with what the operator ordinarily means. So, it was fine when mathematicians extended the domain of + to vectors, because they did so in such a way that (3,0)+(2,0)=(5,0). It was fine when the IEEE floating point standard extended the set of real numbers by adding ∞, -∞, and NaN, because they did it in a way consistent with real arithmetic. (In particular, you can't get from NaN to a number by any arithmetic operator. NaN - NaN = NaN, not 0.)
I mean that any string should count as a string. Even if it is also a number:
<<is [5] a [number v]> and <is [5] a [string v]>> --[ true ]
But if you actually want to be able to read off the end of an array, and get or set some random address, then why does javascript automatically make a bigger array and copy all elements
OH! I see. I'm pretty sure this thread started out about something different.
We chose to have disjoint types for purposes of that block. Partly it's because once you start down the road of non-disjoint types you end up with the users wanting subset types such as Integer, and so on. Then it's hard to know what all the rules are.
Just as it's fine, and often useful, to write an INTEGER? block, it's fine for you to write a STRING? block, and it's easy for you to understand how to do that in terms of the primitive types. It'd be a little more of a cognitive challenge to write STRING THAT ISN'T A NUMBER? even though the procedure when written is simple.
correct.
ok.
<<is (arg) a [number v]> or <is (arg) a [text v]>> --[string]
<<not <is (arg) a [number v]>> and <is (arg) a [string v]>> --[text]
Yeah, as I said, the code is equally simple, but if you're a beginner (a big part of our audience) it's harder (I'm guessing) to work out the correct set difference relationship than to figure out a union of disjoint types.