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,334f9012742e58fc X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Gnat GPL 2010 available soon (conditional expressions) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <2010061621145016807-sjs@essexacuk> <4c270613$0$6974$9b4e6d93@newsspool4.arcor-online.net> <1wuwvzgwlwgli$.1birkinieia0d$.dlg@40tude.net> <1ur19ais2ejih.mjbgdsv9pr66.dlg@40tude.net> <4c275562$0$6987$9b4e6d93@newsspool4.arcor-online.net> <4c276114$0$2378$4d3efbfe@news.sover.net> <7ec98a71-edcb-4851-87fd-6702fb963829@q12g2000yqj.googlegroups.com> <8ac6b8d6-f4c0-4a8b-b3aa-ff6f2d136544@k39g2000yqb.googlegroups.com> <1wl74eppoqii9$.1oxpbe851z3jk$.dlg@40tude.net> <87dfe70c-fd5b-4b76-8e37-b38539826502@y11g2000yqm.googlegroups.com> <4payn5nzd163$.8nb20d9btack.dlg@40tude.net> Date: Wed, 7 Jul 2010 15:39:27 +0200 Message-ID: NNTP-Posting-Date: 07 Jul 2010 15:39:27 CEST NNTP-Posting-Host: a90c20b3.newsspool4.arcor-online.net X-Trace: DXC=P^hZLVPZERheoCI^f\Y]Ea4IUK On Wed, 7 Jul 2010 05:00:47 -0700 (PDT), Phil Clayton wrote: > On Jul 6, 6:18�pm, "Dmitry A. Kazakov" > wrote: >> On Tue, 6 Jul 2010 09:31:05 -0700 (PDT), Phil Clayton wrote: >>> The concept of an order is important because the function F could have >>> side effects in the above example (though I would not advocate that as >>> good practice). >> >> AFAIK, presently the order is not defined. So though this is legal >> >> � �X : String (1..80) := (others => Character'Read (Stream'Access)); >> >> It is not a good idea. > > It would be good if the order was not defined because that would > prevent people depending on it, so making it easier for a compiler to > parallelize. But then the language should define pure functions (relatively to the given context) and prohibit usage of impure ones in the constructs like above. >>> However, we would be able to write >> >>> � (for I in reverse A'Range => A(I)) >> >>> to represent the reverse of the array A is perhaps a little confusing. >> >> The effect is undefined. Theoretically the compiler could initialize array >> elements concurrently on a multi-core processor. > > There are really two concepts here: > 1. the order of evaluation of the expressions for each index > 2. the value the bound variable I gets for each index > > I didn't make it clear that I was switching from [1] to [2], sorry. > This above reverse example was really about [2] to show that the use > of the keyword 'reverse' would result in I having the value A'Last at > index A'First, A'Last - 1 at index A'First + 1, etc. OK. The objection is that in this case I is not the array's index, but a mapping of. That looks totally obscure. >>> Also, it really only makes sense to have one variable holding the >>> array index. �For example, if we could write >> >>> � (I, J : 1 .. 5 => ...) >> >>> surely I and J would always be equal: there are only 5 elements in the >>> array. �Having >> >>> � (for I in 1 .. 5 => ...) >> >>> syntactically rules out multiple variables. >> >> Yes, but many other things as well. However I prefer an absolutely >> different approach anyway, e.g. proper index types. In my world a diagonal >> would be initialized like: >> >> � �(Diagonal (5, 5) => 1.0, others => 0.0) >> >> where Diagonal is a proper function. > > Interesting.. how would you make the expression a function of the > index? I don't want such expressions at all. I mean if these are necessary it must be a function returning an array. Reading aggregates containing some inlined code is not readable to me. This is yet another topic, but I favor user-defined aggregates instead of hard coded special stuff like index dependent expressions. E.g. if you have some frequently used special type of "array literals" you should be able to provide a custom aggregate of. For example, let you deal with band matrices. The language should allow you to define a custom aggregate like A : Square_Matrix := ( Upper => (1.0, 2.4), Diagonal => (7.3, 8.0, 9.1), Lower => (3.0, 2.1) ); P.S. This issue boils down to the interfaces. The point is that you should be able to implement interface of any type for the given one. A record of arrays is an interface which has aggregates like above. Hang it on Square_Matrix and you will be able to do above aggregates and other useful stuff, like A.Upper. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de