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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-31 15:51:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news-xfer.cox.net!peer01.cox.net!cox.net!news-hub.cableinet.net!blueyonder!internal-news-hub.cableinet.net!news-binary.blueyonder.co.uk.POSTED!53ab2750!not-for-mail User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Ideas for Ada 200X From: Bill Findlay Newsgroups: comp.lang.ada Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <3ED46E07.4340CABC@0.0> <3ED4F3FD.A0EF7079@alfred-hilscher.de> Mime-version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Date: Sat, 31 May 2003 23:50:00 +0100 NNTP-Posting-Host: 80.195.75.181 X-Complaints-To: abuse@blueyonder.co.uk X-Trace: news-binary.blueyonder.co.uk 1054421464 80.195.75.181 (Sat, 31 May 2003 22:51:04 GMT) NNTP-Posting-Date: Sat, 31 May 2003 22:51:04 GMT Organization: blueyonder (post doesn't reflect views of blueyonder) Xref: archiver1.google.com comp.lang.ada:38249 Date: 2003-05-31T23:50:00+01:00 List-Id: On 31/5/03 20:18, in article bbavc7$ns8@library1.airnews.net, "John R. Strohm" wrote: >> Does Oberon make adding 2, multiplying by 10, etc, equally concise and >> 'unmistakable'? > > Empirically, those operations do not happen nearly as often as the canonical > I = I + 1. See Knuth, "An Empirical Study of FORTRAN Programs", ca. 1970, > and various follow-on papers in the decades since. Agreed. But we are discussing ?:= operators here, not just increment. As I said in another post, "We have a perfectly good syntax for changing a variable, namely assignment. The fewer notations there are for the same thing, the better, surely." > ... If I have to change > > := idem op expr; > > to > > shadow := idem op expr; > := shadow; -- This happens ALL THE TIME in device drivers. > > I'd rather not have to worry about the implications of not doing fetch *AND* > store on the device register. I've gotten burned on this kind of thing > enough times to be wary. You seem to be making major assumptions about the target architecture and about the semantics of "INC()" or "++" On many (if not most) ISPs, the fetch and store would be unavoidable, even for apparently update-in-place operations. On other, regrettably popular, ISPs there might well be no fetch. So what? Constraining a high-level language to get architecture-dependent effects is not the way to go IMO. That's what machine-code inserts are for. (Or, better, abstracted operations that might use either the latter, or language-defined operations, *if* the compiler *happens* to give what you need.) Further, On 31/5/03 22:38, in article bbb7sv$8s2@library2.airnews.net, "John R. Strohm" wrote: > OK, so what are the implications for parsing expressions? I don't see any significant implications for *parsing* as such. 'idem' or equivalent refers to the variable on the LHS of an assignment. It is meaningless elsewhere. > For example: > What does > I := idem + idem; > mean? What it seems to. > How about > > do_some_proc(foo, baz, idem); > > Does "idem" refer back to foo, baz, or do_some_proc? No. > Should we allow, or not allow, > > J := idem; > > Why or why not? What are the semantics? The precise semantics are up for discussion, but hardly seem difficult. I can immediately think of two reasonable definitions. 1. For the assignment: V := f(idem); We set A := V'access; and V and 'idem' in the assignment are replaced by A.all, passim: A.all := f(A.all); 2. We define the anonymous procedure: procedure assign_f_to_V (V : in out T) is begin V := f(V); end; and replace the assignment by the call: assign_f_to_V(V); In each case all reasonable optimizations would be permitted, nay encouraged. I'm sure these first cuts would need to be refined, and I'm sure there are other approaches. > In particular, consider: > > DEVICE_DATA_REGISTER : BYTE; > for DEVICE_DATA_REGISTER use at 16#4000_00F0#; > ... > DEVICE_DATA_REGISTER := 16#40#; > DEVICE_DATA_REGISTER := idem; > DEVICE_DATA_REGISTER := idem + 1; > > How many times should DEVICE_DATA_REGISTER be *read* by the above code > fragment? Why? I note that DEVICE_DATA_REGISTER is not declared volatile. How many times would it be read by: DEVICE_DATA_REGISTER := 16#40#; DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER; DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1; ? The answers 2, 1 and 0 all seem reasonable to me. Why do you think the language *should* define this? -- Bill-Findlay chez blue-yonder.co.uk ("-" => "")