Re: What about a glob standard method in Ada.Command_Line ?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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