Tail call optimization in Javascript without trampoline

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
kangax wrote:
[snip "Garrett doesn't get it"]

You can say that, but it does not make Function decompilation any more
reliable.

And I did not say that.

No, you didn't. You tested the return value of

[snip]

No, actually I did.

OK, then you had a really lousy way to publish your results, as explained
in the part that you snipped here.

Here it is again: [...]

No, thanks. Learn to read.

Something that "can be used in eval" does not make that thing a
FunctionDeclaration.

Nobody said that it would.

Function serialization is defined as being "implementation-dependent".
Sounds unreliable. No?

Not if the missing identifier is the only thing that is wrong with it.

The most obvious cases of serializing built-in and user-defined function
fails to do what is specified in the most popular implementations.

But, as I have showed, that is not relevant here.

Sounds unreliable. Still not convinced?

Unreliable *for what*?

It fails to serialize user-defined functions as written, as shown in
examples by kangax, Richard, and myself, is unreliable.

Your and kangax's examples did not consider the use case. Richard
provided a result that considered the use case, but of an outdated
implementation. Your point being?

I fail to see the benefit in defending such unreliable strategy.
Furthermore, the reasons for wanting to do that are usually based on
inexperienced floundering and misguidance.

No, you simply don't get it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<snip>

I think that they fixed it with the first release of version 7.

IOW, an outdated, buggy implementation that nobody would ever use to
optimize their functions.

Still, it shows one of the pitfalls of declaring particular
things to be 'working' based on testing a set of examples;
[...]

JFTR: I did not do that; thank you very much for noticing.


PointedEars

 

[Thomas 'PointedEars' Lahn]

<snip>

My point is that

I was asking about Garrett's point, but I'll bite.

examples of things that have happened are examples of things that can
happen.

Undoubtedly, but not things that must happen. And things that, should they
happen, are easily spotted in this case: the optimized source code would not
be executable or if it was executable it would not work like the original
source code (unit testing would sort that out).


PointedEars

 

[Lasse Reichstein Nielsen]

You tested the return value of
Function.prototype.toString() when called on Function.prototype, a built-in
object, which you still don't seem to get.

So what if it's "built-in" (aka native)? Why do you even bring that up?

It's still a function (see ECMA262-3ed, section 15.3.3.1, then
15.3.4). It's toString function is the one specified in 15.3.4.2, and
it should return the syntax of a FunctionDeclaration. The
specification doesn't leave any room to wriggle.

/L

 

[Garrett Smith]

Is it?

Quite obviously. You are calling the method on the built-in protoype
object, not on a user-defined function.

And despite considerable hints you still manage

to miss the point. This is about the representation of *user-defined*
functions, not built-in ones.

[snip bogus results]
Present a correct test case first, then we might talk.

I don't see the problem with the test case.

Look closer.

No problem was observed. The only "problem" mentioned (and it missed my
point) was that the function object being serialized was not
user-defined. The point of my example was that the method "fails in the
most blatantly obvious way" that failing "provides very strong
indication that it is specified incorrectly".

[...]
That result is invalid because it is not a FunctionDeclaration.
Your test case is flawed, so whatever invented data you present as its
results here are irrelevant.

I did not invent that data; I ran the code and the result was produced.
I did not copy the whitespace separators correctly for Chrome result,
but that is so minor it seems hardly worth mentioning. At least to me.

Poor wording on my part. You test case is flawed as to the proof it is
supposed to provide by your own account; the results that you presented
are likely genuine, although rather useless.

The result shows that Chrome fails to return a FunctionDeclaration
representation.

The scope of the evaluated function would also be different in most
cases, too, and there may be problems associated with identifier
resolution.

 

[glathoud]

I find the point of view of Richard Cornford interesting.

Now, to expand a bit the discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=445363

So in at least one common environment, tail call optimization efforts
are underway,
in which case, one could eventually get rid of the decompilation trick
altogether.
To me, that's a pretty good motivation to experiment with tail calls
in JS.

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-3.html

Guillaume

 

[Thomas 'PointedEars' Lahn]

Garrett Smith wrote: [...]

It fails to serialize user-defined functions as written, as shown in
examples by kangax, Richard, and myself, is unreliable.

Your and kangax's examples did not consider the use case. Richard

Don't be ridiculous

Your failure to spot user-defined function in the post I linked to is
not my problem. So yes, the use case was considered (and demonstrated)
just fine. Thank you very much.

The use-case, stupid, is to write an application that converts the source
code of recursive user functions into source code of iterative user
functions. No broken (BlackBerry) or outdated (Safari < 2) implementation
matters there.


PointedEars

 

[Thomas 'PointedEars' Lahn]

So what if it's "built-in" (aka native)?

built-in != native

Why do you even bring that up?

You should read more carefully. *Garrett* brought it up, trying to use the
(rather foreseeable) results of direct calls to
Function.prototype.toString() as
a proof for kangax's statement that "function decompilation" could not
generally be recommended (and therefore the OP's approach was wrong), while
both have been ignoring that it does not make sense to call that method on
built-in or host objects in the first place.

It's still a function (see ECMA262-3ed, section 15.3.3.1, then
15.3.4).

It is "a Function object" in that "its [[Class]] is 'Function'" and that
it can be called ("that, when invoked, accepts any arguments and returns
undefined.") Nothing more, nothing less.

It's toString function is the one specified in 15.3.4.2, and
it should return the syntax of a FunctionDeclaration. The
specification doesn't leave any room to wriggle.

It looks to me like a yet unspotted Specification error (there is nothing
about this in the ES3 Errata, and I cannot find one for ES5), at least for
Edition 5, which claims to "codif[y] de facto interpretations of the
language specification that have become common among browser
implementations." Indeed, it does not make sense that the representation
of an anonymous function should be any other than that of an *anonymous*
function, which by definition excludes /FunctionDeclaration/.

Still, it does not make sense to call that method on a built-in or host
object, so regardless of any implementation issues, it matters little what
the return value is, even more if only user-defined functions are the
subject and the goal is to rerieve optimized source code. Surely you can
see that.


PointedEars

 

[glathoud]

Hey, the use case is "Tail call optimization in Javascript without
trampoline" (thread title).

ECMAScript 3 & 5 neither require the engine to do tail call
optimization (TCO), nor fully specify function decompilation, so one
has to compromise:
1. Write the function inside a string (!).
2. Or let the server or build system stringify tailopt()'s
parameters.
3. Or take the risk of function decompilation. A parser could spot
issues.

Who's not willing to compromise has to wait until all engines
implement TCO.

Cheers,

Guillaume

PS: whether the use case is stupid is yet another question. Ask people
who wrote compilers for other functional languages.