[Edu-sig] Properties use case

[Grégoire Dooms]

Arthur wrote:
>  
>
>   
>>> -----Original Message-----
>>> From: Laura Creighton [mailto:lac at strakt.com] 
>>>       
>  
>   
>>> And I think he will like tens of thousands of threads, too, 
>>> though if these just means tens of thousands of chances to 
>>> modify only part of your complex number, when you wanted an 
>>> atomic action guaranteed to modify both parts as one, then 
>>> he may hate it before he likes it. :-)
>>>       
>
> Sorry  - I suspect everyone else is quite done with this, but I'm still
> bothered by mixed signals.
>
> I would like to be able to present PyGeo as good, sensible code.  Not Museum
> Quality, to be sure. But good and responsible.
>
> There is an implication in what you are saying that I am still off the mark.
> Perhaps I am.  But its not fair, in my mind, to throw that at me knowing
> that it still has not gotten through to me (and Zelle ?) in what way I am
> off the mark.
>
> For the life of me I don't see the problem.  My class has 2 __slots__ -
> .real and .imag. It does with them the kind of things that classes do.  
>
> How is this class different and less thread safe than an infinite number of
> other classes that do with attributes the kinds of things that classes do
> with attributes?
>   
This is a complex matter and I'll try to give a very short (hence a 
little categoric) answer.
First of all, IMO Laura was referring to several thousands of 
lightweight thread such as those found in the Oz/Mozart language 
(http://www.mozart-oz.org). And that is because we have had a PyPy/Oz 
sprint two weeks ago where we made plans and prototypes for the 
integration of some ideas of Mozart into PyPy (mostly logic variables, 
"search", and constraint programming, micro-threads were already on the go).

In that language stateful datatypes such as mutable objects are an 
exception.
By default the variable store is a single assignment  store. That means 
when you create a variable (e.g. with this statement  X=_ ) it is 
uninitialized (called unbound). Then when you assign it you cannot 
rebind it to an other value: X=4 works but if you do X=5 later you get a 
sort of exception (failure). In a sense = does not do assignment but 
true mathematical equality (called unification). So you can do 4=X as 
well as 1+X = 5.
The language supports very lightweight threads (having a million of 
those is no problem), when they try to "use" the value of a variable , 
they block if the variable is unbound.  So you can launch 
inter-dependant threads accessing values computed by each others without 
wondering about the synchronization. That is called dataflow concurrency.

In a sense, your mutable complex object is opposite to that approach 
where (almost) all variables never ever change their value.
> I have unintentionally stimulated a CS  nerve, apparently.  But would still
> love to get to the bottom of issue.
>   
HTH :-)
> Or get an official CS - proper use case aside - bill of health.
>   
I would refer you to the CTM book: 
http://www2.info.ucl.ac.be/people/PVR/book.html
You will find there lots of interresting ideas about computer language 
semantics.


Best,
--
Grégoire Dooms