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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Comments requested for a couple of Ada-Comments submissions Date: Fri, 11 Jul 2014 20:02:08 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Fri, 11 Jul 2014 20:02:08 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="31755"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+dtIAIjNKRXne6cZV63G+pFHWp2j9UX1o=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:tyHi8acpS4fzi8rN346160PNUgo= Xref: news.eternal-september.org comp.lang.ada:20882 Date: 2014-07-11T20:02:08+00:00 List-Id: On 2014-07-11, Niklas Holsti wrote: > On 14-07-11 07:16 , Randy Brukardt wrote: >> "Jeffrey Carter" wrote in message >> news:lpnb74$kmi$1@dont-email.me... >> ... >>> I don't see that there is anything here that the ARG would want to take >>> action on, especially given that Randy said they're only interested in >>> things that are hard or impossible to do in Ada. This is clearly not hard >>> or impossible. >> >> Well, actually, I understand that a similar problem came up recently (I >> think it was related to SPARK) and that the GNAT people had already hacked >> an ugly solution to it. A language-based solution would be better, at least >> if it's not too expensive to implement. >> >> After all, two independent problems that can be solved with a relatively >> simple new feature make that feature more compelling. In any case, it's >> certainly OK for Simon to submit the problem; I've seen a lot sillier ideas >> than this one. >> >> Randy. > > Thanks, Simon, for working up this proposal. > You are welcome. > I think that this proposal should not be limited to solving the "update > of atomic" problem. The ability to write an aggregate that generates a > composite value by giving new values for just some of the components of > an existing composite value is quite useful in any context where a > composite value is used. > That is a very good point. I will add wording that makes it clear the exact same syntax could be used for general updating of, say, records in general. It does raise another point, however. So far, I have only thought about non-discriminated records due to my focus on device registers. Are there any additional issues when discriminated records are involved ? It's only occurred to me just now while typing up this response, but I can't see how it could possibly make a difference, even with variant records. However, I just thought I would ask the question anyway. :-) > > Furthermore, the proposal should IMO not be limited to record types. The > same should be possible for array aggregates, as in this example: > > type Month_Days is array (Month) of Positive; > > Normal_Year_Days : constant Month_Days := > (Jan => 31, Feb => 28, Mar => 31, ..., Dec => 31); > > Leap_Year_Days : constant Month_Days := > (Normal_Year_Days changing Feb => 29); > I can see what you are saying here. Let me have a think about it. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world