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: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.66.76.38 with SMTP id h6mr2859055paw.15.1345670294944; Wed, 22 Aug 2012 14:18:14 -0700 (PDT) Path: a8ni5300815pbd.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 22 Aug 2012 23:18:16 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502e9039$0$6557$9b4e6d93@newsspool4.arcor-online.net> <40tmogy4d1b5.1kc2gm8qfrkdu.dlg@40tude.net> <503240ed$0$6569$9b4e6d93@newsspool3.arcor-online.net> <50326457$0$6576$9b4e6d93@newsspool3.arcor-online.net> <1qril0ny3eczr$.1vlhpbrjyyb8k.dlg@40tude.net> <503375ac$0$6565$9b4e6d93@newsspool3.arcor-online.net> <1vglgit7vnu4l$.2ytljabrhk2.dlg@40tude.net> <5033986c$0$6573$9b4e6d93@newsspool3.arcor-online.net> <62h5nifarvom.1myeqdyevhefq.dlg@40tude.net> <5033b4d8$0$6571$9b4e6d93@newsspool3.arcor-online.net> <5033ff28$0$6185$ba4acef3@reader.news.orange.fr> <5034dac1$0$6579$9b4e6d93@newsspool3.arcor-online.net> <50350d35$0$6579$9b4e6d93@newsspool3.arcor-online.net> <1xdzh15anpuc0.1xw8mwmojasjk$.dlg@40tude.net> In-Reply-To: <1xdzh15anpuc0.1xw8mwmojasjk$.dlg@40tude.net> Message-ID: <50354c95$0$6577$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 22 Aug 2012 23:18:13 CEST NNTP-Posting-Host: e9348e8f.newsspool3.arcor-online.net X-Trace: DXC=AIeB5FWbnnOE4ZB2flKORAMcF=Q^Z^V3H4Fo<]lROoRA8kF_ljHiLPCY\c7>ejVH]6BU]5=I;nGPEU051>A?;H X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Date: 2012-08-22T23:18:13+02:00 List-Id: On 22.08.12 19:44, Dmitry A. Kazakov wrote: > On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote: > >> On 22.08.12 16:30, Dmitry A. Kazakov wrote: >> >>>> As always, the question is inefficient for what and for whom. >>> >>> For the network and the peers. The measures for both can be easily >>> provided. >> >> Well, that would depend on the specifics of "network" and its mode >> of use, wouldn't it? > > There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so > on. In the set called "and so on", information retrieval programs will be efficient at all once they can interpret a data item to be an object for which FLOPs make any sense. That's easier to see when there is markup than when the program needs to guess if some four octets could be a float. >>>>> 2. fails to capture the structure (e.g. recursive, interlinked structures) >>>> >>>> ? >>> >>> Take Containers.Doubly_Linked_Lists as an example. The closure object of a >>> list is the structure in question. >> >> "closure object" = ? > > Linked list is not an object. An object could be a closure of the list upon > the relation predecessor-successor, e.g. a set of linked nodes. So the closure could be mapped to ... what if not an object? >> >> >> >> >> > > Which speaks for itself. Indeed, it shows that you can have the kind of structures you wanted; I'll gladly add recursive structure � la Ada; for now, l'(it'(id => one, f => two, others => <>), it'(id => two, f => three, b => one), it'(id => three, b => two, others => <>); Stream this aggregate to a C++ program outside your project ... >>>>> 6. requires complex, resource consuming, vulnerable infrastructure like >>>>> parsers >>>> >>>> Yes, there are cases where such parsers are needed, and even more >>>> of such things. For example, if you run Google. >>> >>> Remember that the case in question is "exchanging structured data," not >>> running Google. >> >> Google is the biggest thing on earth that exchanges data with >> just about everything outside microwave ovens. > > This is why XML would not require complex, resource consuming, vulnerable > parsers? XML will not require complex, resource consuming, vulnerable parsers once applications need not input non-XML data, such as Excel files or HTML pages. >> The purpose of "syntactic excess" of XML is about the same as in Ada: > > Not at all. Ada's redundancy is here to reduce influence of certain class > of programming errors. For example, Ada has named brackets in place of overloaded brackets in many places. Like XML. > Ada is not proposed for exchanging structured data > between computers. It is, however, required to say how to exchange structured program source text between compilers. > Ada is a programming language. XML in this context plays > the role of a protocol to exchange above mentioned data. No. It is a markup language for tagging data in text documents. We have been here before. > The nature of > errors which may appear upon such data exchange, their behavior has close > to nothing in common to the typo errors programmers do when they write Ada > code. When programmers correct errors that the compilers have found, some of the are strictly syntax errors, others are of a more grammatical nature. Source text not being a stream of octets makes correcting Ada source text easier. Similarly for XML. >>>> You don't have to write parser infrastructure when you >>>> can use XML. >>> >>> 1. I don't need parser if I don't use XML. >> >> I need to write many parsers if I can't use XML. I use data not >> generated by our programs. > > In that case this is irrelevant to the issue. Irrelevant to your issue, I guess, of exchanging data in a network where all components know what's required to participate. The issues other people face have to do with mutual, deliberate lack of information, and with non-coordination. If inscrutable serializing is added on top of that, parties end up with trial and error. That's a lot less so when they at least use XML. > A protocol similar to one of Ada streams deploy does not need > parsing. An exchange of data using streams does not work without agreements on the stream's content; streams from 'Write are not usually self-documenting. That's a lot less so with XML, therefore XML is a suitable choice in situations without agreements. >>> Safety could be against >>> >>> 1. intentional misuse >> >> I don't see how any source of data could protect against misuse of data >> once data have left the "building". > > http://en.wikipedia.org/wiki/Digital_signature Party A 1 <----> * Party B Party A provides data together with a signature. The signature says that what was sent was really sent by A. How does a signature prevent misusing what was sent? (How can a signed kitchen knife prevent its use as a weapon?) The recipient does not learn anything except that the origin is A. The recipient cannot validate the structure using a signature. The recipient is free to use information in ways not foreseen. No accessible piece of data in whichever shape of form can be protected from being used in any way. Being able to interpret data is a consequence of assigning meaning to its parts. A and B may have differing views on that. There are networks without an arbiter. Then, if things work for both A and B, then they are both right. >>> 2. unintentional errors >> >> ? > > E.g. typo errors. Baiting, when you type some garbage to let the compiler > to make a suggestion etc. XML does not only provide for error recovery, as do other ways of exchanging data. (E.g. through bracket naming, or through a redundant amount of syntax; some markup is redundant in that an SGML/XML processor could infer it without running into ambiguity). It can also have good effects on producers of XML insofar as they can employ ubiquitous tools to make sure they are really producing XML documents. Many do.