On Jan 19, 2008, at 12:31 AM, Peter Michaux wrote: > It seems like having types in ES4 is adding quite a bit of difficulty > to when a proper tail call can occur. The Scheme folks don't have to > deal with that, I suppose.
Contract systems in Scheme may use space, so this is a problem that has been studied. ES4 has no user-defined implicit conversions, but the built-in ones could require stack space so that's the hazard, as I understand things. The C syntax makes it harder to see tail positions compared to Scheme, so types are not the only issue. Really, the question is a human factors one. > I think implicit tail calls are one of the most exciting proposals for > ES4. Can it be implicit with the option of making it explicit so that > it throws an error if the call is not in tail position and will > produce the explosive stack growth? This would have the same feel that > the language is "unsafe" but has optional "safety" features like > optional types. ES3 doesn't have any mandatory safety syntax and to me > it would be best to keep all safety syntax optional. This is an interesting way of looking at it, and indeed jaz (Jon Zeppieri) in comments 23 and 25 in http://bugs.ecmascript.org/ticket/323 brought up the idea of an assertion "I want a PTC here:" that could be attached to a call, with implicit proper tail calls. I should have represented this as an option; thanks for bringing it to light on the list. Call it I,X (Implicit, eXpression tail calls) + A (Assert-PTC- here). Even with the explicit syntax for guaranteed PTCs, most of us can't see ruling out as non-conforming an implementation that uses PTC implicitly too. Given that allowance for further PTC without explicit "opt-in" syntax, the assertion jaz proposed makes a lot of sense. My concern that people won't know to use it is weak. Either lack of it will burn people and they'll learn of it and use it, or it won't be needed anyway. Sort of like optional type annotations, as you note. The important point is that leaving out such an assertion, with explicit or implicit PTC (where the explicit case still allows further PTC to be done implicitly), enters the programmer in a guessing game. I,X (no way to assert PTC here or error) I,X+A (original wiki'd proposal + Jon Zeppieri's assertion idea) E,X (+A anyway in case of further PTC at implementation's discretion?) E,S (+A for the same reason?) Looking at it this way, there's a case for A. And given A plus implementation freedom to optimize more PTC than required by the spec, is E really necessary? /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss