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!news3.google.com!feeder.news-service.com!texta.sil.at!newsfeed01.chello.at!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 09 Aug 2010 18:46:27 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.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> <4c601b5c$0$7665$9b4e6d93@newsspool1.arcor-online.net> <9czktq4ntzq7.fhbsnocx0x4w$.dlg@40tude.net> In-Reply-To: <9czktq4ntzq7.fhbsnocx0x4w$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <4c6030e3$0$7659$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 09 Aug 2010 18:46:27 CEST NNTP-Posting-Host: 3a55c806.newsspool1.arcor-online.net X-Trace: DXC=_OMWeMLAQ4d>jlK2>IgHGdic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbkkVBCm`oO1jnc\616M64>jLh>_cHTX3jmX?::J2gC?=o X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:12988 Date: 2010-08-09T18:46:27+02:00 List-Id: On 09.08.10 18:11, Dmitry A. Kazakov wrote: > On Mon, 09 Aug 2010 17:14:36 +0200, Georg Bauhaus wrote: > >> On 09.08.10 16:38, Dmitry A. Kazakov wrote: >> >>> 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 >> >> Is anything wrong with packed arrays of Booleans for status thingies? > > 1. The membership/subset tests look even worse OK. But I guess we could write inlined functions? > 2. No ranges > 3. No loops > 4. No case statement You have the index subtype at the point where you have the array type. Why not ranges, loops, and case statements? > 5. Array aggregates as literals aren't not fun Fun? > 6. No discriminants of > 7. No array index of These refer to arrays in general, not Boolean arrays as sets and, I guess, the item numbered 7 follows a general rule: Where the array type is visible, its index type is visible. (Or else, you have been too lazy and used an anonymous index type; still, you have 'first etc.) Therefore, the index type can be named without indirection, that is, via some array attribute function. (Or else, index values can be made from 'first etc.) Array access will be type checked either way. > Note that array must be a view of a modular type An array of Booleans for status fields must be a view of a modular type? I don't understand that. > with the modulus 2**N, but > the type itself must remain scalar. Uh, which type must remain scalar? >> A definition of the "+" operator, whose meaning(s) is (are) >> stipulated to be well known, seems impossible: > > http://en.wikipedia.org/wiki/Abelian_group ? That's normative ontology, not empirically justified language design ;-) I remember having seen introductory texts covering algebraic structures that use a symbol other than "+" to denote the additive operation. I think the authors have a good reason. One reason might be that they know their audience. This is an example of empirically justified use of operator symbols. When good average programmers write programs, are they structuring their data by conscious use of mathematical structures like groups? I don't think so. It is these programmers that need to know the meaning of "+". This seems vital. Example: C's "definition" of the data type int and its "+" operation demonstrates what happens if you are optimistic about mastery of C's "+" basics. I think Bob's example involving "not" of a mod 3 variable shows a related issue. (And will be included in a test of advanced Ada knowledge? ;-P) Because *even* *though* there is a precise mathematical definition (LRM) of what "not" should return, referring to some overly complex set of rules explaining the operation is hardly convincing? Consistency of the language (with itself) is only an excuse, then. Georg