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

Arguments following spread #3

Closed
barneycarroll opened this issue Oct 28, 2015 · 4 comments
Closed

Arguments following spread #3

barneycarroll opened this issue Oct 28, 2015 · 4 comments
Labels

Comments

@barneycarroll
Copy link

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

@barneycarroll barneycarroll changed the title Arrow expressions as arguments & arguments following spread Arguments following spread Oct 28, 2015
@bathos
Copy link
Owner

bathos commented Nov 1, 2015

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.

@bathos bathos added the bug label Nov 1, 2015
@bathos bathos closed this as completed Nov 1, 2015
@barneycarroll
Copy link
Author

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?

@bathos
Copy link
Owner

bathos commented Nov 1, 2015

I bet there are ES Discuss records about that. Perhaps it would create some hidden complexity. Superficially, permitting a "rightward" mapping is not ambiguous:

function poop(...rest, last) {}
function poop(...rest, penultimate, last) {}

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:

function poop(...wat, ...no) {}

On the other hand, this is actually unambiguous:

function poop(first, ...middle, last) {}

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.

@bathos
Copy link
Owner

bathos commented Nov 1, 2015

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

@bathos bathos mentioned this issue Feb 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants