Strategies for standardizing mistakes

Jim Blandy jimb at
Wed Oct 14 16:40:28 PDT 2009

On 10/13/2009 04:05 PM, Mike Shaver wrote:
> On Tue, Oct 13, 2009 at 7:01 PM, David-Sarah Hopwood
> <david-sarah at>  wrote:
>> I agree with Maciej. The implementation-defined operations have clear
>> specifications of their parameters. I think that it is highly undesirable
>> to adopt an interpretation in which they can have arbitrary additional
>> inputs depending on the context in which they are used.
> If they didn't depend on the context in which they are used, they
> wouldn't need to be host objects, right?  The whole point of the host
> object is that it knows things about the host (what mode it was loaded
> in, what privileges the context offers, what the user's preferences
> are) which aren't within the scope of the language proper.
I think David-Sarah may have overstated his case when he used the phrase 
"arbitrary additional inputs depending on the context in which they are 
used".  Of course host objects interact with the host environment, and 
have access to various kinds of state like privileges and preferences.

There's one specific kind of contextual information that's being looked 
at askance here: knowledge of the expression surrounding the call that 
invoked you.  Perl lets subroutines check what sort of value their 
caller is expecting; that hasn't aged well.

It seems to me that ES5 is not capable of forbidding such behavior.  ES5 
can't forbid implementations from providing JS debugging APIs, nor 
forbid such APIs from providing functions that inspect a call, nor 
forbid host objects from using such a function.

More information about the es-discuss mailing list