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

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

dmitry@elros.cbb-automation.de (Dmitry Kazakov) writes:

> Yes and no. In my opinion instances of universal types may not exist
> at run time.

In Ada, there are actually some rare circumstances where
universal_integers can exist at run time.  For example:

if T1'Size > T2'Size then ...

where T1 and T2 are not static subtypes.  I suspect that the intent of
the original designers of Ada 83 was as you say (u_i is a compile time
concept), but there are a few minor holes in that idea.

Note that the above can raise Constraint_Error if one of the 'Sizes is
very large.

>... A universal_integer has an arbitrary length, its actual
> representation is upon the compiler. So one may not have an object of
> this type. In the end an instance of a universal type should be always
> converted to some "legal" type. Yet with user-defined conversions one
> will have an ability to explicitly add literals to a private type:
> 
> function <syntax-sugar> (Value : Integer) return Data_16_Type;
> 
> Then the following conversion path is applied:
> 
> 123 (of universal_integer)->123 (of Integer)-> 123 (of Data_16_Type)

You presumably need to require that this function be "pure", so the
compiler can evaluate calls at compile time.  (Note that Ada's pragma
Pure applies to whole packages, not to particular functions.)

Also, I suspect it's a bad idea to allow this function to have
machine-code inserts, or calls to foreign languages.  Especially if it's
a cross compiler!

Speaking of cross compilers, I suppose if the function does floating
point arithmetic, the compiler is required to simulate the target
hardware?  That's a fairly substantial burden...

> Further this issue is obviuosly relevant to another thread (where the
> compile time routines are discussed). If such beasts were allowed then
> one might have exactly what you mentioned:
> 
> function <syntax-sugar> (Value : Universal_Integer)
>    return Data_16_Type;
> ??pragma <ensure-that-this-is-a-compile-time-function>;??

I'm slightly confused at this point.  What rules do you propose that
ensure that the function is only called at compile time?  Are these
implicit conversions only allowed for literals?  Only for static
expressions?

> As for danger, it is immense, yet in modern times (take a look at
> comp.object) strong-static-manifested typing is considered as an
> evil?! (:-()

I've read part of that thread (until I got bored of "yes it is", "no
it's not" repeating indefinitely).  Actually, only *some* folks think
that strong-static-manifest typing is evil.  I think it's a sign of the
immaturity of "computer science" that practitioners can't agree on such
a fundamental issue.

Anyway, I don't understand why you like universal types with implicit
conversions better than the alternative I suggested.  (The alternative
is that the type of a literal is determined by context, and the value of
the literal is determined by evaluating a type-specific function at
compile time.)  What is the advantage of universal types?  They seem
kind of kludgy to me.

The original Green language said that integer literals are overloaded on
all integer types.  Universal integer was invented so that things like:

    if X = 1 then ...

where X is a named number, would not be ambiguous.  But I think named
numbers are a kludge anyway, so I don't buy the universal_integer
fiction.

By the way, you didn't mention a universal_access, which would
presumably be the type of "null".

- Bob