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,24d7acf9b853aac8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Fri, 13 Aug 2010 19:52:04 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <13b07f2c-2f35-43e0-83c5-1b572c65d323@y11g2000yqm.googlegroups.com> <13tpf7ya3evig$.h05p3x08059s$.dlg@40tude.net> <1omt2srxtpsga$.c3hbxthzo6cf.dlg@40tude.net> <1e4cch2df5uyb.18brqdd16dhv8.dlg@40tude.net> <14y70ke8am9qw$.2csc9eflvigg.dlg@40tude.net> <1y1c8zzqmcer5.po56hkesa968.dlg@40tude.net> <1o6jah15584x1$.1arrrgog9jdk7.dlg@40tude.net> <1spow9sibnv6l.ci558lff75c8$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1281747127 16710 69.95.181.76 (14 Aug 2010 00:52:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 14 Aug 2010 00:52:07 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!feed.ac-versailles.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail Xref: g2news1.google.com comp.lang.ada:13258 Date: 2010-08-13T19:52:04-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ayxycml2mo60$.1g3uh1fg6m3r0.dlg@40tude.net... > On Thu, 12 Aug 2010 15:56:41 -0500, Randy Brukardt wrote: ... >> Octets don't have a sum, "sum of octets" is meaningless. It's like >> talking >> about the "sum of sand". They're just buckets. > > The content of the bucket does have sum. Compare it with the elements an > integer array. According to the logic since array elements are buckets you > cannot sum integer elements. By "bucket" here I mean a semantic-less collection of bits. Integer elements can be summed because they are integers. Buckets of bits don't make sense to be summed. >> (By "octet" here I mean the >> same concept that Ada calls Stream_Elements, other than with a fixed >> size.) > > 1. This is not the way octets are used in communication applications. No idea. I use Stream_Elements the way I describe here in *my* applications, but YMMV. > 2. If the idea of opaque container is pushed to its end, octet must have > no > "and", "or", bit extraction operations either. They also presume some way > octets can be manipulated and interact with other types (like Boolean). Correct, an octet should have no operations whatsoever. It's just a bucket of bits for transport; it needs to be converted to something real to use it, explicitly so it is obvious what is going on. Besides, I don't believe in bit operations groups of bits in the first place; they should be restricted to Boolean logic. (Ada 83 got this right, IMHO.) There is of course a certain expediency in copying bad ideas from other languages like C; that's whats going on with Ada modular types. But the whole thing is a bad idea from the start to the end. >> And if you do that, you now >> have a lot more chances for error (such as adding octets that are used to >> hold character values and not integers). > > Yes, when implementing a communication protocol, there is no such things > as > characters or integers, only octets. This is independent on the octet > operations. Compare it with address arithmetic. You can sum address of a > task with the address of an employee record. Does it mean that there has > to > be no address arithmetic? I'm a radical on this, too. There should be no address arithmetic in programming languages; leave that to us compiler-writers, we can do a better (and much safer) job. Exposing that low-level stuff is a recipe for disaster. (Again, I realize that there are times, mostly in interfaces to low-level languages and hardware, where you need such things. But this is totally outside of the realm of anything that can be described with sane typing; it makes no sense to even try.) >> Octets are by their nature an >> untyped bucket with no semantics; there has to be a conversion operation >> (like "#" above or S'Read in Ada) to some type with semantics for it to >> be >> meaningful. > > No, that is impossible, because 1) there is no such conversion in almost > any case. Other objects are represented by collections of octets > interlinked in a very complex way. A simple conversion operation is > absolutely unsuitable abstraction for this. 2) You are talking about an > interface, (where however there should be no octets visible at all, but > streams, files etc), I am talking about implementation of such an > interface. There should be no conversions at any abstraction level. I don't have any idea of what you are talking about; it makes no sense to me at all. As you say, you should never have octets visible in the first place above the transport layer. And in that layer, the only thing that makes sense is a conversion to a meaningful type (S'Read is just a fancy name for Unchecked_Conversion, after all). >>>> That's the point: in Ada, type conversions are *not* functions, they're a >>>> built-in gizmo [including some attributed]; by naming them "#" we would >>>> allow unifying them with functions. >>> >>> I would prefer to eliminate them altogether. Conversions are always bad. >> >> I strongly disagree. Some things are best modeled with little or no >> explicit >> semantics (such as a raw stream), and you must have conversions to get to >> real semantics. Indeed, *not* having using conversions in that case is >> misleading; you're applying improper semantics to the operation. > > type Text_Stream is new Raw_Stream with private; > > What is wrong with that? It's applying misleading semantics to an entity; there can be no stream other than a raw stream; even if the stream carries typing information, that information has to be converted and interpreted before it can be used. I don't think this discussion is going anywhere anyway. Randy.