> I felt the same way at first. I think it would help if the group
> shared some common, non-mathematical cases, where laziness is helpful.
I've been using multiple resultset-seq to collect together matching
data from different databases and stream it on through some existing
Java code. It is fa
In August, I was also struggling with laziness. As I went along my
learning curve,
I realized that much of this fog in my mind came up because I was still
taking mutability of data and side effects as "normal" by habit.
I had not "spliced" my thoughts while toggling between Java and Clojure,
someth
On Mar 2, 3:29 am, Mark Volkmann wrote:
> On Sun, Mar 1, 2009 at 11:06 PM, max3000 wrote:
>
> > Hi,
>
> > I find the laziness in clojure very hard to wrap my head around. I
> > understand the idea and it's probably nice in theory. However, in real
> > life it doesn't seem really useful beyond ha
On Sun, Mar 1, 2009 at 11:06 PM, max3000 wrote:
>
> Hi,
>
> I find the laziness in clojure very hard to wrap my head around. I
> understand the idea and it's probably nice in theory. However, in real
> life it doesn't seem really useful beyond hardcore mathematical
> problems.
I felt the same wa
Hi,
Am 02.03.2009 um 06:06 schrieb max3000:
Here is the code that gave me trouble:
(map #(add-watch % watcher callback-fn) all-agents)
This was not executing. I had to change it to the below expression:
(doseq [agent all-labor-agents]
(add-watch agent total-labor-agent callback-fn
Laziness is the bomb. Don't give up on it. ;-)
On Mar 2, 8:12 am, max3000 wrote:
> Thanks for the pointers. I was indeed able to make it work with
> dorun. ;)
>
> Still, I'm not sure I understand what all the fuss is about regarding
> laziness. I'll take your word for it for now but I hope to gr
Laziness hit home for me in Clojure when I noticed that one of our Java
library functions, looking for a Collection, had happily accepted a Clojure
(map ...) object which was going to expand a small set of integers into much
larger objects. Because Clojure deferred the work, they were only generate
Quite a frequent occurrence, welcome to the club!
One simple check that the Clojure compiler could make is to produce a
warning if any lazy result is discarded. I think that would catch 90%
of the problems and give the user an immediate clue what to
investigate. Well it sounds simple, but I have
Hello,
The way I think about it is "am I in a portion of code that does "pure
functional stuff", or am I doing side effects ?
A "pure functional stuff" resembles a computation, but not the storage part,
or the part that gets the stuff from the outside (that is, no input / output
stuff).
"doing si
Thanks for the pointers. I was indeed able to make it work with
dorun. ;)
Still, I'm not sure I understand what all the fuss is about regarding
laziness. I'll take your word for it for now but I hope to grock it
eventually.
Thanks!
Max
On Mar 2, 12:30 am, David Nolen wrote:
> Remember that y
Remember that you can force lazy sequences if you need to as you are with
doseq with doall (retains head) and dorun (does not) as well.
You probably want
(dorun (map #(add-watch % watcher callback-fn) all-agents))
I think it's pretty clear here what's going on. Your code needs
side-effects. In C
doseq is the idiomatic way to write imperative code segments like this
(add-watch generates a side-effect). Nevertheless, I too love using
map for stuff like that. All you need to do is surround the map with
dorun (or doall if you need the return value) and it will force the
computation.
see: (do
Hi,
I find the laziness in clojure very hard to wrap my head around. I
understand the idea and it's probably nice in theory. However, in real
life it doesn't seem really useful beyond hardcore mathematical
problems.
Case in point, I just spent 2 hours debugging a piece of code (shown
below) that
13 matches
Mail list logo