Functional Programming versus ToolCraft

[Dennis E. Hamilton]

OK,

By descriptive schemes, I did mean Prolog and what happens in Haskell
(basically, facts get cached so that they are available for consultation in
new questions).

I want to point out a difference between local and global issues here, and
then get to a more interesting thing (and then maybe give up this thread
altogether).

As far as I am concerned, use of imperative operations in the implementation
of a function can lead to a functional result so long as the operation of
the function never shows a side-effect.   That is, if you can't tell that I
did imperatives, treating the function implementation as a black box, I have
done my job.  In particular, if there is no impact on the global state of
the computation, as opposed to the local state of the function
implementation, I am not so picky.

Yes, assignment operations are inherently "side-effects."  What is
interesting for me is that practically every engine that implements
functional systems employs imperative mechanisms internally, and in fact,
this is a source of the effectiveness of the functional implementation.  The
difference for scheme is that it only makes that accelerator capability
available to users of the engine via idiomatic trickery.  Fine.

	-	-	-	-	-	-	-	-	-

What is interesting to me is that in the use of different programming
systems, people learn things about the underlying mechanism (whether
accurate or the programming equivalent of urban folklore) and develop a
model (possibly inaccurate) that guides how programs are expressed.  It is
not accounted for in the straightforward semantics of the language as it
might be defined abstractly, but it is a response to the actual behavior of
the tool.  I call this collapse and modeling "toolcraft."  For example, it
is toolcraft to expect the kinds of failure trace-back that the Python
engine provides and then be familiar with it as how things should be.  It is
an interesting human adaptation mechanism.

So, conniving tail-recursive forms of function definitions is part of the
toolcraft around the use of scheme.  I notice, as can anyone who runs my
fibt(n) versus fibn(n) examples, that there is a benefit to that in Python
as well as in scheme, and you can write a purely functional program with
good performance (but it is expected to take space of order O(n), not O(1),
though the engine *might* have an accelerator that improves that).  Now
there are all of these idioms for getting computations to be O(const) in
space in Scheme.   The idiom in python is to use safe imperatives and
iterations (i.e., with no side-effects arising against the *use* of the
function, rather than relying on the fact that the implementation will do
that last step for me (not so well, lacking the global knowledge of the
problem that I have).

If someone put that accelerator into the standard python implementation,
after a while, there would be a lot of idiomatic expressions that connived
to take advantage of the accelerator in the implementation.  (The error
trace-back mechanism would also have to be improved and people would adapt
to that, too.)

It is fascinating for me how our relationship to tools isn't a relationship
to the semantics and purity of it but to the pragmatics of the underlying
implementation.  No surprise, actually.  Yet we don't seem to be very aware
of doing that, and that makes this almost an anthropological discussion
rather than anything about language systems!  It makes the debates about
good/right things pretty amusing, though.

I find toolcraft to be a fascinating topic. For one thing, awareness that we
have lots of it is a good practice when we have problems communicating yet
we appear to be talking about the same things.  (I recently started looking
at this because of the dramatic differences in toolcraft I saw among
open-source practitioners and Win32 developers.)

I think being aware of the foundation for idioms that arise in conjunction
with different tools, and that toolcraft idioms are inescapable, is an
important aspect of teaching, experience, and design for programming
systems.

-- Dennis

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Tim Peters
Sent: Tuesday, February 29, 2000 00:39
To: python-list at python.org
Subject: RE: functional programming & tail recursion?

> I don't think one should begrudge an iterative implementation (which is
> pretty immediate) as non-functional!

"functional" implies (among other things) "no side effects".

    i = i+1

is not a functional program.  Saying that iteration is not functional is a
matter of defn, not of moral judgment.

albeit-on-real-hw-nothing-is-functional-under-the-covers-ly y'rs  - tim



--
http://www.python.org/mailman/listinfo/python-list