Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!visix!ip2020!adamksh
From: adam@visix.com
Newsgroups: comp.lang.forth
Subject: Re: Functional (Applicative) Programming
Message-ID: <1991Mar22.183537.24201@visix.com>
Date: 22 Mar 91 18:35:37 GMT
References: <9103210409.AA14380@ucbvax.Berkeley.EDU>
Sender: news@visix.com
Reply-To: adam@visix.com
Organization: Visix Software Inc., Reston, VA
Lines: 99

In article <9103210409.AA14380@ucbvax.Berkeley.EDU>,
UNBCIC@BRFAPESP.BITNET writes:

> I did understand you. You are, basically, right. I just wanted to point out
> some information...

I am glad that you have said this.  I don't like to be picky, but I do
want to say that it was kind of confusing to start your previous message
with "hehehe, I'll show you that you are wrong".

> ...The style that you suggest is the functional paradigm (or applicative
> paradigm).

I will refute this statement below.

>  I don't know what kind of LISP programs you have seen, but this is
> the base of LISP.

Again, I am uncertain how to take this statement.  If you mean to
imply a question about my LISP experience, then I will mention that my
first programming course was Structure and Interpretation of Computer
Programs by Abelson and Sussman at MIT.  But it would not make sense
for you to imply this question, since it is irrelevant to the
discussion at hand.

> (about Dijkstra's suggested commands)
> Things like: do X to all elements of Y; With X # Y (X it's a operator like +,
> for example) return (first element of Y) X (X # (rest of Y)) -- this reduce a
> vector to a element through one operator. In other words, operators to
improve
> functional programming.

These are the examples I suggested.  However, the fact that these
examples arose in the context of functional programming does not mean
that they ARE functional programming.

If you claim that these examples ARE "the functional paradigm", then
you cannot make the statement that these are "operators to improve
functional programming."  You must instead claim that these are
operators necessary for the implementation of functional programming.

This distinction may seem to be picking nits, but I must separate the
examples from the paradigm in order to show that we can use the
examples without using the paradigm, namely that the statement below:

> The whole problem is that functional
> programming is not well adapted to our computers.

is irrelevant to my suggestion.

We refute the statement, "the style I suggest is the functional
paradigm" in two ways.

I. We show that the functional paradigm does not imply the style I suggest.

The following Scheme function:

(define (factorial n)
  (if (= n 1)
      1
      (* n (factorial (- n 1)))))

is functional, since it does not make any assignments.  However, it is
not written in the style I suggest.  That would look like:

(define (factorial n)
  (accumulate * 1 (enumerate-interval 1 n)))

II. We show that the style I suggest does not imply the functional paradigm.

The following Scheme code:

(define 'marys-account 100)
(define 'jims-account 200)
(define 'toms-account .25)

(define bank-accounts '(marys-account jims-account toms-account))

(define (add-interest bank-accounts)
  (mapcar (lambda (x) (set! x (* x 1.05)))
          bank-accounts))

is written in the style I suggest, but it is not functional, because
it has side-effects and its behavior depends on state.

Part II is important because it means we can program without explicit
control structures in a language like Forth without first making Forth
a functional language.  I am also planning on using this style in C.

> IF is necessary. But you can try guarded commands....
> GUARDED-BEGIN <cond> : <action>
>               <cond> : <action>
>                ...       ...
> GUARDED-END

This is an interesting example, but I hope you understand that it is
not actually in the style I suggest, and so I will not be pursuing it.

Adam