> True, that's a problem. But couldn't the library protect itself by > putting a (binding [*strict* false] ...) in front of its code? > (Having a namespace-level binding construct would be helpful.)
That's exactly what I meant when I wrote "it would introduce a problem that library authors have to think about". I don't support any solution that requires libraries to "protect themselves" from decisions made in user code, particularly when it's so easy to externally control the evaluation of lazy sequences -- just visit them within the correct bindings! > This raises a more general thought about binding in general (while > we're talking about new language constructs). Right now you have > basically two choices for influencing code: Parameter passing, which > is, "nothing happens to my code without my permission", and dynamic > binding, which is "You might have the rug yanked from under you, and > there's nothing you can do about it!" (Exclamation point here is an > indicator of mutation, not exclamation.) An interesting point that I don't think anyone's addressed: it's not so much that the rug might be yanked from under you, but that you might find yourself on a different rug when asked to do the work. That can actually be advantageous; you can create lazy sequences and hand them somewhere else, where the appropriate bindings will be enforced during evaluation. (Maybe selecting an output stream or queue dynamically while processing a lazy stream of values, for example). Perhaps I'm just an optimist, or think a little differently. > I'm not really sure what this construct would look like. Somebody > else might have a better idea.... I believe that Rich has done some speculative work on scoping constructs. > Maybe the problem with binding is not that it's inherently evil, it's > just not democratic enough. Heh, I would say it's too democratic — there's something you want to do, but the broader 'society' (the existing configuration of lazy constructs and bindings) wants to do something else, so you must suffer! I'd venture a different opinion: most programmers are not used to thinking of evaluation outside the lexical order (much the same as the switch to concurrent programming). Once you get that, it ceases to be a big deal, and you use appropriate techniques (thunks, controlling evaluation yourself, taking care to choose your scopes, etc.) without much conscious thought. This switch causes a divide in discussions, where one side sees a huge problem to be fixed, and the other side sees an interesting language feature which both requires care and offers power, but arises naturally from the semantics of the language. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
