Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Haskell and ML are both evaluate typed lambda calculus unlike Lisp > which is based on untyped lambda calculus. Certainly the most > familiar features of Lisp (dynamic typing, S-expression syntax, > programs as data (Lisp's macro system results from this)) are absent > from Haskell and ML. And that is supposed to make them better and more flexible??? The ideal language of the future will have *optional* manifest typing along with type-inference, and will have some sort of pramgma to turn on warnings when variables are forced to become dynamic due to there not being enough type information to infer the type. But it will still allow programming with dynamic typing when that is necessary. The last time I looked at Haskell, it was still in the stage of being a language that only an academic could love. Though, it was certainly interesting. > Haskell's type system lets it do stuff that Lisp can't approach. What kind of stuff? Compile-time polymorphism is cool for efficiency and type safety, but doesn't actually provide you with any extra functionality that I'm aware of. > I'm reserving judgement about whether Haskell is really practical > for application development, but it can do stuff that no traditional > Lisp can (e.g. its concurrency and parallelism stuff, with > correctness enforced by the type system). It makes it pretty clear > that Lisp has become Blub. Where do you get this idea that the Lisp world does not get such things as parallelism? StarLisp was designed for the Connection Machine by Thinking Machines themselves. The Connection Machine was one of the most parallel machines ever designed. Alas, it was ahead of it's time. Also, I know a research scientist at CSAIL at MIT who has designed and implemented a version of Lisp for doing audio and video art. It was designed from the ground-up to deal with realtime audio and video streams as first class objects. It's actually pretty incredible -- in just a few lines of code, you can set up a program that displays the same video multiplied and tiled into a large grid of little videos tiles, but where a different filter or delay is applied to each tile. This allows for some stunningly strange and interesting video output. Similar things can be done in the language with music (though if you did that particular experiment it would probably just sound cacophonous). Does that sound like an understanding of concurrency to you? Yes, I thought so. Also, Dylan has optional manifests types and type inference, so the Lisp community understands some of the benefits of static typing. (Even MacLisp had optional manifest types, but they weren't there for safety, but rather for performance. Using them, you could get Fortran level of performance out of Lisp, which was quite a feat at the time.) > ML's original implementation language is completely irrelevant; > after all Python is still implemented in C. Except that in the case of ML, it was mostly just a thin veneer on Lisp that added a typing system and type inference. >> Also, Scheme has a purely functional core (few people stick to it, of >> course), and there are purely functional dialects of Lisp. > Scheme has never been purely functional. It has had mutation since > the beginning. I never said that was purely functional -- I said that it has a purely functional core. I.e., all the functions that have side effects have and "!" on their ends (or at least they did when I learned the language), and there are styles of programming in Scheme that discourage using any of those functions. |>oug P.S. The last time I took a language class (about five or six years ago), the most interesting languages I thought were descended from Self, not any functional language. (And Self, of course is descended from Smalltalk, which is descended from Lisp.) -- http://mail.python.org/mailman/listinfo/python-list
