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 X-Google-Thread: 103376,73cb216d191f0fef X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.24.132 with SMTP id u4mr8567801wif.6.1366357104446; Fri, 19 Apr 2013 00:38:24 -0700 (PDT) Path: hg5ni20931wib.1!nntp.google.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Fri, 19 Apr 2013 09:39:29 +0200 Organization: cbb software GmbH Message-ID: References: <516e6a0e$0$9505$9b4e6d93@newsspool1.arcor-online.net> <516efa28$0$9518$9b4e6d93@newsspool1.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-04-19T09:39:29+02:00 List-Id: On Thu, 18 Apr 2013 21:16:58 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:qtagj9gwjjxn$.ljj8purwznkr.dlg@40tude.net... > ... >> Your concept simply does not hold. There are simple indisputable facts: >> >> 1. The representation of string object is irrelevant to what string is. > > This is clearly false, so it's pretty clear why you end up with bizarre > conclusions. http://en.wikipedia.org/wiki/String_%28computer_science%29 > Specifically, the number of characters that a string object can hold (and > whether that number can change, and by how much) is *indisputably* a > critical part of string object semantics. Confusing semantics of objects with semantics of values they hold? Anyway your argument is evidently bogus as follows from: X : constant Unbounded_String := whatever; Is X a string object? Can you change the number of characters in there? Does it have a different representation? Do you care if it does? > It's certainly true that you can have an abstract string interface that > doesn't expose the representation -- that's the idea behind my > Root_String'Class proposal -- and that's useful in a limited set of > circumstances (mostly in read-only situations, which is the majority of > string operations anyway). But it does not describe the complete semantics > of a string object, nor could it. "Complete semantics" (whatever it means) /= string semantics. >> 2. It is impossible to have one implementation suitable for all string >> objects and all application domains that use strings, e.g. DNA sequencing, >> pattern matching, text processing, compiler construction etc. > > Of course. So what? Multiple string types => have to mix them [in the contexts where only string semantics is relevant] > That's why we want a variety of string types for > different jobs. That gives no reason why anyone should be mixing them! It is the reason, because otherwise you must show that no program can do more than one job ever. > What > do you get when you concatenate a DNA sequence and an Ada identifier? Meaningless question as there is no string type of Ada identifiers. Are you arguing that Ada identifiers require a special representation? A different representation from C identifiers? Are you saying that some string types shall not be mixed? Remember our discussion about cloning types? This has nothing to do with representations: type Ada_Identifier is new String; type C_Identifier is new String; The representation is same. Types are different. String semantics is same. Semantics relevant to compiler/parser construction could be same or different depending on the circumstances. You cannot determine this at the language level. You shall leave that to the programmer. It is his decision only whether types he designs to be mixed or not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de