Range equivalence

[Tom Mulvaney]

Hi,

I was running into slower performance than I expected doing some ClojureScript at work and noticed that one source of slowness was comparing two Range objects. 

At the moment Range equivalence in ClojureScript involves calling `equiv-sequence`. Clojure appears to also do a sequence comparison. When comparing a Range with another Range, would it not be better to just compare `start`, `end` and `step` fields of the other Range, and fall back to a sequence comparison when the other object is not a Range?

Cheers,

Tom

[Alex Miller]

This is a slippery slope into a lot of very implementation-dependent mucking that I have generally shied away from. While Clojure happens to have a particular implementation of range (actually 3 implementations), and it would be possible to override equality to potentially do special things, I don't think it's a great idea. Right now there is a generic and uniform approach (compare the values in order) and adding something like this would be a special case (one of many potential such cases). This would allow you to compare *some* infinite or large sequences in constant time, but not others. It changes the laziness expectations, etc. Every one of these special cases adds complexity to the code and over time I expect they would start to interact, cause bugs, and make changing the implementation harder. So, I have no eagerness to do this.

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

[Thomas Mulvaney]

Thanks,

I suspected it boiled down to keeping things simple, generic and uniform.

At least things are fairly open for extension so I shall just continue to override the -equiv protocol for Ranges and SubVectors where it makes sense.

Cheers,

Tom