1:15 arbscht: partial and comp put the fun in functional
11:38 Chouser: If I have a nested structure of seqs and maps (a heirarchical database), is there a rule of thumb for what level to put the ref at?
11:39 rhickey: is there a known granularity of change? is there an external notion of identity?
11:39 Chouser: at the very top? farther down at like a "table" level? Are there speed or contention issues I should be thinking about?
11:43 rhickey: contention rather than speed should drive it, speed should be fine in any case
11:44 I would avoid field-level refs
11:44 Chouser: I've got a map of maps of sets to represent triples, and a second map of maps or sets to represent the inverse. That means that any change to one top-level map will require a change to the other.
11:44 right now I've got a ref for each of those top-level maps.
11:45 I was considering moving it up to the vector that holds that pair.
11:45 I'm not sure what you mean by external identity.
11:46 rhickey: outside of your app, there is a notion that a particular set of data can be identified by a key
11:47 if you are using triples, probably not an issue
11:47 Chouser: There are ids that might be stored outside and used later, but not references to a particular version of the database. Does that answer your question?
11:48 rhickey: more to do with object/record identity
11:49 if you are going to be heavily multithreaded with lots of updates, those top-level refs will be the bottleneck, if any
11:50 Chouser: ok, that makes sense.
11:50 And if I always update both at the same time, it won't help any to give each their own ref.
11:51 The only other place I could put a ref and not be at the record level, would be in the vals of the first map. ...which is an interesting thought.
11:52 rhickey: right, you could then update the attribute set for a particular key independently
11:53 Chouser: I can still sync across multiple, though, to get "atomic" transations.
11:53 rhickey: exactly, that's the beauty of STM
11:53 arbitrary change sets
11:53 no lock ordering
11:54 Chouser: So I would expect this to have thousands of refs. That shouldn't scare me?
11:55 rhickey: not at all
11:55 Chouser: great.
11:55 I still don't know how I'm going to sync this to disk, but that's a problem for another day...
12:04 oh, but I'll need a ref at the top levels too, since of course you can add keys there.
12:07 rhickey: right but you'll only need to use them when you add/remove keys
20:18 jmn3: hi
20:22 ive been noticing usages of nested [] for bindings. (it was in an fn, actually) Whats that all about? is that mentioned in the docs somewhere?
20:53 rhickey: It's destructuring - documented in the entry for let: http://
21:53 jmn3: ok thanks
21:54 does it say what destructuring is?
22:01 rhickey: I think so: "The basic idea is that a binding-form can be a data structure literal containing symbols that get bound to the respective parts of the init-expr"
22:12 jmn3: thats deep. gonna have to study that one. im in the midst of reading sicp.