Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overloading label syntax for tailcall #19

Open
bobzhang opened this issue May 10, 2016 · 11 comments
Open

overloading label syntax for tailcall #19

bobzhang opened this issue May 10, 2016 · 11 comments

Comments

@bobzhang
Copy link

function even(x){
  __ecma_tailcall: return odd(x-1);
}
function odd(x){
 __ecma_tailcall: return even(x-1)
}

The label is quite descriptive and it is also valid es5 syntax, about backward comptablity, I think it would break very few programs, see discussions in #11

@claudepache
Copy link

The label is quite descriptive

Please, tailcall:, not __ecma_tailcall:. The __ecma_ prefix doesn’t describe anything relevant.

@bobzhang
Copy link
Author

@claudepache it's mostly for avoiding break some weird code, I like taicall: too!

@littledan
Copy link
Member

I like how the current proposal is expression-based. For things like the ternary operator, you put the tailcall annotation right before the call. A label would not permit that.

@bobzhang
Copy link
Author

@littledan I agree, but the current proposal is a new syntax, my proposal is still valid ES5/ES6, it does not hurt expressivity.

@littledan
Copy link
Member

@bobzhang Without it being an expression, the expressivity of the proposal is hurt, and it becomes harder for developers to get precise errors about misusing tail calls. Further, users who are OK in the transition without tail calls being supported should be OK continuing to not get tail calls after an explicit syntax is added.

@bobzhang
Copy link
Author

@littledan can you show an example that is not expressible in this syntax? This syntax allows me write future proof code

@littledan
Copy link
Member

Your code will be future proof by simply not using the tail call feature. Here are two examples that I don't know how to translate into label syntax:

() => continue f(x)

function even(x) {
  return x <= 0 ? x == 0 : continue even(x-2); 
}

@bobzhang
Copy link
Author

() => { tailcall: return f() }

I don't think it is that bad given js is not an expression oriented language.
Anyway, it is just my opinions

@littledan
Copy link
Member

Well, if you're talking about JS as a target language for functional languages to compile into, expressive expressions do help. do expressions have been proposed partly for this exact purpose, but they aren't championed at the moment.

@bobzhang
Copy link
Author

bobzhang commented May 10, 2016

if you're talking about JS as a target language for functional languages to compile into, expressive expressions do help

@littledan For smart transpilers, tailcall statement is good enough, actually, I like this syntax, the label was used as a location, and it was used for control flow, my proposal was just making some labels with special meaning

tailcall was very useful in cases like lexer/parser generator, those are typically generated code, several more strokes does not really hurt

@bterlson
Copy link
Member

bterlson commented May 12, 2016

I don't think it's acceptable to require tail calls from arrows to use a function body (should work with concise bodies). I also don't see how the label works with ternary. Ultimately, I still don't agree that there is value in making tail calls valid ES6 syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants