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,ac4955b8006bd13c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.220.230 with SMTP id pz6mr13133228pbc.3.1338887202514; Tue, 05 Jun 2012 02:06:42 -0700 (PDT) Path: l9ni5329pbj.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Q: type ... is new String Date: Tue, 5 Jun 2012 11:06:18 +0200 Organization: cbb software GmbH Message-ID: <1ch26v7folac1$.1gc355i72r55j.dlg@40tude.net> References: <82defba0-2d39-4418-b678-ebbefeb105d7@x21g2000vbc.googlegroups.com> <4fcccd1f$0$6583$9b4e6d93@newsspool3.arcor-online.net> <4fccdd0c$0$6578$9b4e6d93@newsspool3.arcor-online.net> <4fcd20dd$0$9519$9b4e6d93@newsspool1.arcor-online.net> <1tr1nuc1xy9mp$.d5s1fz9vuczz.dlg@40tude.net> <4fcdc605$0$9524$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: 2012-06-05T11:06:18+02:00 List-Id: On Tue, 05 Jun 2012 10:40:36 +0200, Georg Bauhaus wrote: > On 05.06.12 09:32, Dmitry A. Kazakov wrote: >> On Mon, 04 Jun 2012 22:56:01 +0200, Georg Bauhaus wrote: >> >>> On 04.06.12 19:05, Dmitry A. Kazakov wrote: >> >>>> There is nothing ambiguous in character encoding, >>> >>> In processing data from any source that speaks HTTP, you don't really know >>> the character encoding: you may be told the encoding is X but actually it >>> is Y. >> >> <=> I do know the encoding. > > You snipped the part that explained how this "knowledge" isn't > knowledge. It is in a state of flux and occasionally crystallizes > to yield Heisentypes. ;-) > > (All I see is subsequences of 2#bbbb_bbbb#. For the AI part, > I am told to produce the most likely information that the > originator might have intended to send.) Bad design. Don't do that. >> You are trying to pursue some absolute truth, e.g. "true encoding" of a >> broken page, which simply does not exist and is irrelevant. > > I am the one to create the truth, the valuable information. Like I am > the one to guess the correct interpretation of calendar date 5/6/7. Maybe, but that imposes no problem on software design. The mail program successfully transmitted "5/6/7" without making guesses. Do not conflate well-defined functionality, e.g. "send over socket", "render calendar page on the screen" with ill-defined stuff, like what is going on in someone's head. >> If you want to add some encoding guessing layer, do it just elsewhere. > > Too late. For broken design it is always too late. Fix the design. >>>> For each possible input >>>> there is a defined output the parser should spill. Where is a problem? >>> >>> Here is the problem: There is no complete description of the set of >>> possible inputs. >> >> See, that is the problem. People didn't do their job. > > No, they did their job. How an incomplete definition is job done? Now feel free to tell me that working without specifications, is the right way to develop software... >> Nope, things changing are as irrelevant as the computer's relative position >> to Proxima Centauri. > > So what is the outline of a type that describes a file naming > scheme that has changed? Why should I care about description of naming schemes? I need a set of types describing file name valid in some specified environment. It is not rocket science. Before you start confusing things again, this has nothing to do with parsing file names. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de