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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d303864ae4c70ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-15 03:37:49 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-045-071.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Reprise: 'in out' parameters for functions Date: Thu, 15 Apr 2004 12:37:33 +0200 Organization: At home Message-ID: References: <5ad0dd8a.0404091828.6e79bb4e@posting.google.com> <5ad0dd8a.0404100735.7b2a8317@posting.google.com> <5ad0dd8a.0404130130.66d5e721@posting.google.com> <5ad0dd8a.0404131441.20b8a942@posting.google.com> <5ad0dd8a.0404140703.49e1e2f2@posting.google.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-045-071.arcor-ip.net (145.254.45.71) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1082025468 3271310 I 145.254.45.71 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:7124 Date: 2004-04-15T12:37:33+02:00 List-Id: Wojtek Narczynski wrote: >> I did not disagree with your definition. I did with your statement that >> Ada's protected objects are wrong way. They might have problems, though. >> But it appeared, as you treating them as completely wrong. > > "Wrong" seems to be one of your favourite words. I merely said that > Ada concurrency features are not expressive enough not to require > abstraction inversion in many cases. Sorry, but I still do not get your point. Either Ada features are 1) beyond any help; 2) OK, but has to be impoved in some definite way; 3) Excellent. It seems that you do not agree with (3). So either (1) or (2) remain. Which one? >>> Checking physical units statically would be helpful for high > integrity >>> software. I don't see any practical use for runtime unit checks. > >> Only because I see no smiley... How would you implement: >> >> procedure Put (Stream : File, Value : Measurement); >> procedure Get (Stream : File, Value : out Measurement); >> >> For example, a requirement of one of our customer was to have a button in >> his MMI to switch between European and American units in all visual >> elements and printouts. Now go, figure out, how would you solve that >> using templates. > > Huhm, we are talking about _checks_, then we are suddenly talking > about _conversions_. I gave you an example of a *real* application requiring units (and units checks, because surely in any place where the system expects, say, a velocity, the operator may give it in any compatible unit: knot, km/h, m/s, mph, whatsoever, but not in kPa. So units are indeed checked.) > But even for conversions, even though they are > most certainly useful in many cases at runtime, the idea to hardcode > the external representation of values with units into the compiler and > runtime, is unfortunate. I do not follow you here. My example shows that static *only* checks are insufficient. Period. This does not imply that it is impossible to create a unit system which would be statically checkable. I already mentioned in my previous post that Ada designers managed to do a similar job with the type String. Carefully observe how Ada deals with statically constrained String subtypes. In my view it is quite possible to deal this way with dimensioned values too. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de