RE: What's so cool about Scheme?

["Bayley, Alistair" <address@hidden>]

(This are clearly my opinions... not necessarily shared by others on the
list)

> isn't functional programming just programming without side effects
> ...
> Or is the idea of higher-order programming [arbitrarily] bundled
> into the idea of functional programming?

Functional programming is a style, typified by the use of first-class
functions, and higher-order functions (functions that take functions as
arguments and apply them, and functions that return functions).

How do you define a programming style? For example, I think of
object-oriented programming as a style typified primarily by inclusional
polymorphism. To write good OO code you should also practice modularity,
encapsulation, and delegation, but these techniques can also be applied to
procedural languages. That is, the thing that determines whether or not a
language is object-oriented is: does it support inclusional polymorphism?

Likewise, if a language provides first-class/higher-order functions, then I
would say it is a functional language. That would include Lisp, Scheme,
Dylan, ML, Ocaml, Oz, Erlang...

Some functional languages support programming in a variety of styles. In
Scheme, Lisp, and Oz you can write in object-oriented, functional, logical,
and procedural styles. Haskellers will argue that you can write procedural
code in Haskell using monads (and that Haskell also supports object-oriented
programming through inclusional polymorphism).

> isn't functional programming just programming without side effects

You can classify functional languages as pure/impure, lazy/eager. You tend
to find that the lazy languages (Haskell, Clean, Miranda) are pure, and
impure languages (Lisp, Scheme, ML) are eager. There's no reason you can't
have a pure eager language, but I can't think of one (anybody?). Impure lazy
languages aren't really feasible, because the laziness means that you can't
predict when side-effects will occur, which is not useful if you use
side-effects to perform I/O.


-----Original Message-----
From: Mike Newhall [mailto:mike@newhall.net]
Sent: 03 June 2003 07:48
To: Michael Vanier
Cc: ll1-discuss@ai.mit.edu
Subject: Re: What's so cool about Scheme?


>You can build any imaginable data structure, but it won't necessarily have
>the efficiency you want.  Looked at another way, cons cells are just a
>specialization of vectors.  Looked at another another way, cons cells
>follow from lambda calculus.

	True, but I think general graphs are what humans really want, just
as Scheme can be implemented in machine language: machine language is
technically equivalent but it's not the ideal programming environment.  Here
I'm not considering efficiency; what I'm interested in is CONS as a language
feature and not it's implementation; if the compiler can figure out how to
avoid actually using cons cells at runtime all the better.

>You don't need code-as-data, since neither Haskell or ML support that, and
>both undoubtedly support functional programming.  IMO you need
>
>-- first-class functions
>-- proper lexical scoping
>-- tail call optimization
>
>for a language to be said to support FP.  Haskell fans would probably add
>monadic I/O and lazy evaluation to that list.

	As an aside, why first-class functions?  I think first class
functions are incredibly useful in general, but, strictly speaking, isn't
functional programming just programming without side effects and all the
benefits that brings, and thus why can't you do that without passing
functions around?  Or is the idea of higher-order programming [arbitrarily]
bundled into the idea of functional programming?

>Not sure what you mean by "orthogonal graph machines", but I agree that
>scheme's significance extends beyond FP, and that (conversely) there are
>aspects of FP that scheme doesn't deal with directly (implicit lazy
>evaluation, monads, static typing).

	The general idea is simply that the bundle of ideas represented by
the design of the LISP family of languages is important, but seems to have
no name.  Other languages also possess many of the same qualities of LISP
and Scheme.  These languages are often labeled 'functional'; perhaps the
whole 'functional programming languages' field should bifurcate into *true*
functional languages and those that have the 'LISP quality', whatever people
want to call it.

P.S. I left out 'dynamic typing' as one of the important LISP-like-languages
features.  I know there's a lot of mind share for static typing, but in my
opinion you lose something important in a purely statically typed language;
each paradigm has a purpose (I don't see why they can't coexist in the same
language, either).  More ammo for the argument that "LLL's" are a distinct
species from functional languages.


*****************************************************************
The information in this email and in any attachments is 
confidential and intended solely for the attention and use 
of the named addressee(s). This information may be 
subject to legal professional or other privilege or may 
otherwise be protected by work product immunity or other 
legal rules.  It must not be disclosed to any person without 
our authority.

If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you 
are not authorised to and must not disclose, copy, 
distribute, or retain this message or any part of it.
*****************************************************************