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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public From: "James Giles" Subject: Re: F9X twister & ADA (was: n-dim'l vectors) Date: 2000/04/11 Message-ID: #1/1 X-Deja-AN: 609398111 References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov> <38ED4ECA.ADB698C9@sdynamix.com> <38F28A85.53809F39@sdynamix.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 955424713 12.74.2.51 (Tue, 11 Apr 2000 03:45:13 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Tue, 11 Apr 2000 03:45:13 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-11T00:00:00+00:00 List-Id: bv wrote in message <38F28A85.53809F39@sdynamix.com>... >Surely, you're joking Mr."Feinman"? [...] You can't even competently get Feynman's name right? And you still insist that your program that normalizes a vector is a substitute for one that sums two of them (that's what the example you responded to actually did)? And you expect to be taken seriously? > ... Anyhow, in case the counter example in ADA baffled you >here's how the same fcn might look in the F9X that could have been: > > vector function normalize(v) > external vector > vector u,v > real norm > > vni = 1/norm(v) > do i=1,len(v) > u(i) = v(i)*vni > enddo > return u > end > >** somewhere in your code (sans interfaces & modules) > vector u,v, normalize > . > . > . > u = normalize(v) Looks awful. Aside from the fact that it's 'outdented' (as opposed to indented), there should be no loop. Whole array syntax is preferable. Though I prefer (like some others) the form u(:) = v(:)*vni rather than use the variables subscriptless. Unfortunately, this form may be less efficient on some implementations. If NORM is known to be a function, its type should also be known (otherwise you should have an interface), so the REAL declaration should either be unnecessary or extended. You've introduced a local variable name to take the place of the function name - for no reason I can discern. Accumulating the result in the function name is perfectly clear. I agree that typenames should be usable directly in declarations (rather than as modifiers to the TYPE keyword). This anomaly exists because they decided to allow the :: (double colon) syntax on all declarations, not just type declarations. If it were required on declarations of objects of a derived type and were prohibited on non-type attribute specification statements, then you'd know that any statement containing a :: *must* begin with a typename. So, you'd not need the TYPE keyword there. (Oh well.) I don't know why EXTERNAL is in any way to be considered superior to USE where the type is defined. With the USE form, you also get any additional functionality (like the operator overloads appropriate to the type). And so on.... >Too bad for the missed chance when so much could have been done with but >a little extra tasking on the solitary assignments of the "return" and >"external". It's very BAD language design to use the same keywords for several distinct language features. And, there's no need in this case not to use the Fortran features exactly as they are. The only place where the above form of RETURN would be superior would be to eliminate the need for the RESULT variable on array valued recursive functions. This example doesn't contain such a function. And USE is not less legible than your misuse of EXTERNAL. (Assuming your proposed meaning was that the external statement would import all the relevant definitions of the type 'vector', like overloaded operator definitions and such, then the two forms are about the same. Presumably NORM would be among the primitives defined for the type - so the REAL statement is really redundant even in your version.) There are a *LOT* of things that the committee could have done better in their design of Fortran 90. You've identified only one of them (the TYPE keyword). Your other complaints are misplaced or just wrong. Yes, it's too bad the committee missed the chance to do those other things.... Not that Ada is inherently superior. They did a lot of things badly too (their exception handling, for example). -- J. Giles