Does ES5 forbid implementing builtin functions using ES??

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Wed Jul 15 08:59:34 PDT 2009


So this all loops back to my original point which was this requirement on built-in functions is both unnecessary and in fact is not observed by various implementations. This obviously isn't a big issue but using the text I have already written would be a simple house cleaning change to match reality and eliminate this as a "purity issue".

Allen

>-----Original Message-----
>From: Brendan Eich [mailto:brendan at mozilla.org]
>Sent: Tuesday, July 14, 2009 11:24 PM
>To: Christian Plesner Hansen
>Cc: Allen Wirfs-Brock; Mark S. Miller; es5-discuss at mozilla.org
>Subject: Re: Does ES5 forbid implementing builtin functions using ES??
>
>On Jul 14, 2009, at 10:43 PM, Christian Plesner Hansen wrote:
>
>>> So if you (hypothetically) decided that it was opportune for your
>>> implementation to use JavaScript to implement some of the built-ins
>>> in you wouldn't mind that your implementation was identified as
>>> being "non-conformant"
>>
>> Exactly.  V8 implements most built-ins as JS functions and is indeed
>> incompatible because of it.  We use an extended JS dialect to define
>> built-ins but decided that having a special construct for defining
>> built-ins without prototype/[[construct]] was not worth the complexity
>> and effort.
>
>SpiderMonkey *still* (and since 1996, like the original Netscape 2
>implementation) gives built-in functions [[Construct]] and .prototype
>(https://bugzilla.mozilla.org/show_bug.cgi?id=445319
>  and its dependent bug). This is far from a burning issue, but it
>will probably get fixed soon.
>
>Adding new syntax to mean "function that can't be called as a
>constructor" seems fruitless, apart from following the spec purity
>points. A special form for constructors would have been the way to go
>originally (I said so at ICFP 2005 when asked by Simon Peyton-Jones
>about what I left out), but retrofitting a special form for function-
>that-can't-construct seems like it must entail either new modality
>(stricter strict mode) or more verbose syntax (e.g., |builtin function
>parseInt(...) {...}|, which is self-defeating).
>
>Lambda would have been |this|-free and not callable via new, but we've
>mostly (hi, DSH) agreed that lambda with its fierce Tennent's
>Correspondence Principle purity doesn't pay its way.
>
>/be



More information about the es5-discuss mailing list