[Gridflow-dev] ping (fwd)

[Mathieu Bouchard]

On Fri, 17 Sep 2004, Tom Schouten wrote:
> On Thu, Sep 16, 2004 at 11:25:08PM -0400, Mathieu Bouchard wrote:
> > On Thu, 16 Sep 2004, Tom Schouten wrote:
> > Mutability has nothing to do with it all.
> i wouldn't be too sure about that.
> i'm not big with definitions and all, but i think the concept of
> closure is only well-defined in a functional programming environment.

heh. Closures have been used in a mutable context for very, very
long. e.g. Smalltalk's [], Self's (||), Perl's sub{}, Ruby's proc{}, and
after all, Lisp's (lambda())

> and as far as i understand the origin of lisp, lisp (stripped of
> all mutators) is actually meant to be a replacement for the concept 
> of 'turing machine'.

No, LISP was meant as a kind of generic experimental language-handling
toolkit. The most important feature of LISP may be its interpretive
nature, and it's the language that the EVAL keyword comes from, but also
it's the first language to clearly separate syntax and semantics, as EVAL
doesn't parse anything, and parsing is the job of READ, and what you've
got in the middle is an AST (a tree-shaped bytecode) that is considered as
ordinary data within that language.

LISP is also, incidentally, where implementation of functional
programming began, given the rather large connection with Alonzo Church's
Lambda language, but it's not like the author(s) of LISP really believed
in pure-functional semantics because the techniques for evaluating them
were rather inefficient. So right from the beginning a number of
mutabilities were implemented in LISP, and it only got more of them. By
the 80's, LISP had mutable multidimensional arrays, mutable dictionaries,
mutable closures, mutable objects/classes, and so on.

What happened with the Turing machines is that, a few years before Turing
did his work (1940's) Church invented the Lambda language
("calculus") (1937?) and that became a key element of Turing's thesis on 
the equivalence of completely different computers. (Since then, many other
completely different systems have be shown to be "Turing-equivalent",
including the game-of-life)

> lisp is an evaluator, and talks about evaluation as its basic
> action.

You mean "lambda is an evaluator...". If you want a practical language
that most closely follows lambda, and is extremely unlikely to stray away
from immutability, pick Haskell. But that's 90's research. And you've got
to swallow the strong-typed semantics as well. Else you can also go in a
compsci department and take a course in compilers and chances are that
half of the homework assignments will sound like "make a translator from
lambda to..."

In practice you will find that LISP is much more used than Haskell because
LISP has internalised a bunch of pragmatics and has more of a
"multiparadigmatic" nature from the start, while Haskell is merely the
most pragmatic case in the bunch of languages designed to make a point in
the articulation of a doctorate thesis in pure-functional evaluation, or
somesuch... Last year I've been told by a fan of Haskell that you still
can't do read/write in a dictionary in O(1) average time. That's unheard
of in any language I use.

> these 2 views are fundamentally different, which is i think
> the base of the difference between the two. the rest is just
> extensions to the ideas of state+mutation vs evaluation.

In the future, please don't associate immutable semantics with LISP as
strongly as that. Although LISP was the first case of implementation of
such semantics in a real computer, LISP has a very much hybrid
("multiparadigmatic") nature. Just look at the standard libraries of
CommonLISP. They include a logic language not unlike PROLOG except it
integrates with the rest of LISP. There are also dataflow extensions, and
(mutable) OOP extensions (CLOS, which is what most people mean when
talking of OO-LISP).

Besides, even though LISP's LAMBDA keyword was named in reference to the
closure operator of the Lambda calculus, LISP's closures always has had
mutable semantics.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju