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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Build language with weak typing, then add scaffolding later to strengthen it? Date: Fri, 22 May 2015 16:25:44 +0200 Organization: A noiseless patient Spider Message-ID: References: <127b004d-2163-477b-9209-49d30d2da5e1@googlegroups.com> Reply-To: nonlegitur@futureapps.de Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 22 May 2015 14:24:35 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b96887e80893c84a90c3007226ca0d1c"; logging-data="30327"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JkZrFH/fhb97wYpOsmu79c2Go2fygE3Y=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: Cancel-Lock: sha1:buJ8dY/3f7cyseJGxZFPxXjcVSg= Xref: news.eternal-september.org comp.lang.ada:25944 Date: 2015-05-22T16:25:44+02:00 List-Id: On 22.05.15 14:57, J-P. Rosen wrote: > Le 22/05/2015 13:29, kalvin.news@gmail.com a écrit : >> Even C could be made more robust, if simple type checking is >> performed at compile time. For example, >> >> typedef int apples; >> >> typedef int oranges; >> >> apples a = 5; oranges o = a; >> >> should generate type check error as the types are definitely >> different types. Also, assigning enums to ints and ints to enums >> should be considered illegal. >> > I don't agree. C is a low level language, and good at that. Its types > are those of the machine: bytes and addresses, the rest is a (small > quantity of) syntactic sugar. Not sure this description of what C is in the eye of an Adaist will win an argument; first, it is not exactly right. (If myths say that int was influenced by PDP hardware 40 years ago, this doesn't seem to reflect C compilers in use today, or yesterday.) While the C type int is defined by the C standard, one needs to consult the implementation's docs to learn the specifics of int for a given implementation. Same for Ada! There would have been an opportunity to point out the extended possibilities that Ada offers for expressing expectations on types. But LS : String(1 .. 100_000); is not defined by the Ada LRM as an unequivocally valid piece of Ada source text, since Positive, and therefore String, are only defined to much the same extent that C's int is defined by C. OTOH, what happens if I'd write *(p + 100000-1) in a C program? Then, the C standard is explicit about what a byte is. A C int cannot be expressed as bytes of C. Nor is the behavior of int objects in borderline situations devoid of context in the standard. There also is no forced relationship of machine words and int for a C implementation: 32 bits on a 64 bit architecture is a valid choice. But that _is_ a source of trouble! The issues are elsewhere, and it seems like a good opportunity to show that, with Ada, there is actually more in the hands of a programmer to address issues that cannot be addressed in portable C source text; e.g., reactions to overflow. C is in many ways as strongly typed as Ada, just not everywhere, and that's worth pointing out, specifically addressing the typical problems that C programs tend to run into. C, in addition, has neither subtype constraints, nor derived types, nor language-defined representation expressions etc.. But is _does_ have named type equivalence: typedef struct apples { int amount; } Apples; typedef struct oranges { int amount; } Oranges; Oranges f() { Apples a = { .amount = 5 }; return a; } The definition triggers a compile time error: it is nor permissible to return a structurally equivalent struct apples when instead a struct oranges was named as the return type in f's profile. If the error is corrected, then the code produced, even when just modest optimization is requested, will be the same as if only a scalar type had been used. That is not to say that I'd expect C programmers to avoid bare int. Nor that the "solution" looks attractive. But it does confirm that to say that C is a weakly typed _language_ will be ignored by any C programmer in charge. Doing so falls short of being an argument.