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!weretis.net!feeder4.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!news.belwue.de!newsfeed.arcor.de!newsspool3.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> <1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net> <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> Date: Mon, 9 Aug 2010 16:38:31 +0200 Message-ID: <14y70ke8am9qw$.2csc9eflvigg.dlg@40tude.net> NNTP-Posting-Date: 09 Aug 2010 16:38:31 CEST NNTP-Posting-Host: 852822d1.newsspool3.arcor-online.net X-Trace: DXC= 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? Is "mod M" a required part of the notation or not? >>> 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, flags (by-value sets actually), cryptography, interfacing, communication. 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. Just one example from a huge list, why "in" is not an operation? if 0 /= (Mode and Alarm) then -- Isn't it awful? why am I not allowed to have: if Alarm in Mode then >>> By the way, one defense of modular types I've heard is that >>> they are used in mathematics. True. >> >>> But mathematicians do >>> not use _implicit_ mod. They say things like "X = Y (mod N)", >>> which is pronounced "X is congruent to Y (modulo N)". >>> Congruent, not equal. >> >> The mathematical notation (mod N) is untyped. It applies to any natural >> numbers and what is worse you have to add it at each point of the program >> you use the type. > > Writing "mod" whenever I want an expression that takes the modulus is > a GOOD thing. "+" should always do an add, and nothing else. Huh, modular "+" *does* add in the ring. Your "+" does not! > If want to negate the result of "+", I should write "-". Negative inverse in a ring is not one of integers. They are different types. It is good and helpful that Ada promotes this difference. > If want to take the modulus of the result of "+", I should > write "mod". That would be a type conversion. Bad thing. But I see no problem with that. Give me universal integers or equivalent "2 x width" type and you will get what you want in return: function "+" (Left, Right : Modular) return Universal_Integer; -- overloads standard +, if that exists -- function "mod" (Left, Right : Universal_Integer) return Modular; -- just to remember, it already exists That's it. > Look at how unsigned types are used in C. size_t is a good > example. It's used to count up the sizes of things. > If I have 1000 objects of size 10_000_000, the total > size is 1000*10_000_000 = 10_000_000_000. If that > calculation wraps around on a 32-bit machine, the > answer is just plain wrong. I'd rather get Constraint_Error. > > If I interface to C's size_t, and do similar calculations on > the Ada side, wraparound is equally wrong. I agree. But it rather means that C is wrong defining size_t modular. On Ada side it must be Natural_32. Why Ada does not support that? Why is it impossible to declare 32-bit range 0..2**32-1 without wrapping (=with overflow check)? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de