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

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.