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:wccvgotscxo.fsf@world.std.com...
> 
> : 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.
> 
> However, form would still be used to distinguish between numerics,
> characters, and strings even if your proposal is adopted.

No, my proposal is that the form of a literal does not help determine
its type.  That applies to all kinds of literals.

As I said above, *after* overload resolution has determined the type of
a literal, we can apply rules that ensure the form of the literal is
appropriate for that type.  As you suggest, it's probably not a good
idea for:

    "12"

(with the quotes) to be allowed as an integer.

Exactly what those legality rules are is a fairly minor point.
You don't like 1 as a float, you would like to require 1.0, which
I think is silly, but either way, it's definitely a minor point.

I would eliminate the syntactic distinction between character literals
and string literals -- just use double quotes for both.  Then the
compiler has to determine whether "A" is a character or string from
context.

By the way, the "ulterior motive" in my ideas about literals is that
what I *really* want is user-defined literals.  I think the programmer
should be able to say "this type here has literals", and define which
forms are legal for that type, and what they mean.  But in order to
avoid chaos, we can't have the form of the literal affecting overload
resolution.

> And, very importantly, I'm *not* talking about Integer and Float here. I'm
> talking about integer, floating point, and fixed point *literals*.

I was trying to explain why the "interpretation" of a literal is
different from an implicit type conversion from (say) Integer to Float.
I wouldn't want to allow the implicit type conversion, because it
violates the type system.  But literals are different -- a literal, in
and of itself, is not of any particular type.  So you're not really
doing an "implicit conversion" in the usual sense (even though the RM
describes it that way).

> : 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),
> 
> Right! To continue the thought - it *couldn't* be a string, a character,
> etc... (where Ada includes "floating point" and "fixed point" value in the
> "etc.").

It's fine with me if 1 can't be a string, because it has no quotes (my
quoting conventions in English are confusing the issue here!).  But I
want that to be a post-resolution legality rule.  I don't want the lack
of quotes to help *determine* its type.

> : 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.
> 
> I think you either meant (a) any *numeric* type, in which case you're
> inconsistent, or (b) *any type*, which is now an internally consistent
> position, but brings about some new problems. For example, how should the
> following be interpreted?

I really did mean "any type".

> X : constant String := 1_000;
> 
> Is the underscore retained?

Probably the right rule is that string literals must have quotes, so the
above is illegal.  Do you understand the rather subtle distinction
between letting the literal's form determine its type, versus making
certain forms illegal after having determined the type (clearly String,
in the above case)?

> : 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.
> 
> My point is not that it's a trivial position (although it is), ...

The whole trivial argument is an awful lot of fun, though!

>...but that it's
> an *inconsistent* position,. After all, we could just as easily say that Ada
> should accept
> 
> X : constant Character := 0;

I would require:

    X : constant Character := "0"; -- note double quotes

and also allow:

    X : constant String := "0";

because the context unambiguously determines the type of the literal in
each case.  But I would say just plain 0 without quotes would be a
malformed literal if it turns out to be a character or string literal.

I don't see any inconsistency.

> where the tick marks would be equally unnecessary. This would be much more
> like a Do What I Mean compiler, which would annoy me no end.
> 
> : 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).
> 
> As noted earlier, not according to the dictionary definition of
> "floating-point".

I don't think the dictionary definition you quoted is what Ada means by
floating point types.  In Ada, floating point is referring to an
internal representation, and the behavior of the operators -- not to the
display on the screen.

> :  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).
> 
> Not according to the dictionary definition of "integer".
> 
> : 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.
> 
> Then, to be consistent, you have to object to these as well:
> 
> procedure Mumble("0");
> procedure Mumble('0');
> procedure Mumble("0.000");
> 
> and so forth.

Yes, and I do.  I would like to call those "ambiguous and therefore
illegal".

> : By the way, when I said "one half", I meant it as an English description
> : of a number.
> 
> In order to deduce this, I would have had to look at the form of the
> expression, now wouldn't I? :)

Well, English is like that.  A programming language ought to be less
susceptible to misunderstandings.

> : 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.
> 
> But "one half" is an equally valid way of describing 0.5, 1/2, 1.0/2.0, etc.
> using the informal notation you appear to have adopted... if not, why not?

Too hard to describe precisely in the RM.  To hard to implement in
general.  Not worth the trouble.

The only reason I wrote "one half" is because it's a notation for
describing a number that is *not* allowed in Ada or any other
programming language I know -- hoping you would guess this is just an
English-language description of a particular number.

> : > : 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.
> 
> I never used the word internal in the sentence above.

OK.  So that wasn't quite fair of me.  Nonetheless, Ada floating point
is all about the internal representation, despite what your dictionary
says.

> : 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.
> 
> Oops! Now *you're* dealing in internal representations. Floating-point
> numbers aren't an approximation of anything, according to Merriam-Webster.
> It's a mathematical notation (a representation, in the dictionary's words)
> for a real number. Any precision can be represented.
> 
> : 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?
> 
> Example: I write 4, meaning the integer value 4. You convert it to '4',
> since that's the context in which I appeared to use it. You've added
> information (4 can be a character) that I didn't intend.

OK, I see what you mean.  I didn't intend to allow that.

- Bob