newbie conceptual question [from haskell list]

[D. Tweed]

I'd like to respectfully disagree with some of this :-)

On Wed, 25 Jul 2001, Frank Atanassow wrote:

> These things are nice, but the more I learn about functional languages, the
> more I feel that they are only icing on the cake. The most important thing
> about functional languages is that we know _what they are_, and that they
> can be characterized in a regular fashion which is amenable to analysis; in
> other words, we know how to reason about them, and what sorts of properties
> functional programs satisfy.

Umm, I wouldn't agree with that exactly. If you ignore stupidities like
specifying the mod operator % to be implementation defined, I would claim
that C has/can be given semantics which are virtually as simple as
Haskell. Equally I'd argue that we know as much about how to reason about
imperative languages as we do functional ones. The point is that those
semantics don't split the problem of reasoning about what's going on into
nice independent subproblems like the semantics of Haskell do. Equally,
I'd agree we don't know how to perform _effective_ reasoning on them,
probably because it's pretty much impossible without restricting the set
of allowable programs.

> Saying that a language "satisfies nice properties" sounds abstract and
> useless to some people who just want to get things done, but I really
> believe that it helps not only researchers who know know how to read and use
> formal semantics, but also everyday programmers, because they absorb some of
> these reasoning methods and then start using them intuitively and
> unconsciously. For example, every Haskell programmer has some grasp of
> referential transparency, and uses it implicitly every time he thinks about
> how to structure or rearrange his programs.

Again, as a C++ programmer I have some grasp of what program
rearrangements are valid (E.g.,I can't move an assignment involving an
expression in another variable, say v, from before an assignment to v to
after an assignment to v), and I use it implicitly every time I think
about structuring or rearranging my programs. The problem is that that
doesn't really help because determining whether there's an assignment to
variable v between where an assignment is now and where I want to move it
to is `decidedly non-trivial'.

What I'm basically trying to say is that I don't think it's `simplicity of
semantics' that's the FP advantage but the _effectiveness in the world of
people writing programs_ of those semantics. (Indeed I vaguely remember
reading that John McCarthy didn't develop LISP as a computational
realization of the existing theory of lambda calculus but rather because
he thought programming with only functions would be an effective way of
doing things. The `lambda' was an accident; a friend gave him a book on
Church's theory late in the development and he admitted he didn't really
understand it but thought the name lambda for the function definition
construct was `cool'.) And that advantage comes partly by restricting
yourself to programs that allow this kind of reasoning; this is no
different from the fact that I won't drive after having drunk any alcohol
even though I might well in actuallity still be safe because it's easier
to follow that rule than to figure out if I'm genuinely safe.

> Of course, this argument holds for any "simple" language, not just
> functional ones, where by "simple" I mean "easy to reason about". For

As I say `easy to _effectively_ reason about' =/= simple semantics.
I'm making this point because the natural rejoinder from a C programmer
being told that C (as an imperative language) has more complex semantics
than Haskell is to say `no it doesn't', which I agree with, the point
being that Haskell has a semantics which makes it easier to reason about
effectively. (I'm glossing over the distinction between the various
kinds of semantics for a language such as denotational and operational
here.)

> example, there are concurrent calculi of processes, object calculi and
> first-order algebraic languages which also share this property, and I prefer
> any of them to warty conventional languages. (And this is why I also like
> SML: even though it's not referentially transparent like Haskell, I know
> what sorts of properties it satisfies.)

Now this to me is a really interesting statement. IIRC from many years ago
theres not necessarily an indication in the type system when a function
involves references. Do you actually reason (albeit subconciously) using a
full semantics which includes possible effects due to aliasing of
references or changes to their contents somewhere deep in the functions,
or do you use a rule `well this is 99% likely to be referentially
transparent so I'll assume it is, but I'll keep in the back of my mind the
possibility this assumption may be wrong'? (That's what I'd end up doing I
think.)

> Haskell (and ML) really is different. First, it's not
> implementation-defined.

Umm, again I'd say this is debatable: the volume of e-mail to/from Simon
PJ about the haskell 98 report even though there are various Haskell 98
interpreters/compilers out there suggests this isn't true. Likewise, C and
C++ have specifications which are met to a reasonable degree by many
compilers out there, which prompts the question: when was the last time a
bug in your code in an imperative language was due to an
implmentation-defined part of the language? In 5 years of intensive C++
programming I'd guess I've made maybe 25 bugs due to this, but the number
of bugs I've fixed in my code must be in the tens of thousands.

FWIW, my take on the single biggest reason why I like and am more
productive in situations where I can use a functional language over an
imperative language is essentially being sheilded from temptation: because
in a typical imperative language you tend to have to implement a
case of `map f xs', for example, by a separate routine that knows what the
types of f and xs are (and maybe even what f is) and where you have to
explicitly manipulate things via temporary variables and array indices,
there's an almost impossible urge (often even subconcious) to specialise
and `optimise' things in ways which are in reality very error prone and
difficult to understand. In contrast, not being able to do these sorts of
nasty things in Haskell leads me to do things the next-simplest way,
which is generally using higher order functions and the like (where things
by definition can't go wrong in many of the ways of C).

___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law:  however many computers
email: tweed@cs.bris.ac.uk      |   you have, half your time is spent
work tel: (0117) 954-5250       |   waiting for compilations to finish.