On Wednesday, September 19, 2012 10:52:26 AM UTC+1, Patrik Sundberg wrote:
>
> On Tuesday, September 18, 2012 10:10:35 PM UTC+1, hutch wrote:
>>
>>
>> On 2012-09-16, at 3:21 PM, Patrik Sundberg <patrik....@gmail.com> wrote:
>>
>> I'm asking myself though if there's a more functional design for 
>> accomplishing the same goals? My main goals are to do things consistently 
>> so that changing a value X propagates properly, and being able to find 
>> dependencies of a given value. A DAG+identity map is my first take, but 
>> there may be something more natural for FP I'm completely missing.
>>
>>
>> Sounds like a reasonable approach to me. There's nothing wrong with 
>> state, just how you manipulate it. The STM in Clojure is really nice in 
>> this regard. You might want to have a look at Functional Reactive 
>> Programming (FRP). There's a lot of stuff available about that in the 
>> Haskell community, but usually for UIs and things like that. They sometimes 
>> use spread sheets as an example (spread sheets can be thought of as a DAG 
>> with values and computations in cells… you can see the mapping between them 
>> in your application (where the mapping doesn't work or is hard might be 
>> pointing at something quite interesting). There's also something called 
>> 'Cells' in Common Lisp that might be interesting. I'm not sure what's been 
>> done in Clojure.
>>
>>
> yeah, it's essentially a big mushy complex and persistable "spreadsheet" 
> I'm building, that's the right analogy that I tend to use myself (and 
> should have done in my post as well to make it easier to follow :)). Thanks 
> for the pointers, I'll go check those things out.
>
> btw, after started to play with it turns out records and protocols ends up 
> being the convenient way to do it, seems I don't need the flexibility of 
> multimethod dispatch + I do end up wanting some per type data to store.
>
>
Quick follow up to say thank you for putting me onto cells. That looks very 
much like the kind of solution I'm trying to create, so will study up on 
the various cells implementations for clojure that are around and 
embrace/adapt from there to suit my domain. 

If anyone happen to know the latest and greatest on which ones lived and 
which ones didn't that'd be great. I see a lot of posts in 2009 about cells 
with many implementations so would be grateful to be pointed in a good 
direction as of 2012 by the cells implementors.

Feature comments:
- Lazy evaluation a must
- Don't care so much about circular dependencies, I have good control over 
that and the domain is inherently hard to trip up in that way
- Parallel evaluation nice but not critical 

Thanks

-- 
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

Reply via email to