-
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
Arguments following spread #3
Comments
Thanks. I tried to nail this quick the other day since I only had a minute, and accidentally did params instead of args. Revising now. |
Thanks! Incidentally, this reminded me how irritated I am that a leading rest operation is illegal in the first place. Don't suppose you've got any insight on why this is the case? |
I bet there are ES Discuss records about that. Perhaps it would create some hidden complexity. Superficially, permitting a "rightward" mapping is not ambiguous:
The first thing I can think of is that it does require some new grammar, because this, along with any other parameter declaration with two rests, is nonsensical:
On the other hand, this is actually unambiguous:
So they could have written the grammar such that any given parameter declaration would contain zero or one rest parameters. I don't think this would have required any hoop jumping, actually -- no cover grammars or anything like that -- so I doubt grammatical complexity was the issue. So perhaps it has something to do with how function parameters are implemented internally -- maybe it would be somehow disruptive that, if non-terminal rests were permitted, _non-_rest parameters would no longer have specific indices. But I'm just guessing here; for all I know, nobody brought it up? I'm pretty clueless about the internal mechanics for outfitting functions. |
Other thoughts: In your own code, you can implement a simple util for supporting right-to-left rest-params. (More complex forms wouldn't be so easy to represent, though): const reversedRest = fn => {
const ln = fn.length;
return (...args) => {
const rest = args.slice(0, -ln);
const named = args.reverse().slice(0, ln);
return fn(...named, ...rest);
};
}
const example = reversedRest((tail, ...rest) =>
`the tail is "${ tail }"; there are ${ rest.length } members prior (${ rest })`
);
console.log(example('a', 'b', 'c', 'd')); On Babel REPL |
Thanks for the fantastic work on this. My terse method declarations and bind operations read sensible now. It's a huge boon!
I've spotted the following problems, not sure if it's an issue with themes or the parser - Carthage doesn't suffer (although I find almost everything except for operators and functions impossible to distinguish in Carthage anyway). All these screens were taken in Monokai, but the same problem is visible with Excelsior & Villa-Lobos.
Any arguments following a spread don't play well, see line 125:
![screenshot from 2015-10-28 11-11-54](https://cloud.githubusercontent.com/assets/83627/10786892/de7273a4-7d64-11e5-81eb-3ba84de2e8b9.png)
The text was updated successfully, but these errors were encountered: