Anton van Straaten wrote:
In functional languages, proper tail calls are something that just
happen automatically (to varying degrees depending on the language), and
programmers don't need to think about them most of the time, if at all.
Because of the language semantics, not the implicit
Chris Pine wrote:
Anton van Straaten wrote:
In functional languages, proper tail calls are something that just
happen automatically (to varying degrees depending on the language), and
programmers don't need to think about them most of the time, if at all.
Because of the language semantics
Anton van Straaten wrote:
If an annotation is required to achieve proper tail calls, it means
that you have to be aware of when you're relying on a tail call, and
remember to use the annotation, or you'll have runtime problems when
you implicitly rely on tail call behavior that's
Chris Pine wrote:
Ahhh, I see. Maybe that part wasn't communicated on-list, but was
discussed in the trac ticket (or in the phone meeting? can't remember).
I'm just an observer, and have only seen the one ticket (#323) and the
discussion here. The ticket proposes a required annotation to
not exist. As a programmer, I don't
want to need to keep track of whether which implementations support my
programming style. Do we really want ES4 and Stackless ES4 (for
example)?
Peter Michaux put it nicely when he said:
If there are no requirements for proper tail calls then they cannot
On Thu, 2008-01-24 at 16:09 -0800, Peter Michaux wrote:
For this list, reply doesn't default to the list.
Mailman (which Mozilla uses) allows the following which works quite
nicely (although it's a highly religious topic in some circles):
reply_goes_to_list = 1 # 1 = This list
--
Nathan de
. As a programmer, I don't
want to need to keep track of whether which implementations support my
programming style. Do we really want ES4 and Stackless ES4 (for
example)?
I believe that is the situation now with ES3 and that an ES3
implementation can use proper tail calls if it wishes
On 1/24/08, Lars T Hansen [EMAIL PROTECTED] wrote:
Either the spec will mandate proper tail calls in a set of clearly
defined situations, or it will not mention them at all. The set
should be ambitiously large, but it also needs to be describable.
Anyhow, an implementation will always
Yes, but there have been hot flame wars (probably still burning)
about the advisability of setting reply-to-list. I'm not in favor
myself. Is this a big problem, or only a sporadic nuisance (possibly
much less of a problem than the reverse: private replies
inadvertently going to the list).
On Thu, 2008-01-24 at 16:48 -0800, Brendan Eich wrote:
Is this a big problem, or only a sporadic nuisance...
The latter.
--
Nathan de Vries
smime.p7s
Description: S/MIME cryptographic signature
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
On 23/01/2008, Lars Hansen [EMAIL PROTECTED] wrote:
Ditto, interprocedural analysis and/or inlining
may prove that the body of a try can't throw an exception, thereby
allowing the exception handler to be removed, thereby exposing a
possibility for TCO. And so on.
This nicely shows the
Neil,
I understand your points. But I wouldn't want to defeat an important
feature simply because novices wouldn't understand how to use it.
Especially in this case, where it should be possible for the feature to
coexist with novices without them tripping over it.
People's primary concern
;-)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Mix
Sent: Tuesday, January 22, 2008 7:46 AM
To: Brendan Eich
Cc: Peter Hall; Dave Herman; es4-discuss@mozilla.org; Jeff
Dyer; Erik Arvidsson
Subject: Re: proper tail calls
Thanks. That would
On Jan 22, 2008, at 7:45 AM, Neil Mix wrote:
Thanks. That would work. But I can still see the average user
being
confused when debugging, and not knowing what is going on.
Would you think an explicit keyword syntax for mandatory tail call
would help such a user?
I do.
Others argue that
On Jan 22, 2008, at 11:03 AM, Neil Mix wrote:
I also want to make clear: this isn't about debugging code that uses
PTC intentionally -- that tradeoff is up to the developer. This is
about the novice coder who finds a stack trace on a production system
from code that he doesn't own which just
Arvidsson
Subject: Re: proper tail calls
Not sure if this was clear, but I'm not arguing against PTC
altogether, just *implicit* PTC. I have no qualms about
explicit PTC. (I'm even fairly sympathetic to arguments for
implicit PTC, I'm just worried -- based on Brendan's
statements
On Jan 22, 2008, at 11:03 AM, Neil Mix wrote:
I also want to make clear: this isn't about debugging code that uses
PTC intentionally -- that tradeoff is up to the developer. This is
about the novice coder who finds a stack trace on a production system
from code that he doesn't own which
But why won't we feel it, as trace-readers, just as much when the
PTCs were explicit? This, I don't follow. The programmer and the
debugger-driver are often very different people, in general skills,
familiarity with the source at hand, etc.
We will, but the point is: you (or someone you
Its probably important to go back to Brendan's point about this
being a
feature and not an optimization. Even in Java the stack traces
you get
are very distantly related to the actual code running when all the
inlining, escape analysis, and traditional optimizations are applied.
They
Others argue that this syntactic penalty box means no one will use
PTC; the cursed view of tail calls and recursion will not fade away.
Interesting -- I'd love to know more about why that is. Dave
Herman's example in the ticket isn't so bad once the annotation is
placed on the function
On Jan 22, 2008, at 11:27 AM, Thomas Reilly wrote:
Depends on what you mean by meaningful stack trace. Do you actually
want to see the same function name repeated N times for each
invocation?
I would think not, I would just come up with some notation to decorate
the stack trace.
Tail
One issue with requiring the explicit syntax is that the requirement
isn't worth anything as a restriction. The compiler will have to
figure out whether a phrase could be a tail call to find out if the
ditto phrase using explicit syntax is a legal tail call. It is but a
short step from that to
On Jan 22, 2008, at 12:14 PM, Lars T Hansen wrote:
Ergo some implementations will have this
improvement; users will start depending on it; other implementations
will follow; and the explicit syntax is useful *only* as an assert
that the tail call can in fact take place, and will be useful
on the function call. If this is such a highly desired
feature, how is it that it will be shunned if given a light syntactic
overhead?
In functional languages, proper tail calls are something that just
happen automatically (to varying degrees depending on the language), and
programmers
On 1/22/08, Steven Johnson [EMAIL PROTECTED] wrote:
On 1/22/08 12:14 PM, Lars T Hansen [EMAIL PROTECTED] wrote:
IMO, the best design is that (a) a call that is syntatically in tail
position is executed as a tail call when that is possible, but as a
non-tail call when type conversions or
If there is no guarantee then the implicit proper tail calls feature
is useless to someone writing code for a variety of implementations
(eg web browsers.) If there are implicit proper tail calls then I need
to know when I can count on them and I will only use them in those
situations listed
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Herman
Sent: 21. januar 2008 16:58
To: Peter Hall
Cc: Brendan Eich; es4-discuss@mozilla.org; Jeff Dyer; Erik Arvidsson
Subject: Re: proper tail calls
I am a bit out of my depth
On 21/01/2008, Erik Arvidsson [EMAIL PROTECTED] wrote:
My concern with E (or A for that matter) is that it requires
additional syntax. I'd prefer if we could keep the syntax small.
The explicit syntax has one extra flow. Since the type checker is
optional, even with explicit syntax the program
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
let f2;
function f(a)
{
f2 = function() { return a; }
goto return g();
}
function g() {f2 = null; ... }
Here in f return g() is in tail position yet the frame of f can not
be eliminated completely since it is referenced through
I think talking about stacks and stack overflows might be muddying
this discussion. The language is a garbage-collected language and a
function context (stack frame) should be subject to garbage collection
just like any other object. A stack frame that is no longer
'reachable' (because
Igor Bukanov wrote:
I am saying that even for calls in the tail position an implementation
may not eliminate the parent frame completely as it still may be
exposed via closures. As such the tail call optimization cannot
guarantee that the space complexity of the tail recursion is O(1).
This
On 21/01/2008, Graydon Hoare [EMAIL PROTECTED] wrote:
Igor Bukanov wrote:
I am saying that even for calls in the tail position an implementation
may not eliminate the parent frame completely as it still may be
exposed via closures. As such the tail call optimization cannot
guarantee that
Peter Michaux wrote:
I've been trying to find out how [proper tail calls] are not an
optimization. I haven't read anyone else that thinks they are not an
optimization but I have read other people refer to them as an
optimization. I think that from an application programmers point of
view
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
Consider another example:
function f(a) {
function f2 { return a * 2; }
if (a == 0) return 0;
goto return f(a - 1);
}
f(1 20);
One may expect that this would require O(1) space. But this is not the
case as the implementation
On 21/01/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
Consider another example:
function f(a) {
function f2 { return a * 2; }
if (a == 0) return 0;
goto return f(a - 1);
}
f(1 20);
One may expect that this would
On 21/01/2008, Igor Bukanov [EMAIL PROTECTED] wrote:
On 21/01/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
But the above example *does* only require O(1) space. On each call to
f, a new closure is constructed, but it's dropped on the floor as soon
as the next iteration occurs.
You can not
certainly going to run on multiple ES4 implementations. If
there are no requirements for proper tail calls then they cannot be
depended upon and are useless.
As long as all the implementations have the exact same call stack
limitation then that holds true. However, I think it is unreasonable
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
You can not deduce that from ES4 specs that it does not require that f
should be ever dropped.
f has nothing to do with it. f2 is the closure that is constructed on
each iteration (assuming it is not optimized away in the specific
example you
On 21/01/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
Yes, I am assuming that ES4 mandates that unreachable objects do not
consume space. That doesn't seem like a terribly bold assumption to
me.
ES4 does not guarantee that. Moreover, in most current implementations
of ES3 the unreachable
On 1/21/08, Igor Bukanov [EMAIL PROTECTED] wrote:
ES4 does not guarantee that. Moreover, in most current implementations
of ES3 the unreachable objects do consume space until GC collects
them, but with a conservative GC even that can not be relied upon.
The until GC collects them part does
On Jan 21, 2008, at 1:11 PM, Jeff Dyer wrote:
On 1/21/08 12:35 PM, Brendan Eich wrote:
So the axes of disagreement seem to me to be:
We need to agree on the primary purpose of proper tail calls. I say
it is
portability of code, and that all other concerns do not have enough
weight
The argument (which I do not think is decisive) is that PTC breaks
debugability.
I am a bit out of my depth in this discussion, but explicit syntax
feels wrong to me. However, if it's going to be implicit, it has to be
completely invisible (aside from the benefits) - developers are going
to
On 2008-01-21, at 18:13, Peter Hall wrote:
The argument (which I do not think is decisive) is that PTC breaks
debugability.
I am a bit out of my depth in this discussion, but explicit syntax
feels wrong to me. However, if it's going to be implicit, it has to
be completely invisible
, the allocation doesn't prevent the
calls in tail position from being proper tail calls.
Really, all of our back-and-forth since those messages has been pretty
much off topic.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo
On 1/21/08 2:14 PM, Brendan Eich wrote:
On Jan 21, 2008, at 1:11 PM, Jeff Dyer wrote:
On 1/21/08 12:35 PM, Brendan Eich wrote:
So the axes of disagreement seem to me to be:
We need to agree on the primary purpose of proper tail calls. I say
it is
portability of code, and that all
On 22/01/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
Really, all of our back-and-forth since those messages has been pretty
much off topic.
To bring this back to the topic. I do not think an explicit syntax for
tail calls is useful for the following reasons:
1. It does not guarantee at the
I am a bit out of my depth in this discussion, but explicit syntax
feels wrong to me. However, if it's going to be implicit, it has to be
completely invisible (aside from the benefits) - developers are going
to want their debugging tools to work as before.
Is there a practical approach to
Tail calls do not have to be self recursive. Only a stack could
maintain the necessary state...
Ah yes, I see that now. Duh.
You can easily circumvent an expression being in tail position. For
example, if EXP is in tail position and you want it not to be, just wrap
it as:
let (r =
On Jan 18, 2008, at 10:49 PM, Brendan Eich wrote:
If, in order make the presence of an explicit form convenient, we
have to add sugar for it as an additional form of expression-closure
-- goto call-expr() means {goto call-expr();} -- I don't think
it's the end of the world. I do
On Jan 21, 2008, at 8:12 PM, Maciej Stachowiak wrote:
On Jan 18, 2008, at 10:49 PM, Brendan Eich wrote:
If, in order make the presence of an explicit form convenient, we
have to add sugar for it as an additional form of expression-closure
-- goto call-expr() means {goto call-expr();} -- I
On Jan 21, 2008, at 10:50 PM, Brendan Eich wrote:
return might be a
good choice of syntax if it weren't for the implicit conversion
problem.
It would, indeed: return and yield would both then be low-precedence
unary operators.
(Low-level grammatical quibble with myself, probably only of
On Jan 21, 2008, at 5:26 PM, Peter Hall wrote:
Thanks. That would work. But I can still see the average user being
confused when debugging, and not knowing what is going on.
Would you think an explicit keyword syntax for mandatory tail call
would help such a user?
To the claim that
On Jan 21, 2008 10:50 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Jan 21, 2008, at 8:12 PM, Maciej Stachowiak wrote:
How about something like tailcall or tailreturn.
Or just tail f(x, y), Dave Herman's suggestion.
tail looks great and any of these three suggestions seem far better
than
in presence of proper tail calls will
grow only by the last closure unless the function explicitly makes
values externally reachable.
On 21/01/2008, Jon Zeppieri [EMAIL PROTECTED] wrote:
But the above example *does* only require O(1) space. On each call to
f, a new closure is constructed
On Jan 21, 2008, at 11:37 PM, Maciej Stachowiak wrote:
What I meant to point out is that the motivating use case for
additional up-front checking can't in general be checked until
runtime, which somewhat undermines the point you made that many non-
tail cases could be caught at compile
not be evident until runtime, where the result would
be a TypeError or possibly a new Error subtype.
Isn't this case (implicit conversion) exactly what motivated the idea
that programmers may not be able to easily tell if a call is in tail
position?
Indeed:
ES4 has proper tail calls
My concern with E (or A for that matter) is that it requires
additional syntax. I'd prefer if we could keep the syntax small. I
don't think implicit PTC is an issue. It is an optimization that the
interpreter/compiler should do. What are the problems with I? It
does not change the semantics
On Jan 20, 2008, at 5:22 PM, Erik Arvidsson wrote:
My concern with E (or A for that matter) is that it requires
additional syntax. I'd prefer if we could keep the syntax small. I
don't think implicit PTC is an issue. It is an optimization that the
interpreter/compiler should do. What are
://bugs.ecmascript.org/ticket/323
brought up the idea of an assertion I want a PTC here: that could
be attached to a call, with implicit proper tail calls. I should have
represented this as an option; thanks for bringing it to light on the
list. Call it I,X (Implicit, eXpression tail calls) + A (Assert-PTC
for
the spec to simply require implementations to have proper tail calls?
The I,X original proposal from the wiki required this. It's reasonable,
maybe, if we can agree on the rules and they are not too complicated, but
the crucial question is about usability, human factors, avoiding silent
Will proper tail calls be implicit in ES4 or will there be a need for
special syntax? I hope it is just a required optimization but then I
read this ticket
http://bugs.ecmascript.org/ticket/323
and it seems there is a suggestion that the spec will only require
proper tail calls with a goto
On Jan 18, 2008, at 9:36 PM, Peter Michaux wrote:
Will proper tail calls be implicit in ES4 or will there be a need for
special syntax? I hope it is just a required optimization but then I
read this ticket
http://bugs.ecmascript.org/ticket/323
and it seems there is a suggestion that the spec
62 matches
Mail list logo
