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 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?
>
>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*!!"