On Mon, Nov 9, 2009 at 3:31 PM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > > 2009/11/9 Tiago Antão <tiagoan...@gmail.com>: >> What is the rationale for even? and contains? having different >> behaviors for the exact same error (ie, one throws the other works >> fine and just returns false on a type error)? From a design >> perspective this seems to increase the cognitive load to programmers >> without any (apparent) reason. >> > > I imagine the rationale is efficiency. Every core function could > conceivably do a number of runtime checks to make sure that each input > is the right kind of type, and then Clojure might feel more sluggish. > So instead, the core functions just worry about what to do for the > appropriate inputs. If you pass a bogus input, the consequence > depends entirely on how that particular function was coded. It might > return a spurious result, or it might error. There are numerous > examples of this in the Clojure API. >
Efficiency is certainly part of it. However, it is not spurious. Errors will become exceptions, not random nonsense. Some things one might consider errors are not considered as such, and that is quite a different thing. One presumption here is that this is a simple matter of types. It is not (simple). There are some functions whose domain is constrained by a known/fixed (family of) type(s), but many that are not. even? is (Numbers), contains? is not (open set of associative-like things, false otherwise). This type-openness of many Clojure core functions is one key to its power. I'm sure making contains?/get tolerant of non-associative things gave us benefits elsewhere (i.e. made associative destructuring tolerant of, and thus useful upon, heterogeneous sequences, only some of whose elements were associative). If that were not the case, then any code needed to handle that would need a predicate for an open set in order to filter first. Such predicates are extremely icky to construct and maintain, and, brittle to rely upon. The work I am doing on protocols may help out quite a bit here, as they will provide a unifying point for open abstractions, encompassing explicit type relationships (inheritance form interfaces), superimposed capabilities (e.g. the way Strings become seq-able), and open functional extension (a la multimethods), in a way such that asking (implements? protocol x) will become an open type predicate. > It wouldn't surprise me if there are a number of programmers who would > be turned off by the ease with which one can shoot yourself in the > foot without getting any kind of error message, but in practice I > haven't gotten bit by this yet. > Everyone would like more help from a system when they have made a mistake. But everyone needs to have a realistic view about what can be detected, and at what cost, (especially to produce a revelatory message), as well as a general understanding of open functions. I imagine at some point we may have a diagnostic mode, with many (expensive) runtime checks, and correspondingly more detailed error/mistake reports. But you are right, the emphasis right now is on making correct programs work well. Rich -- 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
