On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of values.
There is something wrong with immutable cyclic data structures: an undefined
(or unexpected) behaviour on
On Apr 6, 8:09 am, Christophe Grand christo...@cgrand.net wrote:
Let say one can write:
(def john-doe {:name John Doe :email j...@doe.com :account {:owner
#cyclic reference to the root map :balance 1000}})
At this point the cyclic structure is a consistent value. As long as
updates create new
On 2010 Apr 6, at 9:09 AM, Christophe Grand wrote:
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips d...@mac.com wrote:
Immutability is orthogonal to reference-ness.
There is nothing wrong with having immutable cyclic graphs of
values.
There is something wrong with immutable cyclic data
The question of the OP was also a practical one : is either Clojure
or functional not a good match?
Honestly, I don't know the answer for sure, because:
* there is still no (widely known ?) utilities to manipulate things
easily. There were attemps like the one by Jeffrey Streizhem in
clojure
On Tue, Apr 6, 2010 at 3:41 PM, Sophie itsme...@hotmail.com wrote:
On Apr 6, 8:09 am, Christophe Grand christo...@cgrand.net wrote:
Let say one can write:
(def john-doe {:name John Doe :email j...@doe.com :account {:owner
#cyclic reference to the root map :balance 1000}})
At this point
On Tue, Apr 6, 2010 at 3:43 PM, Douglas Philips d...@mac.com wrote:
(def john-doe {:name John Doe :email j...@doe.com})
(def account {:identity john-doe :balance 100} )
(assoc john-doe :email john.doe at gee mail.com)
Now the account contains old/obsolete data and no cycles are needed to
On Tue, Apr 6, 2010 at 9:59 PM, Christophe Grand christo...@cgrand.net wrote:
Btw, to some extent, one can create cyclic data-structures in Clojure (only
lazyseqs though -- unless you implement your own map or use lazy-map etc.) :
user= (defn cyclic-seq [coll] (let [s (promise)] @(deliver s
On 2010 Apr 6, at 10:59 AM, Christophe Grand wrote:
The cycles are gone but the identity john-doe aand its curren-state
are still conflated so you get the same problem:
Thus, since simple trees have the exact same issues, circularity is
not the problem.
Really, to me the problem isn't
On Tue, Apr 6, 2010 at 10:43 PM, Douglas Philips d...@mac.com wrote:
On 2010 Apr 6, at 10:59 AM, Christophe Grand wrote:
The cycles are gone but the identity john-doe aand its curren-state are
still conflated so you get the same problem:
Thus, since simple trees have the exact same issues,
On Apr 6, 2010, at 9:01 AM, Laurent PETIT wrote:
* BUT : isn't the real problem that one will not content
[him/her]/self with playing with in-memory data ? One will want to
make the data persistent (outside-of-process, aka
storage-persistance). And with this kind of problem, one will have
I would really love to see (clearly by someone much smarter than I :)
an insightful summary of these kinds of concept-heavy discussions,
stickied or FAQd or even book'd somewhere.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group,
(deftype Account [owner balance])
(deftype Person [accounts])
joe has 1 account.
How to I create / initialize joe the account with mutual references?
I'd rather not use refs.
Thanks!
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
On Apr 5, 2010, at 2:09 AM, Sophie wrote:
(deftype Account [owner balance])
(deftype Person [accounts])
joe has 1 account.
How to I create / initialize joe the account with mutual references?
I'd rather not use refs.
You can't do it directly without one of the two being mutable. But
You need a level of indirection. One way is to make the backward
reference from accounts to owners be based on a non-pointer primary
key (maybe a keyword) that can be resolved through some table. This is
how it works in relational database systems
If you want to use references of some sort,
Is this a Clojure restriction, or is it intrinsic to functional
programming?
If my app is essentially about a user creating and editing a graph
structure (sometimes via crud-level interactions, other times by
somewhat larger refactorings), is either Clojure or functional not a
good match?
Thanks
On Apr 5, 2010, at 7:49 AM, Sophie wrote:
Is this a Clojure restriction, or is it intrinsic to functional
programming?
It's a consequence of immutable data structures, which are an aspect of
functional programming. An immutable object can never be changed, and you can't
create multiple
It's a consequence of immutable data structures, which are an aspect of
functional programming. An immutable object can never be changed
But single-assignment is a quite valid (and more flexible?) form of
immutability. I'm not convinced cycles are intrinsically tied to it in
any way.
(In
On Apr 5, 2010, at 4:34 PM, Sophie wrote:
But single-assignment is a quite valid (and more flexible?) form of
immutability. I'm not convinced cycles are intrinsically tied to it in
any way.
If you can assign to it, it's mutable. What you're talking about is creating a
mutable object, then
It's no more mutable than a pure lambda calculus with lazy evaluation.
There is no _observable_ mutability. Anything else is an
implementation detail.
Single assignment comes from the tradition of logic programming and
concurrent process calculus rather than lambda calculus. A single
assignment
19 matches
Mail list logo
