What is a type error?
David Hopwood
david.nospam.hopwood at blueyonder.co.uk
Mon Jul 10 21:25:15 EDT 2006
Chris Smith wrote:
> At the same time, though, maybe I do want
> the compiler to infer that tax cannot be negative (or maybe it can; I'm
> not an accountant; I know my tax has never been negative), [...]
Tax can be negative, e.g. when a business is claiming back VAT (sales tax)
on its purchases, but the things it is selling have lower-rated or zero
VAT (or it is making a loss).
> Note that even without encapsulation, the kind of typing information
> we're looking at can be very non-trivial in an imperative language. For
> example, I may need to express a method signature that is kind of like
> this:
>
> 1. The first parameter is an int, which is either between 4 and 8, or
> between 11 and 17.
>
> 2. The second parameter is a pointer to an object, whose 'foo' field is
> an int between 0 and 5, and whose 'bar' field is a pointer to another
> object with three fields 'a', 'b', and 'c', each of which has the full
> range of an unconstrained IEEE double precision floating point number.
>
> 3. After the method returns, it will be known that if this object
> previously had its 'baz' field in the range m .. n, it is now in the
> range (m - 5) .. (n + 1).
>
> 4. After the method returns, it will be known that the object reached by
> following the 'bar' field of the second parameter will be modified so
> that the first two of its floating point numbers are guaranteed to be of
> the opposite sign as they were before, and that if they were infinity,
> they are now finite.
>
> 5. After the method returns, the object referred to by the global
> variable 'zab' has 0 as the value of its 'c' field.
>
> Just expressing all of that in a method signature looks interesting
> enough. If we start adding abstraction to the type constraints on
> objects to support encapsulation (as I think you'd have to do), then
> things get even more interesting.
1 and 2 are easy enough. 3 to 5 are best expressed as assertions rather
than types.
--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the Python-list
mailing list