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!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!panix!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Mon, 09 Aug 2010 09:48:02 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: 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> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1281361666 32710 192.74.137.71 (9 Aug 2010 13:47:46 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 9 Aug 2010 13:47:46 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:wRbqEayCqQTFXrxBpbFtAeNvYp8= Xref: g2news1.google.com comp.lang.ada:12980 Date: 2010-08-09T09:48:02-04:00 List-Id: "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.) The above is illegal in every Ada compiler, because My_Unsigned is a _signed_ integer type, and nobody supports that range. Part of the reason modular types were invented is because signed integers don't work in cases like the above. >> 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? >> 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. If want to negate the result of "+", I should write "-". If want to take the modulus of the result of "+", I should write "mod". 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. - Bob