[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 21 22:27:45 1998 
Subject:Complexity 
From: Robin Popplestone  
Volume-ID:980121.02 

Nick Kallen writes.

> I do believe this is the case. Among other things, math is the science of
> precise human logic dealing with quanitative and qualitative aspects of
> entities. Programming languages are languages to precisely describe
> quantitative and qualitative aspects of entities.

The mathematician's concept of what is precise and the programming language
designer's (or "designer") concept of what is precise are different for
most programming languages. They are the SAME for those languages at the
functional end of the spectrum. This, and not language-features, is the
REAL difference between functional languages and the rest - bolting on
features doesn't make a language functional. So Nick Kallen is missing the
mathematical point when he writes:

>  A C++++ with parametric polymorphism (w/ type classes),
> algebraic types, and pattern matching could also *always* produce code
> that was shorter than C++.

A designer  of a  functional programming  language, if  he wants  to  add a
feature, has to prove  that that feature  won't interact disastrously  with
other features, most typically by specifying a translation into the  Lambda
Calculus. If  a programming  language  has n-features  then the  number  of
possible interactions  between  features is  at  least n^2  (leaving  aside
ternary interactions). Consequently  proving anything  useful (for  example
that it is type-safe)  about the language is  likely to require looking  at
n^2 cases,  unless the  language  is carefully  designed, which  C++,  say,
isn't.

Even if we take the Lambda  Calculus, the basic definition of  substitution
has SEVEN cases. So,  until you've built up  a decent repetoire of  lemmas,
every proposition you prove  about substitution requires  you to treat  all
seven cases, often with a couple  of sub-cases. And that's about as  simple
as you  can get  (unless you  use Shonfinkel's  combinators). Even  a  fine
mathematician like Curry got some of the details of alpha-reduction  proofs
wrong,  according  to  Hindley.  [Hindley  and  Seldon,  "Introduction   to
Combinators and the Lambda Calculus", Cambridge UP 1986].

Likewise, the basic  Church-Rosser properties  of the  Lambda Calculus  are
sensitive   to   the   reduction-rules   in   use,   which   is   why   the
functional-language  people  are  sold  on  laziness,  since   normal-order
reduction (corresponding to lazy evaluation) is the standard way to be sure
a of computation  terminating in a  normal form if  one exists. [This  fact
incidentally must have been known to the Algol 60 designers, since they put
call-by-name into the language...]

Moreover, if you want to use the Lambda Calculus as a logic (as HOL does,
for example) you need a typed version, since logics built on the untyped
version are inconsistent (Curry's paradox).

So, analysing programs with mathematical precision is quite hard work, and
requires considerable application of Occam's Razor...

Robin.