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,92d1af21ade61406 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-09 11:03:51 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uunet!sea.uu.net!sac.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Problems with 'class, help anyone? User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Sat, 9 Nov 2002 19:02:53 GMT Content-Type: text/plain; charset=us-ascii References: <3DBE2593.9080800@worldnet.att.net> <3DBF9437.8090408@worldnet.att.net> <3DC74F23.80308@worldnet.att.net> <3DC91DBB.C85F27E@brighton.ac.uk> "Dmitry A. Kazakov" writes: > Robert A Duff wrote: > > > "Dmitry A. Kazakov" writes: > > > >> That's right, but there is a case where "function" really differs from > >> "procedure". I mean protected objects. ... > > > > That's *another* example of basing things on a kludge. > > Certainly, it makes sense to distinguish read-only from read-write > > locking. But to base that on "function" vs "procedure" is ... > > well, Yuck. > > Absolutely > > > Protected functions are *not* functions (in the maths sense), > > and therefore should not be so called. > > Well, strictly speaking "+" is also not the mathematical +. Who cares. You mean because it can overflow? And because (for floats), it can give a "close-but-wrong" answer? Or do you mean, because the user can redefine it to do something else, including having side effects? >... But I > agree that protected function is not the best name for the thing. > > >>... "function" vs. "procedure" for a > >> protected object could potentially mean different implementation and > >> performance. So I think that one should leave "function"s as they are, > >> and just allow procedures with results: > >> > >> procedure Foo (...) return Bar; > > > > Yeah, and then eliminate the "function Foo..." syntax. > > That would solve the problem! > > > > Slight incompatibility... ;-) > > I am not afraid of! (:-)) I can assure you that if the ARG changed the syntax in this way, they would be tarred and feathered (or at least ignored)! ;-) > But we still need some keywords for: > > 1. Subroutine (=procedure) > 2. Subroutine with no side-effects other than on the arguments (=?) > 3. Subroutine with only one side-effect on the result (=?) I think 2 and 3 should use the same syntax on the declaration. To me, it's a minor point whether a subroutine returns results via a "function result" vs out parameter(s). I would advocate a notation at the call site that indicates out-parameterness. > "function" in Ada is sort of 1. dressed as 3. (:-() > > {1,2,3} is multiplied to: > > A. Subroutine with no queue > B. Subroutine with a queue (entry) I am not convinced that these need a syntactic distinction. > Well together it makes 3x2=6 different variants! > > And not to forget the "notation" axis: > > i. operational x+y > ii. prefix (subroutines of protected objects, tasks, attributes) I don't much like the prefix notation. > iii. functional A(x,y) > iv. aggregated (x,y,z) (should Ada have user-defined ones?) I don't know about Ada, but if I were designing a language from scratch, I think I would include user-defined aggregates. Also, user-defined semantics for various other notations, like literals, "in", indexing, and maybe a few others. I would not go so far as Lisp, where you can redefine the meaning of 'if' statements, and you can even redefine the lexical rules of the language. - Bob