On Oct 11, 6:56 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> When a var's definition has a "lazy reference" to itself, as primes does
> below, then your results will be dependent on the lazy/chunky/strict-ness of
> the calls leading to the lazy reference.
While I agree that this sort of reference is probably rare in non-
Euler problems, at best this behavior seems very confusing. Everywhere
else in Clojure (that I know of) seqs are immutable, so it is strange
to observe them changing out from under you here. Perhaps it could be
an error to try to get the next of a lazy seq from within the
computation of that next, rather than just getting nil?
In fact, I can force a potentially more severe bug by modifying the
example slightly, making nums finite and computing the hash of
"primes" within the let:
(def nums (drop 2 (range 100)))
(def primes (cons (first nums)
(lazy-seq (->>
(rest nums)
(remove
(fn [x]
(let [dividors (take-while #(<= (* % %) x)
primes)]
(hash primes)
(some #(= 0 (rem x %)) dividors))))))))
Now, I can get Clojure to compute and cache an incorrect hash for
primes:
user> (take 5 primes)
(2 3 5 7 9)
user> (hash primes)
33
user> primes
(2 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 37 41 43 47 53 59 61 67 71
73 79 83 89 97)
user> (hash (vec primes))
-2057877582
user> (contains? #{primes} (vec primes))
false
-Jason
--
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
