On Sat, 09 Feb 2008 04:15:51 GMT, stephen@[EMAIL PROTECTED]
(Stephen
J. Bevan) wrote:
>George Neuner <gneuner2/@[EMAIL PROTECTED]
> writes:
>
>> However, Dylan is still a Scheme is still a Lisp.
>
>Aren't all functional languages a Lisp then?
Not really. Although Lisp took some ideas from lambda calculus, it
was intended from the beginning to be a practical language and being
too functional was impractical for much of Lisp's lifetime. So Lisp
evolved as a multi-paradigm language, directly supporting both
functional and imperative programming, and supporting OO over the
functional base. Lisp has a lot of language support for imperative
programming: mutable data, assignment, iteration, GO(to), etc.
Scheme tried much harder to go in the functional direction - it
introduced static scoping, did away with iteration in favor of
recursion and chose generalized continuations over GO(to). It did,
however, still have mutable data and assignment.
Dylan evolved from Scheme. Dylan made every data type a full fledged
extensible object in the OO sense and added generic functions ala
CLOS. It also added optional static type checking and would elide
runtime type checks whenever an expression could be completely
statically typed. Dylan started out using sexprs but later it was
changed to use a more conventional syntax.
ML started as a theorem prover and drew inspiration directly from
lambda calculus. Although I'm sure ML designers knew about Lisp, ML
went in a different direction, eschewing imperative programming almost
completely.
I don't know the history of Haskell or Miranda or Ruby, but I doubt
Lisp had much direct influence on them.
I would say that they are all descendants of lambda calculus, but I
would hesitate to call the functional language group descendants of
Lisp. Maybe you could say they are descendants of McCarthy original
idea for Lisp, but not what was actually implemented.
>Or is there something
>different about some functional languages (Haskell?) which makes their
>GC requirements different?
The functional languages, as a group, average higher allocation and
infant mortality rates than is typical for Lisp - it's important to
focus effort on allocation speed and on efficiently cleaning the
nursery in an FPL (Lisp also benefits from these things, just to a
lesser degree).
Also mutable vs immutable data makes a huge difference in the
complexity of the collector if GC is intended to be interleaved or
concurrent with the program.
I don't know specifically about Haskell, but I would imagine that it
has slightly higher rates of closure creation and disposal than the
average FPL.
George
--
for email reply remove "/" from address
|
