7:08 jteo: i keep getting stack overflows (trying to find a large prime).
9:43 vincenz: jteo: show me the code
9:44 jteo: lemme pastebin it. i think i don't quite grok lazy sequences.
9:45 i managed to solve it by using an iterative approach using loop.
9:49 vincenz: rhickey_: Hey if I roll my own language with some ideas of clojure (and obviously mention their origin) would you mind?
9:49 rhickey_: what would you do differently?
9:50 vincenz: rhickey_: several things, some of which wouldn't be supported in your model
9:50 Well, at least not by the jvm
9:50 The fundamental thing I want are delimited-continuations in the presence of stm
9:50 Since that requires me rolling a new lang, I'll prolly make some other changes as well, as well s keep some ideas
9:51 rhickey_: place it somewhere between clojure, haskell and arc
9:51 well mostly between clojure and haskell :)
9:51 and scheme, cause of the dc's
9:52 (The only neat thing from arc, though I think you support this as well are fun-callable data structures)
9:52 rhickey_: vincenz: well, few of the ideas in Clojure are novel, everyone borrows from the past - good luck!
9:52 vincenz: rhickey_: thanks :)
9:52 Btw, you're welcome to join #oasis
9:52 It's a bit of a social ltu for freenode
9:53 Often silent, but we have bouts of interesting conversations, and a lot of smart people
9:54 jteo: ltu?
9:57 ...where I go to remind myself how little I know about anything.
9:58 jteo: ah.
10:14 rhickey_: jteo: what's the problem with the primes you pasted?
10:15 jteo: rhickey_: stack overflow.
10:23 cgrand: rhickey, in Compiler.java:1790 shouldn't it be "Class classForName(String)" instead of "Class forName(String)"? (else I get MethodNotFound...)
11:51 jteo: I think your code chains filters and, to get a new prime, it has to go through all the filters... and when there are too many filters your stack explodes.
11:52 jteo: cgrand: i guess so. I was trying to figure out how to iterate over a lazy seq.
11:54 ie. some way to skip forward to the nth item in the lazy-seq, without consuming large amounts of memory/cpu.
11:55 obviously loop is one way.
12:18 Modius: jteo: Depending on how the lazy sequence is implemented under the hood, looping through may not alter the CPU usage of any given stage of iteration, nor the memory footprint.
12:18 jteo: true.
12:19 Modius: jteo: What can lead to memory usage also are lazy sequences that make use of memoized links (some require these, e.g. certain self-referencing list solutions) - but the link back to the head (if you somehow keep one) causes all results to be preserved until the end of the computation, limiting how far you can traverse the sequence, or how many can be traversed in parallell with other actions that also use ram.
12:19 jteo: :)
12:20 Modius: jteo: The cliched haskell self-referencing fibonacci highlights this effect - AFAIK spking RAM proportional to N when obtaining the Nth item.
12:21 jteo: given that it's mostly run for small values of N..
12:21 (eg. in tutorials)
12:25 Modius: I believe Clojure has the raw tools required to solve these problems (macros + lambdas), and said solution would be inside its concurrency/STM model.
12:27 By "problem" I mean "ability to programmatically model solutions in this manner", not that it's a language problem per se
12:29 vincenz: Modius: Err..
12:29 Modius: that's a lot of BS :)
12:29 Modius: vincenz: sorry
12:30 vincenz: 1) recursive fibonacci in Haskell is just for tutorials
12:30 2) if you do not want to keep it around, make it a function
12:30 fib n = ...your memoized version !! n
12:31 3) If you do not like to use space, then just write it recursively
12:31 the whole point of the memoized version is to trade-off computation for storage
12:32 Modius: vincenz: Does writing it recursively partially memoize? Otherwise it'll become infinitely slow before the 30th element.
12:32 vincenz: Anywho, a bit weak to bash on $(LANGUAGE) if you do not intimately know said $(LANGUAGE) outside of the $(LANGUAGE) forum where noone is there to watch wat you say.
12:33 Modius: just write it iteratively?
12:33 Modius: vincenz: (On bashing) agreed, wasn't my intend, just to describe an effect. And I'd discussed it on #haskell by the way.
12:33 vincenz: s/uh/duh
12:33 Modius: vincehz: I did try to say "cliched haskell self-referencing fibonacci" - I wasn't indicting a language; but an expression form under memoization.
12:33 vincenz: let fib n = worker 0 1 1 where worker a b m = if m == n then b else worker b (a+b) (m+1)
12:34 * vincenz nods
12:34 vincenz: Modius: But the leakage-problem is acknowleged
12:34 Modius: It's just a trade-off really, do you want to use CPU or do you want to use memory, and granted, if you're not careful you can leak more than you want to.
12:35 Modius: vincenz: I'm not going to hawk my own library in someone else's pond; but I have one where I was able to do both -self-referencing AND memoization; but memoization only between the links, not to the head.
12:36 vincenz: Modius: IIUC, you memoized the last two but not the whole thing?
12:36 Modius: vincenz: I don't consider the "leakage problem" that the cliched fibonacci highlights a haskell problem; but was trying to use it to describe an effect.
12:37 cgrand: jteo: I guess this is not what you look for?
12:45 jteo: cgrand: neat. now let me try to understand how it works. ;)
12:54 i'm having difficulty understanding why this one doesn't cause a stack overflow compared to the sieve implementation i tried.
13:05 cgrand: jteo: in yours, when you have already got 3, 5 and 7 to get the next prime, you ask to your seq (which filter out multiples of 7) for the next item, which asks to its parent seq (filter out 5x) which asks to its parent seq (filter out 3x) which asks to the odd numbers seq. In mine I just loop over the list of known primes (in prime?).
13:05 jteo: using "every?" you mean?
13:10 cgrand: yes, every? is just a loop
13:11 jteo: ah.
22:54 Chouser: does #(filter identity %) deserve its own built-in name?
22:56 or maybe add an arity-one option to filter?