----- Original Message -----
From: "Maximilian Wilson" <[EMAIL PROTECTED]>
To: "Anthony Borla" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, December 03, 2005 3:20 PM
Subject: Re: Oz Newbie: Pattern Matching and Type Conversion
Max,
> >On 12/2/05, Maximilian Wilson <[EMAIL PROTECTED]> wrote:
> > operation. This wouldn't matter so much if Floats didn't have such
> > very different properties from Ints, unlike say fixed-point numbers...
> > it makes it very difficult to reason about the semantics of your
> > calculation. I am more and more coming to appreciate Mozart's
> > strict aversion to arithmetic type coercion.
>
> Come to think of it, it strikes me that C-style type promotion
> (an int is a float) is a bad idea for the same reason that "a
> square 'IS A' rectangle" is now widely considered to be a
> fallacy. A square has the same *data* as a rectangle, but it
> has extra constraints, so the Liskov substitution principle
> doesn't hold if squares are mutable.
>
> (Trying to adjust e.g. the height of a rectangle may break an
> assumption that the length remains constant, if the rectangle
> is a mutable square.) Conversely, a rectangle is not a square
> because it lacks some of its properties. A subtype relationship
> is not appropriate in either direction, and the same is true for
> floats and ints.
>
That's an interesting take on the subject. I certainly don't recall off-hand
seeing that argument used [applying the Liskov Substitution Principle] to
describe the behaviour of fundamental / primitive types, only complex /
user-defined types [e.g. C++ / Java classes].
I suppose this is because in languages [like those mentioned] the former are
treated as special cases [i.e. they are entities which directly map to
hardware] rather than as 'true' types ?
Ignoring implementation / value encoding differences, though, if we compare
integers and floats, we see that they have similar interfaces and behaviour.
By this I mean [largely] the same arithmetic operations apply to each, and
they each used in the same way: to represent numeric values. Furthermore,
floats can represent all integer values [I'm assuming a C model here], thus
could considered a 'specialisation' of integers, though of course, the
interface differences would preclude their being considered to be in a
superclass / subclass relationship, as you point out.
Given this general behavioural similarity, and that floats can represent all
possible integer values, it seems reasonable [*] to support type promotion,
specifically, the promoting of integers to floats. I wouldn't, however,
endorse implicit type conversions in general [though it is possible to get
used to them and program accordingly].
[*] This assumes that 'programmer convenience' is a priority. The cost of
this convenience is, of course, less guarantee that your program is doing
exactly what you expect it to be doing.
Referring to my comment about type promotion in my earlier post, I'd gotten
used to write expressions like:
SomeFloatValue / anIntegerValue
in C because of implicit type promotion. Strictly speaking it is sloppy
programming, and, I'm finding, a very difficult habit to break [by this I
mean that I keep writing such erroneous expressions, and it is the compiler
that alerts me to the error].
Cheers,
Anthony Borla
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
