From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd63afa4dc364b7e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-03 01:59:51 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!falcon.america.net!sunqbc.risq.qc.ca!news3.bellglobal.com!fu-berlin.de!uni-berlin.de!ailinel.cbb-automation.DE!not-for-mail From: dmitry@elros.cbb-automation.de (Dmitry Kazakov) Newsgroups: comp.lang.ada Subject: Re: Static typing (Was Re: Better support for garbage collection) Date: Tue, 03 Apr 2001 08:57:34 GMT Message-ID: <3ac97b48.86871890@news.cis.dfn.de> References: <3ac85c82.13458000@news.cis.dfn.de> NNTP-Posting-Host: ailinel.cbb-automation.de (212.79.194.99) X-Trace: fu-berlin.de 986288254 4642730 212.79.194.99 (16 [77047]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: supernews.google.com comp.lang.ada:6391 Date: 2001-04-03T08:57:34+00:00 List-Id: On Mon, 2 Apr 2001 13:15:23 GMT, Robert A Duff wrote: >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. An interesting example. You are right that in Ada universal types are leaky (:-(). >>... 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 (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.) There is no need for a user-defined conversion to be a compile-time function. As a consequence, it is possible that Devils_Number : constant Data_16_Type := 666; is not static. It may look strange, but it is pretty consitent with what we already have with enumeration literals and named constants which are undistinguishabe from parameterless functions. Similarily, in effect, 666 ::= Integer_To_Data_16_Type (666). >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... A conversion function should be treated like any other routine. >> 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 (Value : Universal_Integer) >> return Data_16_Type; >> ??pragma ;?? > >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? The point is that IF (I am not sure here) universal types are allowed as formal paramerters of some routine (no matter whether it is a conversion function or not), THEN there should be a rule that prevents this routine from being called at run time. >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. Because with user-defined conversions you get user-defined literals for free. Then the idea of user-defined conversions is a fundamental ADT (or OO if you like) feature. If we consider how new types could be built upon the existing types, we will find the following three major approches: 1. Cloning: same functionality - unrelated type (type ... is new in Ada). Used when we do not want to add apples to oranges. 2. Inheritance: same functionality - related type (type ... is new with). This is what is usually called OO. 3. Masquerading (multiple representations): other functionality - related type. This is what the user-defined conversions are supposedly for. As an example, look at Ada string types and the plethora of "&" functions one must have to interchangeable use instances of different kinds of strings. As for your idea, I feel it uncomfortable, when something is undeterminable without a context. I accept it for many things, just because we do not know how to do it better. But why such a simple thing as 1 should have no type? IMO any thing in a language should have a type. >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. A nice fiction. Anyway 1 is also a fiction (or a science fiction? (:-)) >By the way, you didn't mention a universal_access, which would >presumably be the type of "null". Surely. Moreover, in general there are lots of universal types, if you want to build the type system consistently. This issue is definitely related to the concept that, for instance, all numeric types should have a common ancestor. Elaborating this idea, you will come to universal record, array, index types too. Practically if you look into a type you will find some universal fiction behind it. Regards, Dmitry Kazakov