curry and compose -- functional language constructs

[Marcin 'Qrczak' Kowalczyk]

Wed, 2 May 2001 09:36:09 +0200, Alex Martelli <aleaxit at yahoo.com> pisze:

> "From the outside" (the "client-code" side), a callable class-instance
> mostly differs from a typical functional-programming function object in
> that its state is modifiable.  You CAN use sort-of-FP (e.g. in Scheme)
> where "closures" modify their own state, but the "mainstream" of FP
> relies on non modifiable objects.  All in all, I agree the difference
> is not huge!

Although the functional style emphasizes how work can be done without
an implicit state, imperative style is embedded in functional programs -
and in this case is is natural to pass imperative actions as first-class
values.

Two key ingredients of the functional style (IMHO), lack of implicit
state (immutability) and function objects, are technically quite
independent. When the first principle is not used and a state is
present, stateful function objects are still natural (although some
languages don't call them functions in this case).

(It's perhaps not a coincidence that they come together. Without state
the order of evaluation doesn't matter, so higher order functions
which hide evaluation order of user-supplied functions can be more
freely used.)

When an imperative action is a first-class value, such that treating
it as an expression doesn't execute it yet, functions taking
such actions as arguments are naturally used instead of special
control constructs in other languages: starting threads, catching
exceptions, try:finally:, entering critical sections, dispatching
actions using a dictionary of options, ensuring availability of an
external resource during some work, blocking asynchronous exceptions,
timeouts, imperative iteration over data, attaching finalizers...

BTW, there is a difference between treatment of imperative actions
in functional languages and command/query separation of Eiffel or
Python's statements: an imperative action in a functional language
almost always produces an answer. In case it's not needed, it's trivial
(if the language requires it to be exactly one object). But in case
it is needed, it would be silly to introduce a stateful place to
put it and then retrieve it in another piece of code. This is what
Eiffel does and I don't understand reasons of doing so. It's natural
for me to distinguish destructive commands and idempotent queries,
but not to always separate an operation into these parts.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK