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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA 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,UTF8 Received: by 10.68.219.170 with SMTP id pp10mr11575501pbc.1.1338843358301; Mon, 04 Jun 2012 13:55:58 -0700 (PDT) Path: l9ni1725pbj.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.ecp.fr!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 04 Jun 2012 22:56:01 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Q: type ... is new String 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> In-Reply-To: Message-ID: <4fcd20dd$0$9519$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 04 Jun 2012 22:55:57 CEST NNTP-Posting-Host: 6e27d723.newsspool1.arcor-online.net X-Trace: DXC=]imA:Wg9I?Agj[ZPFj7ehOic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@@RHBLX;S0JCPCY\c7>ejVH`7R On 04.06.12 19:05, Dmitry A. Kazakov wrote: > On Mon, 04 Jun 2012 18:06:36 +0200, Georg Bauhaus wrote: > >> On 04.06.12 17:14, Dmitry A. Kazakov wrote: >> >>> malformed /= untyped. >>> >>> Typing is about a way to describe behavior. >> >> Well, yes, though in the web word, "type" may de facto mean "element type" >> at best. The problem with strings is not that one could speak >> about operations PUT, GET, DELETE, HEAD, and so on, and consider >> these the behavior of something. The problem is data that cannot >> reliably parsed and mapped to a set of properly typed objects. But >> we still must have that information! > > You are mangling OSI layers. Yes, deliberately changing layers for illustration of the layers that may yield a type. At my layer, every attempt at mapping the contents of a "string" to objects of a type is doomed to failure in case it should be general. This doesn't work without creating a slew of types that is as vague as its input. Sometimes input is undecidable without human intervention, so Turing completeness does not really help. Types would have to be ever changing, and complex, and flexible, and be developed in O(∞) of program writing time, all since they must adapt to changing input. > 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. Or, you get a mix of characters encoded as X here and Y there in the same document. Sometimes human intervention can help finding a correct interpretation, sometimes it can't. The problem is conceptually similar to that of determination of a calendar date, given 5/6/7 of a document written in English, issued by a French organization, written by a Swiss employee, processed by the usual software. > 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. It's the web. Changing. Data are not quite as lucid as a set of ways to designate a file. Is the latter set changing so frequently that the Ada standard would not be able to follow?