Thanks, that really helps clarify things. So is the new tree saved when it
is created (i.e., when the old tree is "updated"), or do you have to "write
it back" at some point? In other words, as a user of aatree, do I obtain a
new tree and then tell aatree "Here is a new tree. Please (incrementally)
save it." Or does the mere fact that I have a new tree mean that it has
already been saved?
As for terminology, I wouldn't worry too much about using the word "update"
when talking about immutable datastructures. Most functional programmers
understand the term "update" to mean "make a 'copy' of something, with some
part of it changed in some way" in such contexts. I think what was
confusing is that (a) the Readme didn't explicitly say aatrees were
immutable (from a value perspective) and (b) there aren't any examples on
using the library. I think adding a few examples (with perhaps a little
explanation of what is happening under the covers) would go a long way.
Nathan Davis
On Thursday, October 1, 2015 at 4:22:48 PM UTC-5, William la Forge wrote:
>
> Sorry for my bad language. I've not written much about immutable
> structures before so old phraseology keeps coming in inappropriately.
>
> The structures are immutable. A change results in a new tree with only the
> nodes which are changed (and their parent nodes) replaced. But the key
> property here is that deserialization and serialization operations which
> are performed on these trees are done in place, without making any new
> nodes--thanks to the magic of atoms. So for example, if several threads are
> accessing the same tree instance, they all share the deserialized values
> while any changes to the tree contents results in new tree instances. I.E.
> It is done right, to the best of my ability. (Extra eyeballs on the code
> always being appreciated, of course!)
>
> Now I'm sorry for having been so terse and ambiguous. I need practice
> talking about this stuff. So your questions are appreciated twice over! :-)
>
>
> On Thursday, October 1, 2015 at 4:41:33 PM UTC-4, Nathan Davis wrote:
>>
>>
>>
>> On Thursday, October 1, 2015 at 2:58:15 PM UTC-5, William la Forge wrote:
>>>
>>> A value can have more than one form or implementation. For example, a
>>> String and a char array may both represent the same value. Most objects,
>>> for example, can be serialized. Changing the form of a value then is not a
>>> change of value. This is the idea behind lazy deserialization /
>>> reserialization.
>>>
>>>
>>> We can represent a data structure as a tree, where the values in the
>>> tree can be either the immutable value of the object or a read-only
>>> ByteBuffer holding the serialized form of the value, or both. Both forms
>>> can be held by nodes using atoms, so the form of the values can be changed
>>> without having to create a new tree. The value remains unchanged and the
>>> tree can be safely shared between threads.
>>>
>>
>> I think we are on the same page to this point.
>>
>>
>>> Lazy deserialization comes after loading a map or vector from a
>>> ByteBuffer. Initially only the root exists, which holds only the
>>> ByteBuffer. As you access and alter the contents of the map or vector, the
>>> portions of the tree which are accessed are deserialized.
>>>
>>
>> This is where I get confused. Are aatrees persistent structures (in the
>> functional programming sense, like Clojure's data structures) whose values
>> cannot be changed (although their internal representation ("form") may
>> change), or are they mutable? If they are persistent, what do you mean by
>> "alter the contents"?
>>
>> Nathan Davis
>>
>
--
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/d/optout.
