2010/4/7 Michael Gardner :
> 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
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 g
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 ha
On Tue, Apr 6, 2010 at 10:43 PM, Douglas Philips 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, circu
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 cre
On Tue, Apr 6, 2010 at 9:59 PM, Christophe Grand 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 (lazy-cat coll
> @s))
On Tue, Apr 6, 2010 at 3:43 PM, Douglas Philips 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 3:41 PM, Sophie wrote:
> On Apr 6, 8:09 am, Christophe Grand wrote:
> >
> > Let say one can write:
> > (def john-doe {:name "John Doe" :email "j...@doe.com" :account {:owner
> > # :balance 1000}})
>
> At this point the cyclic structure is a consistent value.
True.
>
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 2010 Apr 6, at 9:09 AM, Christophe Grand wrote:
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips 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
On Apr 6, 8:09 am, Christophe Grand wrote:
>
> Let say one can write:
> (def john-doe {:name "John Doe" :email "j...@doe.com" :account {:owner
> # :balance 1000}})
At this point the cyclic structure is a consistent value. As long as
updates create new values that match the domain invariants, why
On Mon, Apr 5, 2010 at 4:54 PM, Douglas Philips 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 update beca
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 va
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 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 fa
On 2010 Apr 5, at 10:29 AM, Per Vognsen wrote:
In languages like Python and Smalltalk that conflate value and
identity, you need nasty tricks like abusing the garbage collector's
object graph traverser to find all references to a given object (e.g.
gc.get_referrers() in Python) and then rewire th
Because of identity-value indirection, there's nothing to it:
(defn swap-refs! [r1 r2]
(let [x @r1]
(ref-set r1 @r2)
(ref-set r2 x)))
In languages like Python and Smalltalk that conflate value and
identity, you need nasty tricks like abusing the garbage collector's
object graph traverse
On 2010 Apr 5, at 9:43 AM, Per Vognsen wrote:
I already mentioned this in my original response, but it's worth
reiterating that the situation is very much like a relational database
system. In a relational database there are no direct pointers, only
primary keys. A primary key is nothing more tha
On Mon, Apr 5, 2010 at 8:24 PM, Michael Gardner wrote:
> 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 immutabl
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 obje
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
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, mutabi
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.
(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
24 matches
Mail list logo
