On Thu, May 31, 2012 at 2:27 AM, Andreas Rossberg <[email protected]>wrote:
> On 31 May 2012 00:31, David Herman <[email protected]> wrote: > > OK, but that begs the question. The problem is that your "might" test is > neither sound (as Allen pointed out) nor complete (as I pointed out) for > "can." What guarantee are you trying to provide? What do you mean by > "might?" > > +1 > > I think the function that some here seem to want is neither possible, > nor desirable. While this is impossible to answer for "the function that some here seem to want", since you're responding to Dave who is responding to me, I'll reiterate that the function I want is very possible. As I wrote previously it tests exactly for the following three cases: On Wed, May 30, 2012 at 3:20 PM, Mark S. Miller <[email protected]> wrote: > 1) bound functions > 2) fat arrow functions > 3) functions that neither mention "this" nor contain a direct eval > operator in their body. > I agree that distinguishing among these three cases would expose irrelevant implementation details. The above three categories are functions that *cannot* be this-sensitive. AFAICT, this is a hard guarantee. Thus, distinguishing between these three cases together vs all other functions is a semantic distinction. > Whether a function is looking at 'this' or not (or how > it was constructed that way, i.e. syntactically, or using 'bind') is > pretty much an implementation detail, and it should not be possible to > _sense_ it. A function is free to _document_ it as part of its > contract, though. For the code function f() { if (false) { return this; } } function g() { } The point of having rules that predictably say that f might be this-sensitive but g cannot be is so that the author of g can effectively "document" this fact, by having the predicate vouch that g is not this-sensitive, and its customers can know it is not lying. Of course f can document the same claim by conventional means, but it can't document it in a way that assures others it is not lying. Those who use the predicate's answer as their way of "reading" this documentation will only see g's claim, not f's. See http://www.erights.org/elang/kernel/auditors/ http://wiki.erights.org/wiki/Guard-based_auditing None of this should be surprising. We are all familiar with static type systems that will distinguish only between programs that might cause a type error and those that are guaranteed not to. We do not complain that a safe program might need to be revised before a type checker can vouch that it is safe. Likewise, the author of f would need to revise it if they wish the predicate to vouch that it is not this-sensitive. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
