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,92d1af21ade61406 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-10 09:15:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!core106-s128.dialo.tiscali.DE!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Problems with 'class, help anyone? Date: Sun, 10 Nov 2002 18:13:12 +0100 Organization: At home Message-ID: References: <3DBE2593.9080800@worldnet.att.net> <3DBF9437.8090408@worldnet.att.net> <3DC74F23.80308@worldnet.att.net> <3DC91DBB.C85F27E@brighton.ac.uk> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: core106-s128.dialo.tiscali.de (62.246.106.128) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1036948538 11563944 62.246.106.128 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:30686 Date: 2002-11-10T18:13:12+01:00 List-Id: Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> 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? Both and more. Any computer objects at best only simulate mathematical ones. They never *are* mathematical objects. > I can assure you that if the ARG changed the syntax in this way, > they would be tarred and feathered (or at least ignored)! ;-) Alas >> 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). OK > 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. So let's allow timed and conditional entry calls for all kinds of subroutines! Let's allow results for entries. >> 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. OO-people would not give it away. They like to write comical things like "x.sin". It is almost as sacral as only-in-parameters-for-functions (:-)) If we want to abolish postfix notation, then we should consequently allow protected operations on multiple objects and entries of multiple tasks. [and multiple dispatch, of course] >> iii. functional A(x,y) >> iv. aggregated (x,y,z) (should Ada have user-defined ones?) > > I don't know about Ada, Surely it is not about C++#* (:-)) > 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. Yes > 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. Agreed. The problem of Ada is not in lexical rules, they are almost perfect in my view. The problem is that ADT implementation is far incomplete in Ada. One cannot create a record and expose it as an array. One cannot define a constructor for every new type. One cannot have discriminants for every type. One cannot override implementation of a type while deriving from it, etc. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de