<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


Someone could define a version of Common Lisp with these characteristics...<br><br></blockquote></blockquote><div><br>... hopefully that never happens !<br><br>Patronizing assumptions  on the part of language implementors have mostly been avoided in CL up until now.<br>
There's a reason hackers choose CL to design/implement their systems : they are willing to take responsibility for their own code. For the opposite case think Java. Java's StringBuffer class came about due to flawed assumptions that had to be handled after the fact. The world that is modeled in software is not as cut and dried as we would all like it to be : resources are not infinite.<br>
<br>That being said, I really do like some of the features that I've seen in Clojure (speaking from actual experience using Clojure and CL). Forcing immutable data structures on users to simplify the language implementation issues or to make concurrent programming 'easier' is neither of them. The one thing I would change in Clojure is this very thing. Even Haskell has it's monads and Lisp allows for functional and imperative styles to be mixed. <br>
<br>There may be an important lesson here ...<br><br></div></div>