I think we are digressing. There are three separate questions: 1. Intent 2. Specification 3. Testing
Sometimes the intent is hard or impossible to specify formally, sometimes a specification is hard or impossible to test for. That doesn't necessarily invalidate such an intent or such a specification. Something you cannot test you might still be able to prove, for example. The whole point of having weak maps are space complexity consideration. So the name should be chosen accordingly IMO, regardless of whether we have a good solution to (2) and (3), which are really separate problems. But I'll leave it at that, nobody wants another longish bike-shedding discussion. On 16 September 2011 18:50, David Bruant <david.bru...@labri.fr> wrote: > Changing the subject to something more relavant. > > Le 16/09/2011 15:36, Andreas Rossberg a écrit : >> >> On 16 September 2011 15:17, David Bruant<david.bru...@labri.fr> wrote: >>>> >>>> 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. >> >> Obviously, I was talking about a server that is expected to get an >> unbounded number of messages during its uptime. >> >>> 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. >> >> The difference is, this limitation would be hit for the _normal_ use >> case of the server. If my program cannot deal with its expected use >> case, then it is incorrect. > > What is the definition of normal use? Size of input? When machines will be > powerful enough to handle your current normal case without tail call > optimization, will the definition of "normal use" change? > Once again, program correctness [1] (tell me if you use "incorrect" > differently and please define it if so) has nothing to do with > implementation considerations of the plaform that run your program. > There is no contradiction in having a correct program which fails when > implemented because of implementations issues (of the platform, not the > program). > > I do not think the ECMAScript standard is the the place where implementation > considerations should be addressed. For that matters, people have been > writing JavaScript programs for years and the spec doesn't say a word on > implementations. > > Also, why should tail call optimization should be standardized? There is a > use case, but aren't there other implementation optimizations that could be > considered? Should they all been standardized? Why this one in particular? > Really, once again, an appendix named "hints for implementors" or a > different document or a page on the wiki would be better than a normative > section. Saying that ECMAScript implementations aren't standard because they > do not support one programming style sounds like a lot. > > >>> 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). >> >> That is true, but whether some property can be observed from within >> the language itself, or only by its environment, is not relevant. > > It is not for people who write programs, it is for implementors because it > directly impacts their work. They are not implementing a language anymore > (which they still were as of ES5.1), but a language and some implementation > constraints. > Let imagine for a minute that tomorrow, implementors find another > implementation trick which allows to run without crash the use cases that > motivated the proper tail calls proposal, why would it be problematic? Why > does it have to be this optimization in particular? > > >> There is no test that you can reliably write for a 'print' function. >> Still you want to be able to rely on it printing what you gave it. > > I (if i was an implementor) would want to test my print function. I can > decide to do it from within the language or not since i have more power. You > can also test a function from outside a language (which is a more relevant > choice for a print function). > > >> Or consider a sleep(secs) function. How would you test it? > > Time cannot be formalized. The best we do is a human-acceptable > approximation of it. For what it's worth, I recommand reading the ES5.1 spec > for Date.now(). I think that test262 does a pretty good job of test coverage > for it. > > >>> "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. >> >> I think you implicitly do, all the time. Just try turning off GC and >> see whether your programs still work reliably. > > With or without GC, there are 2 possible behaviors for a program (assuming > conformant platform): > - it works reliably > - it crashes (not reliably most of the time) > GC isn't of any help regarding reliability. It is helpful to make my program > running reliably longer, that's all it does. If you disagree, please provide > an example proving me wrong. > > What I implicitely do is not relying on the GC, it's praying that the > implementation (and GC in particular) is good enough to make my program run > without crashing long enough. > That's what everyone does, I think. > Does this kind of prayers has a place in the spec? > > Same thing for tail calls. We write a program in some style praying that the > implementation will run it without crashing. Turns out, recursive tail calls > make implementations often crash. Is it a good reason enough to impose > something on the spec for that? > > Tell me if i'm wrong, but until today, all implementation decisions have > been made based on market considerations. JS is fast because of that. New > classes of program can be run now while they couldn't before (in the sense > that performance did not allow these programs to be efficient). See the > video at [2]. > I do not think it's the role of a language standard to have a word on > implementation considerations. If there is a need for tail call optimization > from the programmer side (to run some programs which use to fail without), > well, implementations will adapt. If there is no push with that regard, I do > not see why the spec should tell implementors what to do. > Also, there is a long history in JavaScript of implementations doing what > they want regardless of spec. There may not be a need of another such case. > > Spec driving features and market driving implementation choices sounds like > a good trade-off. > > David > > [1] http://en.wikipedia.org/wiki/Correctness_%28computer_science%29 > [2] http://blogs.intel.com/research/2011/09/pjs.php > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
