Raffael Cavallaro <[EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com> writes: > > It never occurs to Lisp programmers that Lisp, too, might be a Blub. > > Of course it does - Thats why we try ocaml and haskell etc. It's just > that we don't see the useful features of these languages as being > sufficiently useful to compensate for their lack of the ability to > easily do syntactic abstractions over a uniform syntax.
That sounds to me like a Blub programmer speaking. > For example, a common lisp with optional static typing on demand would > be strictly more expressive than common lisp. But, take say, haskell; > haskell's static typing is not optional (you can work around it, but > you have to go out of your way to do so); haskell's pure functional > semantics are not optional (again, workarounds possible to a limited > extent). This requires you to conceive your problem solution (i.e., > program) within the framework of a particular paradigm. This lock-in > to a particular paradigm, however powerful, is what makes any such > language strictly less expressive than one with syntactic abstraction > over a uniform syntax. Incorrect, I believe. The above is like saying Lisp's lack of optional manual storage allocation and machine pointers makes Lisp less powerful. It's in fact the absence of those features that lets garbage collection work reliably. Reliable GC gets rid of a large and important class of program errors and makes possible programming in a style that relies on it. You can make languages more powerful by removing features as well as by adding them. This is what Haskell does, with its functional purity. Haskell's lazy evaluation semantics pretty much depend on the purity. See also SPJ's papers on composable memory transactions in Haskell: http://research.microsoft.com/~simonpj/papers/stm/index.htm These transactions rely on Haskell's pure functional semantics and if I understand correctly, can't be implemented reliably without it. And just like GC gets rid of a large class of pointer and storage allocation errors, composable transactions in concurrent programs get rid of lock-related errors, traditionally a huge source of problems in real-world code. -- http://mail.python.org/mailman/listinfo/python-list
