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: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: strange behaviour of utf-8 files Date: Mon, 18 Nov 2013 18:34:08 +0100 Organization: cbb software GmbH Message-ID: <1x6cdio4omkep.14oukmbw0ux7q$.dlg@40tude.net> References: <73e0853b-454a-467f-9dc7-84ca5b9c29b2@googlegroups.com> <1ghx537y5gbfq.17oazom68d4n6.dlg@40tude.net> <9d00683c-949c-4e88-a161-ebd78b350d39@googlegroups.com> <1w23uq33ul2i8$.wzjpp3evot36.dlg@40tude.net> <5288c584$0$6639$9b4e6d93@newsspool2.arcor-online.net> <52891372$0$6636$9b4e6d93@newsspool2.arcor-online.net> <10ec0vuld83fy.1t7bduzwsrfe.dlg@40tude.net> <5289d34e$0$6637$9b4e6d93@newsspool2.arcor-online.net> <528a10a9$0$6564$9b4e6d93@newsspool4.arcor-online.net> <528a3796$0$6635$9b4e6d93@newsspool2.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: Ws8cDh6KC0dYMbHlsA0RIw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3800 Xref: number.nntp.dca.giganews.com comp.lang.ada:183927 Date: 2013-11-18T18:34:08+01:00 List-Id: On Mon, 18 Nov 2013 16:51:50 +0100, G.B. wrote: > On 18.11.13 16:25, Dmitry A. Kazakov wrote: >> Compare: >> >> 123 is a literal of Integer, mod 341, Unsigned_16, ... types > > Compare > > type My_Int is range 1 .. 10 > with Size => 16; > > to > > type My_Int is range 1 .. 10 > with Size => 32; > > > Now > > type My_Char is range 'A' .. 'Z' > with size => 31; > > to > > type My_Char is range 'A' .. 'Z' > with size => 15; > > > And > > type My_Float is digits 6 range 0.0 .. 1_000.0 > with Mode => Round_To_Nearest_Even; > > These are representation issues. Representation is a property of a type. Whether representation is relevant to the semantics of the type depends on the domain space. The type determines the semantics and relevant aspects of the representation. Not otherwise. > I guess there is a view that says rounding is a type? Certainly. Rounding behavior is determined by the semantics of some type operations. > So what: > > An encoding aspect would just be a means that allows programmers > to say what they mean. If aspect maps to a distinct type then yes. But it is futile to talk about aspects as "Ada's RM aspects" because it is unclear whether they are related to the semantics or are implementation artefacts. Ada 2012 blurred it beyond recognition. > After all, this is about interpreting a bit pattern at compile > time, No. There is no bit patterns at compile time. The compiler operates on an alphabet. Ada's alphabet in unambiguous: RM 2.1. Consider an Ada source packed using LZH. Does that produce another program? No, the program is same. You can use punched cards instead, or write it down on a coaster, it is still the same program. > Even when using 7bit ASCII, there is *no* information in the > source that explicitly states what is meant in a given ASCII > String literal. Again, it has nothing to do with encoding. Which is why errors here are so dangerous. > So, saying that ASCII works is just accidentally > right. Nothing accidental in the case of UTF-8 reinterpreted as Latin1 and conversely. It works because ASCII is an integral part of either. Thus an Ada program written in ASCII is invariant to UTF-8, Latin1 and many other 8-bit encodings. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de