Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mimsy!oddjob!hao!noao!arizona!gudeman From: gudeman@arizona.edu (David Gudeman) Newsgroups: comp.lang.misc Subject: Re: H.O.Functions + Polymorphism Message-ID: <1817@megaron.arizona.edu> Date: Fri, 17-Jul-87 14:08:21 EDT Article-I.D.: megaron.1817 Posted: Fri Jul 17 14:08:21 1987 Date-Received: Sat, 18-Jul-87 18:38:28 EDT References: <...> <2637@crcge1.UUCP> <1345@ogcvax.UUCP> Distribution: world Organization: U of Arizona CS Dept, Tucson Lines: 82 In-reply-to: pase@ogcvax.UUCP's message of 8 Jul 87 04:43:44 GMT In article <1345@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: In article gudeman@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? I left for a week right after I posted this, that's my reply is late... Well, imperative languages do not support these features, ... Scheme and SL5 are two imperative languages that support higher order functions, SL5 and Algol are two imperative languages that support lazy evalution of arguments. BTW, it may be that you want to call Scheme a functional language. You can if you want, but it is also an imperative language in that it has assignment and control flow. Because imperative languages are modeled somewhat after the machines they run on, having storage locations, addresses and state, such concepts are really incompatible with them. ... Storage locations, addresses, and state are not unique to RAM machines, and their appearence in a programming language does not show that the language is modeled at all on the machine it runs on. Neither Scheme nor SL5 is modeled on modern computer architectures. 'C' is one of the more flexible imperative languages. Why do people always think of C, Algol, Pascal, and Fortran when they say imperative language? These are all hardly more than structured assemblers compared to the really powerful ones like Lisp, Icon, SNOBOL4, APL, Scheme, SL5 and dozens more. ... directly bind arguments to a function and thereby create a new function ...... This view of functions is thoroughly incompatible with that of any imperative language. This view of functions is thoroughly compatible with that of a number of imperative languages. Maybe the disagreement is a result of your definition of imperative languages. If you define imperative languages as the class of structured assemblers, I see how you might think there is an incompatibility. But even so, there isn't any incompatibility. It would be trivial to design C-with-currying, and not too difficult to implement it. ...... A lot of imperative languages have polymorphic types also. I do not yet see the advantages to lazy evaluation except in a few cases which are academically interesting but of little practical use (all of which involve an exact representation of an infinite sequence, such as the digits of an irrational number). Lazy evaluation makes it possible to write functions/procedures that work on a wider range of input. For example, function lazy-multiply(x,y) if x = 0 then return 0 else return x * y end cannot be written with strict evaluation. However, 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. Again, there are several counter examples to this claim that I've already named. David Gudeman Department of Computer Science gudeman@arizona.edu Gould-Simpson Science Building {allegra,cmcl2,ihnp4,noao}!arizona!gudeman The University of Arizona 602-621-2858 Tucson, AZ 85721