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.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site noscvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!sdcsvax!noscvax!broman From: broman@noscvax.UUCP (Vincent P. Broman) Newsgroups: net.lang.ada Subject: Re: ForTran-Ada + flamette + question Message-ID: <503@noscvax.UUCP> Date: Fri, 30-May-86 12:28:43 EDT Article-I.D.: noscvax.503 Posted: Fri May 30 12:28:43 1986 Date-Received: Sun, 1-Jun-86 08:21:41 EDT References: <4700037@ada-uts> Organization: Naval Ocean Systems Center, San Diego Summary: ada 'eval' suffices not. List-Id: <> richw@ada-uts justifies the lack of procedure pointers in ada by asserting that they can be simulated satisfactorily with an 'eval' procedure, that dispatches on a parameter of an enumerated type by invoking the procedure that is logically associated with the parameter's value. This is insufficient. The canonical example is a numerical quadrature package which integrates user-supplied functions. The problem is that the dispatcher that repeatedly invokes the integrand must know the NAMES of all potential integrands in order to invoke them. These names are known only at user-compile-time, not library-compile-time. The quadrature routine should not see integrand names, it should only specify the parameter and result types of the eventual integrands. A generic quadrature package mispleases because separate copies of it must be instantiated for each function to be integrated. I have used function/procedure pointers in Algol-family languages fairly often. A big attraction (to me :-) of Scheme and its cousins is the power afforded by making procedures first-class objects. If language size is the real concern here, I would gladly give up in return such dubious features of ada as: default values of parameters, the raise statement, assignments to objects of unconstrained size, etc. Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 225 2365 {seismo,caip,ihnp4,ucbvax}!\\\\\\\ Arpa: broman@bugs.nosc.mil Uucp: {floyd,moss,bang,hp-sdd,sdcsvax}!noscvax!broman