Re: Static typing (Was Re: Better support for garbage collection)

[Robert A Duff <bobduff@world.std.com>]

"Ken Garlington" <Ken.Garlington@computer.org> writes:

> 
> "Robert A Duff" <bobduff@world.std.com> wrote in message
> news:wccr8zl4h0n.fsf@world.std.com...
> Note, however, that if these literals were "interpreted" as their "obvious"
> floating-point context, and the function I posted earlier were introduced,
> you'd have to decide if now (a) the literals were "more obviously" an
> integer or (b) that the correct form could not be determined from context.
> Either way would seem very awkward to me. Granted, you have that problem now
> distinguishing different decimal representations, but I certainly wouldn't
> want to make it any worse!

Sorry, I've lost track of which function you mean.  But certainly (a) is
Bad (if I understand what you mean) -- it introduces Beaujolais effects.

As to (b), once we have determined the type of a literal (ignoring its
form), we can then apply some rules to insist that its form is Good.
What I don't like is that the form helps determine the type.

> : >... If we are to have implicit casts of integers to
> : > floating point values, why not then permit the more general:
> : >
> : > Y : Float := ferble;
> : >
> : > where "ferble" is a function that returns an integer (or, for that
> matter,
> : > any fixed-point) type?
> :
> : Why not?  Because it makes no sense.  Converting type Standard.Integer
> : to Standard.Float probably makes no sense.
> 
> A conversion (or "interpretation", if you prefer) of a representation that
> is numeric, but has an implied decimal point to the right of the last digit,
> to a representation that has an explicit decimal point to the right of the
> last digit, makes no sense? Then why do you want an Ada compiler to do it
> for literals?

I see the two as completely different.  We shouldn't really be talking
about Integer and Float here.  We should be talking about, say:

    type Apple_Count is range 0..1_000;
    type Length_In_Meters is digits 7;

We don't want to implicitly convert a number-of-apples to a length,
because it doesn't make sense -- they're measuring different things.
This has nothing to do with the fact that one is float and the other
integer.  We wouldn't want to implicitly convert Apple_Count to
Orange_Count (two different integer types), either.

Literals, on the other hand, have no particular type.  The literal "1"
could be of any integer type (in Ada), and which type is determined by
context.  I say it should be "any type", and still determined by context
according to the usual overload resolution rules.

> : But implicitly converting
> : "1" to (say) Float *does* make sense.  I was only talking about
> : literals.
> 
> Again, this makes about as much sense as insisting that 1 be implicitly
> coverted to character, string... or, for that matter, "one half" to be
> converted to some numeric type. After all, if you're going to object to the
> "overhead" of adding .0, then why not object to adding quote marks for a
> character or a single-word string (in the absence of some object with that
> name)... isn't each "obvious in context"?

Of course it would be silly of me to make a big stink about having to
read an extra ".0" in the code.  I think it's silly, but it's obviously
not a big deal.

What I really object to is the general idea that the *form* of a literal
helps determine its type (during overload resolution).  For example,
suppose we have two procedures:

    procedure Mumble(X: Integer);
    procedure Mumble(X: Float);

Then in Ada, a call "Mumble(1);" will resolve to the first Mumble.  But
that's error prone.  A reasonable person might accidentally think it
refers to the other one (because, after all, the number one is a
perfectly reasonable floating-point number).  I claim that this call
should be ambiguous, and therefore illegal.  Likewise, "Mumble(1.0)"
could be mistaken to refer to the wrong one (because, after all, 1.0 is
an integer number).

If you want to require the ".0" in a call to the second one, as an extra
hint, I won't complain *too* much.  But I object to the ".0" being used
to help determine which Mumble we're talking about.

By the way, when I said "one half", I meant it as an English description
of a number.  Not as an Ada string literal.  I wanted to distinguish the
concept of numbers from the way they are written in Ada, so I could
complain about the latter clearly -- apparently it didn't work.  ;-)
So your point about converting "one half" is missing my point.

> : Note that Ada always converts literals to some particular type.
> 
> Sure... some type that is *closest* to the representation *as entered*. If
> you don't enter a decimal point, why would you expect it to be converted to
> a representation that requires a decimal point (fixed or floating)?

I don't understand why you think the form of a literal should have
something to do with the internal representation of the thing.  If that
were the case, we would be writing all numbers in binary, because that's
closer to their representation.  It seems to me that floating point is a
way of approximating the real numbers efficiently, at the expense of
some loss of precision.  Fixed point is a different way of doing the
same thing.  So it seems to me that the syntax for literals should
reflect the way we naturally write numbers, and not worry too much about
the internal representation.

> : Note also that I'm not advocating all manner of implicit conversions.
> : Certainly no implicit conversions that might lose information.
> 
> What about a conversion that adds *unintended* information?

I'm not sure what you mean by that.  Certainly if I say "it's about 10
miles from here to my house", you understand just as well as if I had
written "... 10.0 miles ...".  (In fact, I suppose 10.0 would confuse
you into thinking I was being overly precise -- but that's a whole
'nother issue.)  Leaving off the ".0" doesn't make you think miles are
discrete integer quantities, in English anyway.

- Bob