proposed language change to int/int==float (was: PEP0238 lament)

[Marcin 'Qrczak' Kowalczyk]

28 Jul 2001 14:49:14 +1200, Paul Foley <see at below> pisze:

> Um...Guido, Scheme is broken!

I don't see how it is broken.

> You should have a completely *abstract* type hierarchy, representing
> the mathematical entities (e.g., "real" represents mathematical reals,
> quite independent of any possibility of a precise computer-based
> representation), and all the implementation types should inherit from
> those.

Python doesn't use abstract types. Interfaces are implicit. You may
group types under implicit interfaces yourself, it's not specified
in the language. There is no Python construct which would express
your meaning of "real".

> That is, "int" and "long" should be sibling subtypes of "integer";
> "int" should *not* be a subtype of "long" as in your proposal.

Everything works as long as you don't call it subtyping, so I propose
to not call it subtyping for the purpose of this discussion. Is
anything still broken?

> The handling of exactness is also broken.  Exactness is
> metainformation, like units.  It's probably wrong to put it in the
> language at all.  It's *certainly* wrong to say integers are always
> exact and floats always inexact.

Why? It's the most practical approach I know.

> If the exactness flag has to carried around externally (e.g., in
> the programmer's head) anyway, there isn't much point having an
> inexact concept of exactness in the language.

It doesn't have to be explicit in the language at all. But in practice
ints and rationals are usually exact, and you should rarely use them
as inexact, and that floats are inexact, and there is no much need
to rely on the fact that in some circumstances they can be exact.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK