"Kaz Kylheku" <[EMAIL PROTECTED]> writes: > > Incorrect, I believe. The above is like saying Lisp's lack of > > optional manual storage allocation and machine pointers makes Lisp > > less powerful. > > That is true. By itself, that feature makes Lisp less poweful for > real-world software dev, which is why we have implementation-defined > escape hatches for that sort of thing. > ... > This is a bad analogy to the bondage-and-discipline of purely > functional languages. [/] The removal for the need for manual object > lifetime computation does not cause a whole class of useful programs > to be rejected.
Did you just say two conflicting things? It's that very rejection that necessitates the escape hatches. > In fact, all previously correct programs continue to work as before, > and in addition, some hitherto incorrect programs become correct. > That's an increase in power: new programs are possible without losing > the old ones. There's more to power than making more programs possible. We also want to be able to distinguish correct programs from incorrect ones. Lisp has the power to eliminate a large class of pointer-related errors that are common in C programs, so Lisp is more powerful than C in that regard. Increasing the number of programs one can write in the unfounded hope that they might be correct is just one way to increase power. You can sometimes do that by adding features to the language. Increasing the number of programs you can write that are demonstrably free of large classes of errors is another way to increase power. You can sometimes do that by REMOVING features. That's what the Lisp holdouts don't seem to understand. > Right. GC gets rid of /program errors/. Pure functional programming > gets rid of /programs/. GC also gets rid of programs. There are programs you can write in C but not in Lisp, like device drivers that poke specific machine addresses. > /Pure/ functional programming isn't about adding the feature of > functional programming. It's about eliminating other features which > are not functional programming. It seems to me that Haskell does some mumbo-jumbo to be purely functional only in some theoretical sense. In practice, its purity is enforced only in functions with a certain class of type signatures (i.e. most functions). You can write impure code when needed, by adding certain monads to the type signature of your function. The point is Haskell's static type system can then tell exactly which parts of your code are pure and which are impure. If you do something impure in a funciton with the wrong signature, you get a compile time error. You can choose to write in a style that separates pure from impure functional code in a Lisp program, but the compiler can't check it for you. If you get it wrong and call an impure function from your "pure" code (say in a lock-free concurrent program), all kinds of obscure bugs can result, like pointer errors in a C program. -- http://mail.python.org/mailman/listinfo/python-list
