Richard--- > What if you accidentally cause a library to realize an infinite > lazy sequence?
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.) 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.) Well, this might be wildly speculative, but couldn't there be a middle way? I.E. a scope or a function body (if we are trying to unify these concepts then Scope and Function Body is really the same thing), instead of exporting variables of things that can be substituted, basically sets up a negotiation over what can and should be bound. It might state things like "binding this such-and-such a way is a \really \bad idea, but if you do X first, it would be OK; and of course if you \insist...." The actual binding (if such a guard has been put up) then doesn't happen until the conditions have been run through. I'm not really sure what this construct would look like. Somebody else might have a better idea.... Maybe the problem with binding is not that it's inherently evil, it's just not democratic enough. -- 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
