Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ucbcad!ucbvax!unisoft!jef From: jef@unisoft.uucp (Jef Poskanzer) Newsgroups: comp.lang.misc Subject: Re: H.O.Functions + Polymorphism Message-ID: <441@unisoft.UUCP> Date: Wed, 8-Jul-87 13:59:53 EDT Article-I.D.: unisoft.441 Posted: Wed Jul 8 13:59:53 1987 Date-Received: Sat, 11-Jul-87 18:37:58 EDT References: <1345@ogcvax.UUCP> Sender: news@unisoft.UUCP Reply-To: jef@unisoft.UUCP (Jef Poskanzer) Distribution: world Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Lines: 43 In the referenced article, pase@ogcvax.UUCP (Douglas M. Pase) wrote: >In articlegudeman@arizona.edu (David Gudeman) writes: >>Any language with functions can have higher order functions, and any >>language with the concept of `arguments' can have lazy evaluation of >>them. So how can these features be called advantages of functional >>programming? > >Well, imperative languages do not support these features... > >'C' is one of the more flexible imperative languages.... >...one is not able to directly bind arguments to a function and thereby >create a new function: > let p1 = plus 1; >This view of functions is thoroughly incompatible with that of any imperative >language. int p1(x) int x; { return x + 1; } Or if you want to be polymorphic: #define p1(x) ((x) + 1) >...lazy evaluation is not supportable in >imperative languages as it is an 'evaluate on demand' strategy for function >parameter evaluation. All imperative languages evaluate the arguments to >functions before the function is invoked. Algol 60 had call-by-name over twenty years ago. It wasn't useful then either. The point about generic functions is valid, and many recent imperative languages support them. --- Jef Jef Poskanzer unisoft!jef@ucbvax.Berkeley.Edu ...ucbvax!unisoft!jef "I SAID I LOVE ALL MANKIND *DAMMIT*!!"