Re: THREADS:SYMBOL-VALUE

[Sam S. <sd...@gn...>]

Hi,

> * Vladimir Tzankov <igmnaxbi@tznvy.pbz> [2008-10-05 20:24:07 +0300]:
> On Oct 5, 2008, at 8:07 PM, Bruno Haible wrote:
>> Vladimir and Sam wrote:
>>>> (I added SYMBOL-GLOBAL-VALUE, SYMBOL-THREAD-VALUE
>>>
>>> I think a (THREADS:SYMBOL-VALUE symbol &optional (thread-local-p
>>> nil)) would be better.
>>
>> But maybe one of the two is the one that people will want to use 99%
>> of the times? That would probably be SYMBOL-THREAD-VALUE, I'd
>> say. When multiple threads are computing, none of them is interested
>> in the SYMBOL-GLOBAL-VALUE, normally, right?
>
> I think SYMBOL-GLOBAL-VALUE will be used more frequently - especially
> for sharing.  If symbol is bound in a thread - all calls to
> SYMBOL-VALUE from the thread itself - will return the per thread value
> cell (and if not bound - it is equivalent SYMBOL-GLOBAL-VALUE - the
> global value cell).  SYMBOL-THREAD-VALUE is more for debugging
> purposes - to inspect what's going on in (not current) thread (even
> terminated one).

So basically what we want to do is to extend SYMBOL-VALUE to accept an
&optional argument specifying the thread in which to look the value up
(NIL=GLOBAL, T=CURRENT).

>>> it is backwards-compatible with CL:SYMBOL-VALUE and thus can safely
>>> shadow it when desired.
>>
>> Hmm. When people do a (use-package "THREADS"), will they want to use
>> the global value or the value in the current thread?
>
> Basically people should use SYMBOL-VALUE and they will get either the
> global value (if not bound per thread) or the per thread binding.
> This is consistent with other CL implementations. These two functions
> should be used explicitly by the user when he knows exactly what he
> wants to obtain (not to set - btw: should it be setf-able).

So what you are saying is that my proposed extension to SYMBOL-VALUE is
not backwards-compatible.
This means that you need an entirely new function with two required
arguments:
(THREADS:SYMBOL-VALUE-THREAD symbol thread)
where thread can be NIL to mean global value, T to mean (CURRENT-THREAD)
or a thread object.
it should return 2 values: BINDING and BOUND-P (similar to GETHASH).
It should also be setf-able.

Offering 2 separate functions to do two similar things is, IMO,
counterproductive.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 8.04 (hardy)
http://ffii.org http://mideasttruth.com http://camera.org
http://dhimmi.com http://honestreporting.com http://jihadwatch.org
Live Lisp and prosper.