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 Path: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Thu, 12 Aug 2010 15:56:41 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <46866b8yq8nn$.151lqiwa0y2k6.dlg@40tude.net> <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 1281646603 25023 69.95.181.76 (12 Aug 2010 20:56:43 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 12 Aug 2010 20:56:43 +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 Xref: g2news1.google.com comp.lang.ada:13195 Date: 2010-08-12T15:56:41-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1spow9sibnv6l.ci558lff75c8$.dlg@40tude.net... > On Wed, 11 Aug 2010 18:18:48 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg@40tude.net... >> ... >>> Conversion mess is what we already have right now. The point is that "+" >>> is >>> well-defined and meaningful for octets, but it is not closed in there. >>> Why >>> >>> function "**" (Left : T; Right : Natural) return T; >>> function S'Pos(Arg : S'Base) return universal_integer; >>> ... >>> >>> are OK and "+" is not? >> >> The first has the same operand and result type (the power operand is >> something else and not really part of the operator IMHO). > > What is the difference between "**" and "+"? It must be a language one, > because semantically sum of octets is not an octet. Octets don't have a sum, "sum of octets" is meaningless. It's like talking about the "sum of sand". They're just buckets. (By "octet" here I mean the same concept that Ada calls Stream_Elements, other than with a fixed size.) >> The second is the >> long winded name for a conversion operator - it implies no semantic >> change. >> I'm arguing that operations like S'Pos would be better having a common >> name >> like "#" rather than a host of specialized names. > > Huh, and these must be a type conversions too: > > function S'Exponent (X : T) return universal_integer; > S'Length > A'Length (N) > ... Nope, these have semantics. Of course, the boundary is a gray area. ... >>> 1. What is this else? >> >> Huh? This doesn't parse. > > The above looks like math to me. You take octet arguments and compute some > results using arithmetic operations. The octets are converted to some other type that has math. There is no built-in relationship between the octet and the type with the math; it has to be explicitly defined. ... > I see. No, that is a wrong way IMO. The right one is interfaces. If you > want S be like T, derive S from T. If you don't like the implementation of > T, inherit only the interface of. You should never have a need in explicit > type conversions in a properly designed program. That way lies madness. You would have to give types properties that they have no reason to have (like "sum of octets"). 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). 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. >> 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. Randy.