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!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!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 13:00:38 -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> <14y70ke8am9qw$.2csc9eflvigg.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1281373220 15369 192.74.137.71 (9 Aug 2010 17:00:20 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 9 Aug 2010 17:00:20 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:upri/0gubrjM6VG6VZ8ERftzvco= Xref: g2news1.google.com comp.lang.ada:12991 Date: 2010-08-09T13:00:38-04:00 List-Id: "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. >...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. >>>> 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. >...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". >...cryptography, Explicit "mod". > 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;" > 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. > 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)? Good question. - Bob