david.bruant at labri.fr
Fri Sep 16 06:17:19 PDT 2011
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.
>> 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 , 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.
More information about the es-discuss