-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
Please, |
@claudepache it's mostly for avoiding break some weird code, I like |
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. |
@littledan I agree, but the current proposal is a new syntax, my proposal is still valid ES5/ES6, it does not hurt expressivity. |
@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. |
@littledan can you show an example that is not expressible in this syntax? This syntax allows me write future proof code |
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:
|
I don't think it is that bad given js is not an expression oriented language. |
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. |
@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 |
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. |
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
The text was updated successfully, but these errors were encountered: