from my background, you can only go by what people promise. The interface promises it will work with maps. using anything else is undefined behavior. So I am wrong to assume anything about sort, also, under the same argument.
it like this : http://www.fallacyfiles.org/afthecon.html you can only assume what they tell you to assume. Until the documentation says otherwise, you can't count on what happens to work. . . . unless you program in Eiffel, I guess. That said, merge is still perplexing to me. It should be "meld" . . .or even "meld-maps" or "conjoin-maps" . .. . especially accurate given how it is implemented. On Sat, Jan 24, 2009 at 12:10 PM, [email protected] <[email protected]>wrote: > > I understand that merge uses conj, but my point remains. I, and I > would imagine at least a few others in the programming world, view an > API's documentation as it's contract with the rest of the world. In > general it tells me what the function expects from me, and what I > should expect from the function. So when I read a doc string that > strictly speaks in terms of maps, I wonder what that means for other > data structures? Is this behavior I can rely on? Is it something > that will go away in the future? I think stuff like this stems from > the fact that it's a LISP, and that functions defined types rather > than an explicit type system (along with the fact that I come from a > Java/C++ background). However, if the doc is going to talk about a > specific "type", then I feel the function should limit itself to that > type. > > I understand this is nit-picky, and I'm not going to be upset if > nothing changes. I just thought I'd point it out. It could also be > that I missing something fundamental. > > > On Jan 24, 11:00 am, wubbie <[email protected]> wrote: > > In core.clj, merge is essentially defined using conj. > > user=> (merge '(1) 2) > > (2 1) > > user=> (merge [1] 2) > > [1 2] > > user=> (merge #{1} 2) > > #{1 2} > > user=> (conj '(1) 2) > > (2 1) > > user=> (conj [1] 2) > > [1 2] > > user=> (conj #{1} 2) > > #{1 2} > > user=> (conj {:name "ryan"} {:age 25}) > > {:age 25, :name "ryan"} > > > > -sun > > > > On Jan 24, 10:51 am, e <[email protected]> wrote: > > > > > merge confused me, too. I was surprised to see in the docs that its > input > > > needn't be sorted (or have anything to do with lists) . . . .or maybe > it > > > merges unsorted things however, but where's the discussion of whether > the > > > result of merging two sorted list is a sorted list? Well, it's avoided > > > because it's for maps. > > > > > On Sat, Jan 24, 2009 at 1:13 AM, [email protected] < > [email protected]>wrote: > > > > > > user=> (doc merge) > > > > ------------------------- > > > > clojure.core/merge > > > > ([& maps]) > > > > Returns a map that consists of the rest of the maps conj-ed onto > > > > the first. If a key occurs in more than one map, the mapping from > > > > the latter (left-to-right) will be the mapping in the result. > > > > nil > > > > > > According to merge's doc string it is meant to work on maps. > However, > > > > this is only part of the truth: > > > > > > user=> (merge '(1) 2) > > > > (2 1) > > > > > > user=> (merge [1] 2) > > > > [1 2] > > > > > > user=> (merge #{1} 2) > > > > #{1 2} > > > > > > Of course, the canonical example: > > > > > > user=> (merge {:name "ryan"} {:age 25}) > > > > {:age 25, :name "ryan"} > > > > > > What's the point? Maybe the doc string should be changed to be more > > > > general, or perhaps merge should check that it is indeed working with > > > > maps? > > > > > > Personally, this doesn't bother me all that much. However, if people > > > > rely on this behavior then it could be harmful if in a future version > > > > of Clojure merge only works for maps, or if it's results change for > > > > the other types of structures. I feel that a doc string should act > as > > > > a contract between the function and it's user (think Eiffel). I > think > > > > the contract for merge could be improved. > > > > > > -Ryan > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
