[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's so cool about Scheme?

> Date: Tue, 03 Jun 2003 01:18:48 -0400
> From: Mike Newhall <mike@newhall.net>
> 	Correct my naivete if I am missing the big picture, but to me the
> coolest things about Scheme and LISP-like languages seem to be:
> 1. Code = data (including the necessary lambda for getting a handle on
>    environments to create closure 'data' objects)

Those are two separate things, but both are useful.  ML languages have
closures but do not represent code as data.  Having code as data permits
structural macros.

> 2. A 'graph engine': CONS cells are like Turing-complete data structures:
>    you can build any imaginable data structure without explicitly using
>    pointers or managing memory

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.

> 	Tail recursion is cool but that is a real-world optimization, no?  On
> an abstract machine you never run out of stack space (if we are talking
> purely from an abstract language design perspective -- i.e., ease of
> programming from a human point of view).

It's a pretty important optimization.  I wouldn't want to do functional
programming without tail call optimization.

> 	I think these two features enable or greatly simplify metaprogramming:
> higher-order functions, code manipulating code for the purposes of
> implementing macros and so on.
> 	What, specifically, do you need beyond these features to enable a
> 'functional paradigm'?  Do you even need these features in a language to
> adhere to a functional paradigm?

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.

> The point of all this is the question: Is Scheme really a 'functional
> programming language' or is it just a really general purpose tool that
> allows functional programming?  

Yes ;-)  Scheme was explicitly designed to support functional and
imperative programming.  It can pretty easily be extended to support other
paradigms (e.g. OOP).

> Instead, does this set of features that
> lends generality to Scheme constitute a cool idea but one with no good
> name, so the label 'functional' is misapplied?  Would Scheme, LISP and
> their relatives be better categorized as 'orthogonal graph machines' or
> some such?  

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).