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,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: Wed, 12 Jan 2005 12:22:39 +0100 Organization: cbb software GmbH Message-ID: <1hp29yovmnm44.1m41vtfjc5k4s$.dlg@40tude.net> References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <16jm4u4b7j5bh.5r4falzh3k6a$.dlg@40tude.net> <9ls4dpw9xkri$.1t4b3d8zglukq.dlg@40tude.net> <2106909.XdsyxhICSC@jellix.jlfencey.com> <2079224.1WssEAdSMv@jellix.jlfencey.com> Reply-To: mailbox@dmitry-kazakov.de Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net +1eLPa8yRFTYQVbEOq+IFgLXAiFfpntZhxp8fdfbMWsDVOo2I= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7685 Date: 2005-01-12T12:22:39+01:00 List-Id: On Tue, 11 Jan 2005 13:57:13 +0000, Vinzent 'Gadget' Hoefler wrote: > Dmitry A. Kazakov wrote: > >> On Tue, 11 Jan 2005 07:24:10 +0000, Vinzent 'Gadget' Hoefler wrote: >> >>> Dmitry A. Kazakov wrote: >>> >>>> I would leave all optimization issues to the compiler. >>> >>> Hmm. Then: What about pragma Volatile? pragma Atomic? >> >> Atomic and volatile are not about optimization. They describe a >> contract. It is wrong to use pragmas for them. Maybe in C++, which >> does not deal with concurrency it would be appropriate, but definitely >> not in Ada. It is clear why these pragmas appeared. > > Atomic and/or Volatile are not necessarily about concurrency. Sometimes > they are just about hardware. ...running parallel to CPU... >> With full ADT an "atomic Integer" will implement abstract protected >> object. No need in any pragmas! > > Hmm. So instead of > >| type Timer_Mode is >| record >| BCD : Count; >| CM : Count_Mode; >| RWM : Read_Write_Mode; >| SC : Counter_Select; >| end record; >| [aspect clauses] >| pragma Atomic (Timer_Mode); > > you'd like to write > >| type Timer_Mode is >| atomic record >| [...] Probably: type Timer_Mode is new Ada.Atomic.Protected_Object with record ... (I don't like new keywords) >>> Or all these interesting ones from Annexes D, E & H? >> >> It depends on each concrete case. > > Remote_Call_Interface? Interrupt_Priority? Attach_Handler? > Inspection_Point? Oh! (:-)) OK, Remote_Call_Interface could be moved to a pseudo-body. Priority could be a parameter of a task constructor or a discriminant (a long story). Attach_Handler should be a representation clause ("for ..."). Inspection_Point is OK to me. --- Pragmas are supposed to be advises to the compiler, not to the program reader. That means, if you remove all pragmas from the program it should still have sense, same sense. This principle is violated too often, most notoriously, by the pragmas appearing in the specifications. I'm afraid pragmas might become a kind of Ada's preprocessor. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de