I'm sorry for misreading your comment about the term "tower". :-)
> do you object to using the word "tower" to talk about it
No, I don't really care about the terminology, except when it helps to communicate.
> do you object to the graph of number types described by that paragraph
I think the problem boils down to using a flawed analogy to arrive at a conclusion and then pretending the conclusion is sound and elegant. There are really two things going on:
First, we've got a tower, or tree, or DAG of "abstract" types. These are mathematical constructs or Platonic ideals. So you can build a tower that says "All Integers are Rationals" and "All Rationals are Reals". And it's supported by Set Theory! So you conclude that you can use an Integer anywhere that a Rational or Real is allowed. Then, knowing that we're going to apply this to a programming language, you add "All Floats are Reals". Fine, we've got abstract Floats, and it looks lovely.
Second we've got actual "concrete" data types. These are things like Float64, Int32, or BigInt. Importantly, you can't have an implementation of Real anything. In general, Real numbers can't be processed on a Turing machine. You can have a tagged union of Computable things, but that's not really the same as "Real" in bold quotes.
Ok, so the mistake comes when you try to combine those first and second sets of things. We say concrete BigInt is like the abstract Integers, and concrete Float64 is like the abstract Floats. So far so good. Then we look at the abstract tower, we decide that Integers and Floats need to become Real, so we say BigInt and Float64 need to use Reals to get a common type. But there is no common type. We said the concrete types are analogous to the abstract types and made an unsound conclusion.
Finally, we write the compiler, and reality hits us. So we go back to the standard and add some bits about "Some things really should be Exact. Conforming implementations should try to avoid Inexact when they can." It's not a separate tower - it's a bandaid for flawed logic.
Anyways, this is all a bit too philosophical. I'm not actually passionate about it, but our discussion kept going, and you kept asking, so I kept trying to explain. Most people like implicit conversions in their programming languages, and so you've got to make up some rules. I just don't like pretending the rules are not ad hoc, and it's nothing a smug lisp weenie should really be smug about.
> do you object to using the word "tower" to talk about it
No, I don't really care about the terminology, except when it helps to communicate.
> do you object to the graph of number types described by that paragraph
I think the problem boils down to using a flawed analogy to arrive at a conclusion and then pretending the conclusion is sound and elegant. There are really two things going on:
First, we've got a tower, or tree, or DAG of "abstract" types. These are mathematical constructs or Platonic ideals. So you can build a tower that says "All Integers are Rationals" and "All Rationals are Reals". And it's supported by Set Theory! So you conclude that you can use an Integer anywhere that a Rational or Real is allowed. Then, knowing that we're going to apply this to a programming language, you add "All Floats are Reals". Fine, we've got abstract Floats, and it looks lovely.
Second we've got actual "concrete" data types. These are things like Float64, Int32, or BigInt. Importantly, you can't have an implementation of Real anything. In general, Real numbers can't be processed on a Turing machine. You can have a tagged union of Computable things, but that's not really the same as "Real" in bold quotes.
Ok, so the mistake comes when you try to combine those first and second sets of things. We say concrete BigInt is like the abstract Integers, and concrete Float64 is like the abstract Floats. So far so good. Then we look at the abstract tower, we decide that Integers and Floats need to become Real, so we say BigInt and Float64 need to use Reals to get a common type. But there is no common type. We said the concrete types are analogous to the abstract types and made an unsound conclusion.
Finally, we write the compiler, and reality hits us. So we go back to the standard and add some bits about "Some things really should be Exact. Conforming implementations should try to avoid Inexact when they can." It's not a separate tower - it's a bandaid for flawed logic.
Anyways, this is all a bit too philosophical. I'm not actually passionate about it, but our discussion kept going, and you kept asking, so I kept trying to explain. Most people like implicit conversions in their programming languages, and so you've got to make up some rules. I just don't like pretending the rules are not ad hoc, and it's nothing a smug lisp weenie should really be smug about.