There has been some discussion of lazily computed expressions in the Numerical Clojure group:
https://groups.google.com/forum/?fromgroups=#!forum/numerical-clojure There, the interest is really in deferring execution of large matrix operations until and efficient execution strategy can be determined. The capability to do this kind of thing is being build into the core.matrix APIs at the moment, collaboration on this would be welcome. As a related point, if you are thinking of "spreadsheet" in the sense of a multi-dimensional grid, then you should definitely be looking at core.matrix anyway - it is shaping up to be the defacto standard for managing multi-dimensional array data structures in Clojure On Monday, 4 February 2013 14:06:27 UTC+8, dcj wrote: > > > John, > > Thanks for your email and the links, I'm interested in this topic and > wasn't aware of the previous work you referenced. > > I would't be surprised if the sentiments expressed by Stephen Compall in > this thread, specially > > my Clojure style seeks immutable solutions, and cells-ishs don't fit in > that category > > might be shared by many in the Clojure community. > Just something to keep in mind, and it is certainly possible that I'm > wrong about this. > > Important parts of the app I am currently working on definitely have a > need to "react to changes on dependent values" > Right now, unfortunately, I am attempting to manage the dependency graph > and the resulting > updates/propagations manually, which is tedious and prone to error. > I'm actively looking for a solution that would automate some or all of > this. > > I'm wondering if this kind of thing might work well in conjunction with > the "graph" library recently released by Prismatic, and there are > are similar work-alike libraries. > > One idea I am currently mulling over is "compiling" a computation > specified in the "graph" manner into a dynamically updatable > realization/implementation, somewhat similar to the way that Prismatic > compiles their graphs into maps , lazy maps, > or a map with each subcomputation spawned in parallel via futures. > > I'm definitely interested in talking/working with others with similar > interests/requirements…. > > Don > > On Feb 3, 2013, at 1:39 AM, john <john....@gmail.com <javascript:>> wrote: > > Hi, > the library > https://github.com/straszheimjeffrey/dataflow > and > http://richhickey.github.com/clojure-contrib/dataflow-api.html (1) > > or > https://github.com/gcv/dgraph > > seems to me very cool for systems that need to react on changes on > dependent values. I very much like the API in (1) > > Actually my personal opinion is that this is a very substantial thing in > business applications. > > Am I wrong but nobody seems to bother about them? > (I am not well clojure connected so this assumption is totally based on > git-update-dates / clojure-user-group discussions / planet.clojure.in > posts) > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
