Then all of them must be schizophrenic: forcing delay X while forcing delay
X gives a stack overflow except if the delay happens to be the rest-part of
a lazy seq, and then gives nil instead making the sequence seem to
terminate early.
That's very odd. How does it "know" whether the delay it's
Clojure 1.6.0
user=> (def foo (delay (str @foo)))
#'user/foo
user=> @foo
StackOverflowError clojure.lang.Delay.deref (Delay.java:37)
user=>
same with Clojure 1.7.0-master-SNAPSHOT, I don't see it returning nil
as you said.
On Fri, Feb 13, 2015 at 7:53 AM, Fluid Dynamics wrote:
> On Friday, Feb
Clojure 1.5.1
user=> (def bar (cons 1 (map #(do (println %) (+ (nth bar %) %)) (range
#'user/bar
user=> (take 10 bar)
(0
1
IndexOutOfBoundsException clojure.lang.RT.nthFrom (RT.java:795)
It is possible that it is lein/REPLy that's causing the output not to
be print, I've seen it done a num
And here's some really crazy behavior from 1.5.1!
=> (def bar (cons 1 (map #(do (println %) (+ #_(nth bar %) %)) (range
#'user/bar
=> (take 10 bar)
(0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1 0 1 2 3 4 5 6 7 8)
=> (def bar (cons 1 (map #(do (println
On Friday, February 13, 2015 at 12:47:17 AM UTC-5, Justin Smith wrote:
>
> I don't want to sound too brusque in my defense of Clojure. I'm a huge
> fan, so criticism of the language does get me a bit defensive.
>
I am a fan as well. Constructive criticism is useful as it can lead to
improvements
To go into a bit more detail about what this code does:
Here's the code formatted idiomatically -
(defn divides? [x y] (zero? (mod x y)))
(defn prime-ub [x] (/ x (if (even? x) 2 3)))
(defn lower-primes [primes x]
(let [ub (prime-ub x)]
(take-while #(<= % ub) primes)))
(defn prime? [prime
On Friday, February 13, 2015 at 12:05:24 AM UTC-5, Justin Smith wrote:
>
> it's an infinite lazy sequence with itself as a dependency. The first n
> elements see a value of the initial non-lazy prefix. The alternative would
> be a compilation error.
Nope. Every component of the sequence should
it's an infinite lazy sequence with itself as a dependency. The first n
elements see a value of the initial non-lazy prefix. The alternative would be a
compilation error.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send em
it's an infinite lazy sequence with itself as a dependency. The first n
elements see a value of the initial non-lazy prefix. The alternative would be a
compilation error.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send em
On Thursday, February 12, 2015 at 11:24:03 PM UTC-5, Justin Smith wrote:
>
> Not unbound primes, primes as (cons 2 ...). If you look at my post above
> where I added a print statement to prime? the first 32 inputs see (2) as
> the value of primes. 32 is the chunking size of the range function.
Oh, it's much worse than anyone has mentioned yet. The whole (def primes
...) bit is also a problem. What you are saying to the compiler is "create
a var named primes and assign it this lazy-seq...", and then while defining
that lazy seq you are creating closures that use "primes". That sort of
cir
Not unbound primes, primes as (cons 2 ...). If you look at my post above where
I added a print statement to prime? the first 32 inputs see (2) as the value of
primes. 32 is the chunking size of the range function.
--
You received this message because you are subscribed to the Google
Groups "Clo
I really fail to see how this can be related to chunking. So in:
(def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3
(range))
*prime?* would be being called with unbound *primes*? And no exception
would be raised and again no 4 or even numbers left to testify?
Em sexta-feira,
Clojure is quite elegant, but it's not always unsurprising.
Even if one surprising behavior around lazy-seq realization is changed,
others are likely to continue to occur.
The solution to this is to not write code that implicitly relies on a
specific timing of lazy realization. If you need resu
Even THIS works now:
(defn primes [] (let [primes' (atom nil)]
(reset! primes' (cons 2 (filter #(prime? @primes' %)
(iterate inc 3))
Em sexta-feira, 13 de fevereiro de 2015 01:28:13 UTC-2, Jorge Marques
Pelizzoni escreveu:
>
> Anyway, I would be in awe that being Closure
Anyway, I would be in awe that being Closure such an expressive and
elegant language its user base is really ok with an state of affairs in
which:
(def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3
(range))
does not mean what it obviously should and above all means something
no, we have not moved past this, and the error is absolutely because you
take too much for granted about lazy behavior
(defn divides? [x y] (zero? (mod x y)))
(defn prime-ub [x] (/ x (if (even? x) 2 3)))
(defn lower-primes [primes x] (let [ub (prime-ub x)]
(println "primes" primes "x" x)
(tak
So why isn't 4 and any even numbers in the result list? Empty primes'
allows everything to pass. We are already beyond this. I've already posted
that even this does not work:
(def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3
(range))
Em sexta-feira, 13 de fevereiro de 2015
Considering for the sake of argument the possibility that it is a
legitimate bug, and not a result of misusing the language features, it is a
family of bug that will be more common than most, because it reflects a
style of programming that is rare in real Clojure code.
But it isn't a bug.
Lazy
Not even this works (in which I try to avoid state mutation):
(def primes (cons 2 (lazy-seq (filter #(prime? primes %) (drop 3
(range))
Em quinta-feira, 12 de fevereiro de 2015 23:26:03 UTC-2, Fluid Dynamics
escreveu:
>
> AFAICT the issue here is combining lazy evaluation with state mutat
AFAICT the issue here is combining lazy evaluation with state mutation.
Don't do that. :)
--
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 - p
Beautiful, Armando! Thanks for your the insight. Anyway, I really don't buy
the "that's the way it is" argument. Totally looks like a bug and I don't
find it a coincidence it is working differently in the development branch.
Thank you all for your time :)
Em quinta-feira, 12 de fevereiro de 20
This is excellent, I was just working out something similar myself.
The version using an atom is not idiomatic Clojure, and isn't a translation
of the Haskell version either.
On Thursday, February 12, 2015 at 4:30:02 PM UTC-8, Armando Blancas wrote:
>
> Jorge, I tried this on 1.6 and seemed to w
Jorge, I tried this on 1.6 and seemed to work:
(def primes
(cons 2 (for [n (iterate inc 3) :when (prime? primes n)] n)))
On Thursday, February 12, 2015 at 4:21:45 PM UTC-8, Jorge Marques Pelizzoni
wrote:
>
> Neither did delay help:
>
> (defn primes [] (let [primes' (atom nil)]
>
Laziness is pervasive in Haskell, for all computation (unless you force it
off with special constructs).
Laziness in Clojure is as pervasive as sequences, but it is not for all
computation like in Haskell, and sequences have the previously-mentioned
features of sometimes-more-eager-than-the-minimu
Neither did delay help:
(defn primes [] (let [primes' (atom nil)]
(reset! primes' (delay (cons 2 (filter #(prime? (force
(deref primes')) %) (drop 3 (range
Serious this is not a bug?
Em quinta-feira, 12 de fevereiro de 2015 22:14:46 UTC-2, Jorge Marques
Pelizzoni esc
Thanks, Michael, for your analysis and explanation. However not even this
worked:
(defn primes [] (let [primes' (atom nil)]
(lazy-seq (reset! primes' (lazy-seq (cons 2 (lazy-seq
(filter #(prime? (deref primes') %) (drop 3 (range))
And one thing we klnow for sure is th
Hmm, upon further investigation I think I would not call this a bug in
Clojure that got fixed, I think I'd call this an unspecified behavior in
Clojure that happened to break your function and now happens to allow it to
work.
Your function depends heavily on Clojure's laziness, and laziness is an
Or perhaps 1.7.0-alpha5 has a change vs. 1.6.0 that makes this code work by
accident.
Using lazy sequences to define later elements in terms of the prefix of the
sequence up to that point has come up multiple times, usually with the
example of generating primes (but different code each time).
I d
Well, that's a bug then :) And seems to have been fixed. Thanks!
Em quinta-feira, 12 de fevereiro de 2015 17:51:13 UTC-2, Michael Blume
escreveu:
>
> Oh, well this is fun -- with bleeding edge clojure I get the right answer,
> but with 1.6.0 I see the same results you did.
>
>
>
--
You receive
Oh, well this is fun -- with bleeding edge clojure I get the right answer,
but with 1.6.0 I see the same results you did.
On Thu Feb 12 2015 at 11:47:54 AM Michael Blume
wrote:
> Strange, when I run your code I don't get 9 or 15
>
> On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni <
> j
Strange, when I run your code I don't get 9 or 15
On Thu Feb 12 2015 at 11:02:00 AM Jorge Marques Pelizzoni <
jorge.pelizz...@gmail.com> wrote:
> Hi, there! Please bear with me as I am very new to Closure (this is my
> second program ever) but have a kind of solid Haskell background.
>
> I was tr
Hi, there! Please bear with me as I am very new to Closure (this is my
second program ever) but have a kind of solid Haskell background.
I was trying to get a version of this Haskell code:
divides x y = mod x y == 0
primeub x = div x (if even x then 2 else 3)
isprime primes x = all (not . divide
33 matches
Mail list logo
