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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-01 03:02:37 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: left-to-right (was In-Out Parameters for functions) Date: Mon, 01 Mar 2004 12:12:39 +0100 Message-ID: References: <1077634311.254581@master.nyc.kbcfp.com> <3c0u3054mganvifajj3g6jealh07qoi1h7@4ax.com> NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1078138956 53309904 I 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:5968 Date: 2004-03-01T12:12:39+01:00 List-Id: On 28 Feb 2004 08:22:20 -0500, Stephen Leake wrote: >Dmitry A.Kazakov writes: > >> On 27 Feb 2004 09:07:12 -0500, Stephen Leake >> wrote: >> >> >> >Why is that better? The goal is to have code that works (meaning >> >> >produces correct results :), on all compilers/platforms. >> >> >> >> But the code has some semantics it implements, at least I hope it is >> >> so (:-)). This semantics is either order-dependent or not. That does >> >> not depend on platform. The goal is to implement that semantics. The >> >> rest does Ada. >> > >> >Right. And _if_ the semantics happens to be order-dependent, then to >> >be portable, the same order must be used on every compiler/platform. >> >> Then the semantics has to be *explicitly* expressed in the code, as an >> important part of implementation. The code reader should clearly see >> it, and say, aha! > >Yes! the code should certainly express the desired semantics! > >I'm not clear what your point here is. Expression notation was designed to resemble the mathematical one, which has no evaluation order. A sequential order in a formula is a rare exception. The left-to-right sequential order is an exception of exception. If we want to define an order, then we should use a notation that clearly indicates the order. An infix notation does not. To pretend that it does would be misleading. >> >So we need to talk about why you believe this to be the case - we >> >cannot simply say "yes, you are right". >> >> We cannot, because it would mean that there are no cases where the >> semantics is order-independent. > >Why is that a problem? > >Matrix multiply semantics is order-dependent (not evaluation order, >but multiply order). You mean that matrix multiplication is not commutative (A*B /= B*A)?, because it is associative: A*(B*C) = (A*B)*C. > Again, I'm not getting your point. When I see A*B*C in a program I do expect that "*" is a multiplicative operation. Further I expect that operands evaluation order is irrelevant, because the notation tells nothing about it, and I really do not want ARM to specify it. It would break the abstraction. Should I really know whether A is a function, reference or a register? Isn't dereferencing A an evaluation? Should that also be made left-to-right? Are cache effects relevant? Should ARM define them? >> Occam's razor priciple - to have code valid under possibly least >> strong assumtions. Weaker they are, higher is the code quality. > >Then we should all be using SPARK. I do not think so. SPARK limits many things to gain checkability. This actually also violates the principle of least strong assumtion, as left-to-right order would do. The difference is that SPARK gives a valuable gain - checkability. I feel that left-to-right order rather makes error detection harder, by making broken code working. Maybe it would appropriate to remember PL/1 lessons here. They also tried to specify a conversion in all possible cases. Made it PL/1 more portable, readable? >There is a trade off to be made; >readability vs portability vs efficiency. Ada 95 made one choice for >the trade off; we are discussing other possible choices. I hope that it can be reconciled by wider using DbC. If a user-defined operation has an interesting side-effect, that should be specified in the contract and later checked in all cases where the side-effect is used. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de