Le 16/09/2011 14:14, Andreas Rossberg a écrit :
On 16 September 2011 13:52, David Bruant<david.bru...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to