Poll: a nonstate keyword

[Fawzi Mohamed]

On 2008-06-01 08:44:59 +0200, "Janice Caron" <caron800 at googlemail.com> said:

> On 01/06/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>> If the library solution is efficient then and the use cases I identified
>> are covered then I see no need for the keyword (and keeping the language
>> simple and ensuring the the users understand the style of the language is
>> worth some effort).
> 
> So let's make a list of all of the use-cases that we can collectively
> think of. These are the ones I can come up with:
> 
> (1) caching
> (2) reference counting
> (3) intrusive linked lists (also intrusive binary tree nodes, etc).
> (4) "is associated with"
> 
> Any more?

I had written the cases I could come up with here
		http://www.wikiservice.at/d/wiki.cgi?TransitiveConst

>> If the compiler really gets more aggressive in ensuring that invariant is
>> constant then the only possible solution will be fully external (id_number
>> in the object
> 
> No need for that. The hashtable can be keyed on "this".

ok, using a size_t, so that the object is not kept around for it

>> +cleanup handle in destructor,
> 
> which would be transparent

but needs at least a mixin in the destructor, or there is some magic 
that I don't know yet?

>> and external hashtable
>> mutable_state[id_number]),
> 
> It wouldn't need to be external, it could be a static member variable.
> (I think it would have to be, if we want cleanup to be transparent).
> So you'd end up with something like

yes with external I meant not packed with the object.

> 
>     class A
>     {
>         mixin Cache!(int) x;
>     }
> 
>     const a = new A;
>     a.x = 3; // OK
> 
> 
>> it would be a pity to have to pay this extra
>> cost when most cases in which this is used are related to the need of being
>> more efficient.
> 
> If the calculation is faster than a hashtable lookup, then you
> shouldn't be caching anyway. If the calculation is slower than a
> hashtable lookup, then with a hashtable lookup, you still win.
> 
> I'm not so sure about the other use cases. That's why it's a good idea
> to make a list, and weigh up the pros and cons of each possible
> solution.

I agree that listing the use cases is a good idea, and what I have tried to do.
I think for example that in the case of lazy linked list the external 
hastable solution is probably too expensive, at leas twice as slow to 
traverse, and with at least twice the overhead in memory.
Indeed a linked list is often a poor choice, as it is 
oversequentializing and has a rather large overhead, but it is a choice 
that come up naturally when using the functional programming style.
Also for statistical information about calling pattern to a pure 
function one probably doesn't want to spend much time/space.
Memoization, well maybe you are right, that is unless you are in a 
tight loop, you probably don't care about the hastable lookup, but this 
happens in *every* call independently if the element is present or not, 
so things like caching just the last request with a simple pointer, if 
it is often repeated are probably not an option.

Fawzi