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

["Ken Garlington" <Ken.Garlington@computer.org>]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccg0frz5hz.fsf@world.std.com...
: "Ken Garlington" <Ken.Garlington@computer.org> writes:
:
: > "Robert A Duff" <bobduff@world.std.com> wrote in message
: > news:wccvgorkl54.fsf@world.std.com...
: >
: > : > I understand that you see it as a "malformed literal"... but WHY is
it a
: > : > malformed literal, any more than
: > : >
: > : > X : constant Float := 1;
: > : >
: > : > would NOT be a malformed literal under your proposal? Isn't the
desired
: > : > result "obvious" in each case?
: > :
: > : I find it obvious in this case, but not in the String case.  Shrug.
: > : That's only a minor point.
: >
: > Again, the inconsistency is rooted in an inability to articulate WHY
it's
: > "obvious" in one case, but not in another.
:
: I thought I articulated it already.  I'm basing my thinking on
: fourth-grade maths, rather than on computer hardware.

What part of "4th grade maths" covers text?

:  In 4th grade
: maths, the integers are a subset of the rational numbers.  The Ada
: integers are a subset of the mathematical integers, and the Ada floats
: are a subset of the rational numbers, but the number we refer to in
: English as "one" is a member of both.

Which is irrelevant, since we both previously agreed that the imprecision of
English was insufficient, right?

: That's why I see nothing wrong
: with denoting this number as 1, no matter what it's Ada type.
:
: You claim I'm being inconsistent by not going further, and allowing
: 1_000 (without quotes) if the type is String.  Well, maybe that's
: inconsistent, but so what.  I think we both agree that the rules about
: what forms of literals are allowed should be different for different
: types.

If we both agree that "what forms of literals are allowed should be
different for different types," then you must agree that it is reasonable
for integer literals to be restricted to their dictionary form.

Of course, if you don't see inconsistency as an issue, then of course you
don't have to agree on anything :)

: >... Presumably, we want to write the
: > language so that the expected result is "obvious" to the largest number
of
: > people. For example, if I see
: >
: > X: constant Float := 1/2;
: >
: > I would intuitively expect this to have the same effect as if I wrote
: >
: > A : constant Integer := 1;
: > B : constant Integer := 2;
: >
: > X : constant Float := A/B;
: >
: > If they both work, then I would also expect the following to work:
: >
: > function Q (Z: in Float) return Float;
: >
: > X : constant Float := Q(A);
: >
: > and at this point we are talking about implicit casts, which I don't
like.
:
: I don't like it either.  But I claim the two issues are different.  The
: literal 1 is *not* inherently of type Integer.  The reason you can't
: implicitly convert Integer to Float is the same reason you can't
: implicitly convert My_Float to Float (even if My_Float has the same
: 'Digits as Float, and therefore the same underlying representation, and
: the same mathematical properties).

See previous post about the dangers of mixing specific Ada types (Integer,
Float) into the discussion, as well as machine representations.

: > Not being able to articulate the difference here is the same problem as
: > insisting that the term "floating-point" MUST be limited to hardware
: > representations... it's fine, so long as everyone shares your mindset
(and
: > there's counter-evidence to that already). However, if someone believes
: > otherwise, then they may be confused and frustrated when the more
widespread
: > definition is not supported by the language.
:
: Perhaps I misspoke when I said something about hardware
: representations.
:
: The point is that floating point types in Ada (and all other programming
: languages) are intended for doing certain kinds of approximate
: calculations, which has little to do with the representation of these
: things on the screen -- that is, every programming language disagrees
: with all those dictionaries you quoted.

Again, you're confusing the concept of a *type* with the much-narrower
concept of a *literal*. See the definition of type at www.foldoc.org for
more information.

: That's not too surprising -- after all, Ada uses the term "integer" to
: refer to a rather small subset of the mathematical integers.  ;-)

Which integer is not permitted in Ada as an integer literal (vs. an Integer
type)? Are you worried about line length limits?

: > In your other post, you said:
: >
: > : My proposal does not "loosen" -- in fact (other than the minor ".0"
: > : thing), my proposal makes more programs illegal -- it tightens.
: >
: > First, this seems to be a Bad Thing -- to make legal programs, that use
a
: > more strict definition of literals, illegal.
:
: First, recall that I am not proposing to change Ada -- of course I agree
: that such an incompatible change would be a Bad Thing.  I am talking
: about what I would do if I were designing an Ada-like language, from
: scratch, with no compatibility concerns.
:
: > Second, isn't this contradicted by the example above? GNAT says two of
these
: > are illegal, you say all four are legal.
:
: Sorry -- I was unclear.  In the "other post", I was saying that my rule
: saying "the expected type for a literal is any type" is a *restriction*.
: You are correct that allowing to leave off the ".0" is an *extension*.
:
: >... Note that it's not limited to ".0";
: > all sorts of literal forms (exponents, based numbers, etc.) would now be
: > exchangable. All you have to do is leave off one digit (e.g. 1.00000E5
: > instead of 1.000001E5), and suddenly your floating-point value can be an
: > integer!
:
: That's a good point.  I agree that it would be confusing for 1.00000E5
: to be an allowed form for an integer literal.

Now it starts to get really strange in that we have to introduce a new
literal form, presumably <sign><digits>.0, to allow as integers. Are we sure
we need this extra complexity?

: > :> J: constant String := a; -- is this a literal "a", or a reference to
: > :> something that I forgot to import? Both are possible...
: >
: > : The a is an identifier, not a literal, and I don't propose to change
: > : that.
: >
: > Again, WHY is it a an identifier, if there's no identifier named A in my
: > program?
:
: Oh, come on!  I know that you know perfectly well that the a above is an
: identifier, and not a literal -- this is the syntax defined in chap 2 of
: the RM.  I never proposed to change that.

This statement appears to parse as "it's not allowed because the ARM doesn't
allow it." In which case, your whole proposal is dead, since the ARM doesn't
allow it, either :)

You'll have to depend on a different line of argument -- if it's "obvious"
what was intended here, what's the problem with being consistent and
allowing this to be parsed?

: I think literals and identifiers should be syntactically
: distinguishable, and I'm sure you agree.

(1) You seem to be making a "proof by authority" here -- even if we both
agreed, at least one of us should be able to explain why.

(2) This still doesn't answer the case where the literal *is* syntactically
distinguishable, e.g.

X : constant String := 1;

: - Bob