Additional Math functions

C. Scott Ananian ecmascript at cscott.net
Wed Apr 29 17:50:59 UTC 2015


On Wed, Apr 29, 2015 at 12:56 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

> On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote:
> > I suppose it would be nice if JavaScript engines fell back to passing
> arguments on the heap to avoid this problem, but I don't think that's part
> of the ES6 spec.  Am I mistaken?
>
> that's an implementation detail. The ES spec. doesn't care whether or not
> you employee multiple argument passing strategies in your implementation.
> Personally, I wouldn't bother unless for some reason the implementation had
> a very small (<10?) stack based argument limit.
>
> Similar, anyone who who wants to spread a large array into an argument
> list is probably misguided.
>

I'm just saying: it's not safe to spread an arbitrary array into
`arguments` unless the spec explicitly says that the number of arguments is
limited only by heap size (not stack size) or something like that.  The ES6
spec does not contain any such language.

For tail calls, the spec says:

> A tail position call must either release any transient internal resources
> associated with the currently executing function execution context before
> invoking the target function or reuse those resources in support of the
> target function.
> NOTE For example, a tail position call should only grow an
> implementation’s activation record stack by the amount that the size of the
> target function’s activation record exceeds the size of the calling
> function’s activation record. If the target function’s activation record is
> smaller, then the total size of the stack should decrease.


I'm not sure exactly how you'd write equivalent language for "arbitrary
arguments size", something like a note on section 9.2.12
"FunctionDeclarationInstantiation" stating,
"An execution context should use resources only for named arguments of the
function.  Unnamed formals should not increase the size of the Environment
Record."
  --scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150429/2c0787fa/attachment.html>


More information about the es-discuss mailing list