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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!feeder.news-service.com!newsfeed.straub-nv.de!noris.net!news.n-ix.net!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: S-expression I/O in Ada Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> <8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com> <258zlxrv4fn6.1vszho1rtmf48$.dlg@40tude.net> <984db477-973c-4a66-9bf6-e5348c9b95f2@n19g2000prf.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> Date: Mon, 9 Aug 2010 22:27:45 +0200 Message-ID: <1y1c8zzqmcer5.po56hkesa968.dlg@40tude.net> NNTP-Posting-Date: 09 Aug 2010 22:27:45 CEST NNTP-Posting-Host: 4ebaf617.newsspool2.arcor-online.net X-Trace: DXC=ACAbil0\2BOFJ3]dH>I?oEA9EHlD;3YcB4Fo<]lROoRA8kF On Mon, 09 Aug 2010 13:00:38 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> On Mon, 09 Aug 2010 09:48:02 -0400, Robert A Duff wrote: >> >>> "Dmitry A. Kazakov" writes: >>> >>>> The implementation or the idea? Would you agree that objects with some >>>> properties of modular integers have place in Ada programs which do not >>>> interface C? >>> >>> No. I do not like implicit "mod". But that's the essence of >>> modular types. >>> >>> If I ran the circus, then this: >>> >>> M : constant := 2**64; >>> type My_Unsigned is range 0..M-1; >>> pragma Assert(My_Unsigned'Size = 64); >>> >>> X : My_Unsigned := ...; >>> Y : My_Unsigned := (X + 1) mod M; >>> >>> would be legal, and would not raise any exceptions, even when >>> X = M-1. (And I'd want "(X + 1) mod M" to be implemented >>> as a single "add" instruction on a typical 64-bit machine.) >> >> What does "+" above return? > > A value of type My_Unsigned. The values of this type are > the infinite set of all integers -- that's already the > case in Ada, except that the RM allows (not requires) > certain calculations to overflow and raise C_E. OK, but it is not modular, it is natural. And it is just a different case where modular types should not be used in first place, like size_t. Equivalent Ada types like Storage_Offset are not modular. >>...Is "mod M" a required part of the notation or >> not? > > No, not required -- my idea is that if you want to > perform some operation ("mod" or "+" or "*" or anything), > you write that explicitly in the code. No change there > from the way signed integers already work. Yes, but not for modular types! (:-)) >>>>> Perhaps they _should_ be unordered, but I won't agree or disagree, >>>>> since I think in an ideal world they should be banished. >>>> >>>> I think they could be fixed. >>> >>> How? And having fixed them, when would you use them? >>> That is, when would you prefer them over signed integers? >> >> Ring buffer indexing, > > I prefer an explicit "mod" there. This is will be a source of errors like forgetting mod or specifying wrong modulus. The idea of modular types is to prevent such errors. >>...flags (by-value sets actually), > > I prefer array-of-Boolean over modular. Even better would > be a proper user-defined abstraction, with notations like "in". Agree >>...cryptography, > > Explicit "mod". Disagree. >> interfacing, communication. > > For these, you don't want modular semantics -- you just want > a data type whose representation matches what you're > interfacing/communicating with, such as "type Octet is > range 0..2**8-1;" The problem is that these things require both array-of-Boolean view and arithmetic. I agree that when arithmetic is used, then it has to be wide. E.g. when interpreting sequences of octets as little/big endian numbers, we never use modular arithmetic. But integer arithmetic is incompatible with array/set view. I.e. once you added something it is another type integer: function "+" (Left, Right : Octet) return Universal_Integer; >> I think that all these usages require different types of modular types with >> different sets of operations. So I would prefer a language extension which >> would allow me construction of such types rather than built-in ones, which >> satisfy no one. > > I certainly agree with that. But it sounds like you are > agreeing with my point -- that modular types should not > be in the language. Yes, but what I want will never become Ada, so I prefer that minimum I can get. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de