On 2006-12-17 12:49:46 -0500, Jon Harrop <[EMAIL PROTECTED]> said: > For example, when faced with a problem best solved using pattern matching > in Lisp, most Lisp programmers would reinvent an ad-hoc, informally > specified and bug-ridden pattern matcher of their own.
No, I think most of us would use an exising lisp pattern matcher, like cl-unification. > >> By asking this question you've implicitly admitted that to solve it *as >> he thought of it* in a pure functional language would require >> reconceptualizing it (i.e., the aforementioned "jumping through >> hoops"). > > You are saying that solving it as he solved it requires a different > solution. How does that make Lisp any different to the next language? Give kenny some credit for not being a complete idiot. Cells was originally designed to keep UI elements in sync with an internal application model. The UI domain is I/O, i.e., a side effect. To do this lazily invites situations where an inherently unpredictable user action forces a complex series of constraints to be computed before anything can be displayed to the user, so the user must wait while the lazy system catches up. To do this eagerly means that at any time, any unpredictable user action will cause already computed state to be displayed, because everything has been kept up to date automatically all along. I'm saying that he conceived of the problem in the most natural way - state with mutations - and implemented it that way. He was not forced by his language to reconceive it purely functionally, have haskell implement the default lazy semantics, only to require the programmer to find an escape hatch from this default laziness since what he really wants is eager evaluation of side effects (i.e., I/O - syncing of model state with GUI display). People habitually think of the world as state and mutations of state. We've been doing so for a minimum of tens of thousands of years, quite possibly a million or more. People are good at thinking about mutation. Maybe this should tell us something about the desirability of certain programming language semantics and that referential transparency is a bit overrated. > >> We don't want to reconceptualize everything according to a particular >> paradigm, we want the flexibility to write the solution to >> the problem in the terms we think and talk about it, not the >> procrustean bed of pure functional semantics. > > Of the programming paradigms that can be implemented in Lisp, Lisp doesn't > exactly make them easy. Moreover, every time you pick a random Lisp library > off the wall to implement some feature already found in most other > languages, you fragment the already tiny user base into even fewer people. Not all lisp programmers will be solving the same sorts of problems as each other, so naturally they'll be using different sets of libraries. This use of different sets of libraries for different tasks doesn't constitute laguage fragmentation. -- http://mail.python.org/mailman/listinfo/python-list