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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.uni-weimar.de!medsec1.medien.uni-weimar.de!lucks From: Stefan.Lucks@uni-weimar.de Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Fri, 5 Apr 2013 21:55:27 +0200 Organization: Bauhaus-Universitaet Weimar Message-ID: References: <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> <4hzv51v872q2$.1imijbwd7heqm$.dlg@40tude.net> NNTP-Posting-Host: medsec1.medien.uni-weimar.de Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-507350925-1365191728=:31746" X-Trace: tigger.scc.uni-weimar.de 1365191798 1560 141.54.178.228 (5 Apr 2013 19:56:38 GMT) X-Complaints-To: news@tigger.scc.uni-weimar.de NNTP-Posting-Date: Fri, 5 Apr 2013 19:56:38 +0000 (UTC) X-X-Sender: lucks@debian In-Reply-To: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Xref: news.eternal-september.org comp.lang.ada:14879 Date: 2013-04-05T21:55:27+02:00 List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-507350925-1365191728=:31746 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 5 Apr 2013, Dmitry A. Kazakov wrote: > On Fri, 5 Apr 2013 17:16:59 +0200, Stefan.Lucks@uni-weimar.de wrote: >> I agree with you that there is no reason to distinguish between them. Th= e >> entire distinction narrow, Wide_ and Wide_Wide_ Strings (and Characters) >> is a historical artifact, no more, no less. >> >> But if there is no reason to disting between them -- there is no reason = to >> mix them either! > > Sorry, but it cannot be both. No, if you mix them, you must distinguish them. At least, when=20 implementing your own multi-method, such as function Longest_Common_Substring(S1, S2: Universal_String) return Universal_String; -- maybe "is abstract"; Either Universal_String is abstract, then so would be this multi-method,=20 and you would to override it n^3 times, when supporting n different string= =20 types. Or you can actually have objects of type Universal_String, but then= =20 using this method without making explicit conversions means a whole new=20 bunch of implicit conversions. One problem with implicit conversions is that Strings don't "know" their=20 encoding (Is it UTF-8? Or ISO-Latin-1? Or ...?), so you don't even have=20 the information you need to perform the conversion. Which is why you need= =20 to make explicit conversions. And then it is not a big leap to say "convert everything into my favourite= =20 kind of string, then call my method, and then convert the result back". > Consider Ada.Text_IO.Create. It has name a string and content. You tell= =20 > us that it is not necessary to be able to open an UTF-8 file which name= =20 > is UTF-16? Blame Microsoft. I know a lot of things to blame Microsoft for, but in the Unix world, all= =20 files are essentially sequences of bytes that you read or write, and it is= =20 your problem to know the semantic of these sequences. So this is not much= =20 better than in the Microsoft world. In any case, Ada.Text_IO.Create is a good example. As much as I understand you, if Name is of type Universal_String'Class and= =20 you call Ada.Text_IO.Create(File, Name) you expect the proper thing to=20 happen, right? I agree that this would be cool. But it just cannot work! Right now, if the encoding of Name is, say, ISO-Latin-1 and the encoding=20 the underlying filesystem expects is UTF-8, you can have really surprising= =20 results when calling Ada.Text_IO.Create(File, Name). It would be cool to=20 solve this issue with some Universal_String type. But firstly, the strings we have don't know their encoding. The=20 application programmer knows (hopefully), but it is not part of String. Secondly, even if we had some kind of enhanced string type with object=20 Name storing its own encoding, in addition to the string itself, the=20 library wouldn't know which encoding it to convert Name into, or if=20 any conversion is needed at all! The point is, you can mount different filesystems with different naming=20 and encoding conventions, even on the same machine. (With Linux for=20 sure, I guess that also works in the Microsoft world.) No Universal_ type will solve this issue -- you just cannot get rid of=20 explicit conversions. At the end of the day, something such as opening or= =20 creating a file is some kind of a low-level operation, alas. >> I think, I agree with Randy here. The old bunch of strings are a mess, > > There is nothing wrong with them except for being not in the same class. > [Literals could be done better] > Furthermore what Randy proposes will actually be worse than pitiful > Unbounded_String. For them you could at least do this: > > type Relative_File_Path is new Unbounded_String; > type Absolute_File_Path is new Unbounded_String; > > You could not do that for tagged strings. OK, here we agree. Whatever the "new" strings are, the ability to define=20 incompatible types with the same representation, that you cannot mix=20 (without explicit conversion) is important for a language supporting=20 safety-critical stuff! I sometimes have types Tainted_String and=20 Save_String, being both derived from [Wide_[Wide_]]String, and I am happy= =20 when the compiler stops me from messing up between variables of this type.= =20 Does Randy's proposal really not allow that? ------ I love the taste of Cryptanalysis in the morning! ------ --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universit=E4t Weimar, Germany-- --8323329-507350925-1365191728=:31746--