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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6bf1c4b845bd2160 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.xsnews.nl!feed.xsnews.nl!border-1.ams.xsnews.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: Wed, 25 Aug 2010 16:20:03 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: What about a glob standard method in Ada.Command_Line ? References: <4c6f9837$0$5420$ba4acef3@reader.news.orange.fr> <4c739e76$0$6992$9b4e6d93@newsspool4.arcor-online.net> <152a2z5en4z2o$.xjsuqr7s8yak$.dlg@40tude.net> <4c73e859$0$6991$9b4e6d93@newsspool4.arcor-online.net> <4c73fcf6$0$6992$9b4e6d93@newsspool4.arcor-online.net> <1jxm50y65grlo.sjyb9hm4y1xp$.dlg@40tude.net> <4c743a59$0$6893$9b4e6d93@newsspool2.arcor-online.net> <4c74db09$0$6890$9b4e6d93@newsspool2.arcor-online.net> <1r82cxcws3pc9$.r40m8l3ttil7$.dlg@40tude.net> <4c74f9f6$0$6772$9b4e6d93@newsspool3.arcor-online.net> <17drl4b1ko4iv.1eccfudluzl5h.dlg@40tude.net> <4c7515fc$0$7664$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: <4c752693$0$7656$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 25 Aug 2010 16:20:03 CEST NNTP-Posting-Host: 8eab98a4.newsspool1.arcor-online.net X-Trace: DXC=jLh>_cHTX3jmo9UYX]H=bii X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:13730 Date: 2010-08-25T16:20:03+02:00 List-Id: On 25.08.10 15:30, Dmitry A. Kazakov wrote: > If code points have nothing to do with String why do you propose to do it > with String? Because file names as entities external to Ada have got nothing to do with code points, from an Ada point of view: file names have to do with Strings, though. This is in part a consequence of how subprogram parameters in Directories.Start_Search were chosen. > And how is this related to the point anyway? Directories.Start_Search exposes a programmatic interface to names of files. String has might-work-best name components: Standard.Character, because the outside world is under the (full) control of the conflicting real world requirements of users, other programs, legacy buggy programs, assumptions... There is no completely working standard for file names. Conclusion: there cannot be a good, portable Ada type representing file names. No encoding will help, no abstraction will help. But what we have, and what does help, is a programming interface to the bare components of file names: String. (For me, not even file name Pattern is needed; but since Start_Search operates on String, and since scanning a directory (a) with OS pattern (b) without OS pattern might result in the same computer operations, I thought we might as well add another Start_Search that makes Pattern passive: just fetch filenames one by one as in (b) and let the programmer select based on RE matching after the fact.) >> The important question is what constitues Σ, > > http://en.wikipedia.org/wiki/Code_point Start_Search is based on String; file names do not obey the rules of ISO 10646; no hope. Practically, the Σs established by external file names are not free of contradictions or ambiguities. But String can potentially remove the contradictions, because it does not care about the meaning of a sequence of (let's say) octets. This is the big plus of String: power to the programmer who assigns meaning to sequences of octets. And this is the big plus of String based REs: they do not care about the meaning of a sequence of octets either, but they can be employed to *find* meaningful sequences when tackling real world file names. >From here, one can go on to a different type from the collection that covers Unicode. > It could > represent some encoding of Σ*, which is the point. Exactly. And since there is no single, well defined, portable Σ for file names, the best we can do is inspect their encoded representations (String) and have our programs draw their own conclusions. Georg