{Weak|}{Map|Set}

[David Bruant]

Le 16/09/2011 14:14, Andreas Rossberg a écrit :
> On 16 September 2011 13:52, David Bruant<david.bruant at labri.fr>  wrote:
>> Furthermore, let imagine for a minute that i need an ECMAScript
>> implementation for programs i write which i know (for some reason) all are
>> short live and use a maximum finite amount of memory i know. Based on this
>> knowledge (i admit this to be weird to have this knowledge), i could decide
>> to not implement a garbage collector. My programs are short-live and use few
>> memory, i may not need to care about the memory.
>>
>> In this imagniary ECMAScript environment without Garbage Collection, why
>> would i care of references to be weak or strong? I don't, i write programs.
> Right, but why would you care about WeakMap either? The canonical Map
> is perfectly fine for that situation.
True.


>> Also, the notion of garbage collection is a separate concern from
>> programming. It comes from the necessity of being careful of resources.
> Well yes, but that's part of programming. In practice, all resources
> are finite. And the difference between finite and infinite space usage
> is a correctness criterium.
>
> Consider writing a server. If I cannot rely on tail call optimization
> then writing its message loop as a recursive function (e.g. actors
> style) would be incorrect. If I cannot rely on GC, then allocating an
> object for each received message would be incorrect. If I cannot rely
> on weak maps, then, say, mapping every message object to a return IP
> would be incorrect.
You are making a connection between program correctness and 
implementation consideration of what you use to write these programs. It 
doesn't sound right.

"If I cannot rely on tail call optimization then writing its message 
loop as a recursive function (e.g. actors style) would be incorrect."
=> This is not true. If your server ever receives only one message, you 
should be fine. The problem is in implementation limitation, not 
correctness of your program. It turns out your programming style with 
nowadays reasonable use cases (size of input, number of messages...) 
makes current implementations fail. I agree that it is annoying, but it 
doesn't make your program incorrect.
If we start considering implementation limitations as sources of program 
incorrectness, then some ECMAScript programs will always be incorrect.

Regarding tail call optimization, as far as I'm concerned, an agreement 
between implementors sounds like a more reasonable approach. There is no 
way in the language to test this feature. In this video [1], David 
Herman explains that a test can be written (at 40:40), but the test 
relies on implementation limitations rather than the language by itself 
(unlike all tests that can currently be found on test262).


"If I cannot rely on GC, then allocating an object for each received 
message would be incorrect."
=> Can you refine this point? I don't understand the connection between 
garbage collection and correctness of your program.
I allocate objects on a daily basis and have never /relied/ on garbage 
collection. Don't get me wrong, I'm glad it exists, I'm glad i can write 
long-running program because garbage collection recycles memory, but i 
can still write programs that can run out of memory. The language allows it.
With regard to memory management, GC is a convinience and allows me to 
write program which can live longer without running out of memory in a 
minute. It is in no way something that can be relied on for program 
correctness, (unless i am missing something?)
Same goes for tail call optimization.

David

[1] http://www.youtube.com/watch?v=hs6tF-RDX4U