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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.software-eng:3032 comp.lang.ada:3377 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!billwolf%hazel.cs.clemson.edu From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) Newsgroups: comp.software-eng,comp.lang.ada Subject: Re: Ada language Message-ID: <8219@hubcap.clemson.edu> Date: 3 Mar 90 05:09:55 GMT References: Sender: news@hubcap.clemson.edu Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu List-Id: >From peter@ficc.uu.net (Peter da Silva): > Would you care to address the confusing and dangerous deficiencies in > the ADA language: operator overloading and the use of rendezvous for > interprocess communication, for example? The implementation of the operator to be used is completely determined by the type(s) of the parameters involved and by the visibility rules. Where do you see problems? It seems to me that operator overloading takes advantage of the human ability to process context rather extensively (which is also exploited in the "natural" languages such as English), and I have not found it to be either confusing or dangerous. The main problem with the rendezvous is "priority inversion", which will be taken care of in Ada 9X. Feel free to describe any other problems you might wish to point out; I know of nothing inherently confusing or dangerous about the Ada rendezvous. Bill Wolfe, wtwolfe@hubcap.clemson.edu