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

Inline block comments can introduce unwanted commas in a function parameter list #769

Closed
dpritchett opened this issue Oct 13, 2010 · 11 comments
Labels

Comments

@dpritchett
Copy link
Contributor

Please see http://gist.github.com/624272

I was trying to caffeinate some JS of the form

callThisFunction( /* block comment here */ firstArgument)

but my compiled JS output came out looking like

callThisFunction( /* block comment here */, firstArgument).

Note the extra comma.

@satyr
Copy link
Collaborator

satyr commented Oct 14, 2010

Would compiling without extra commas suffice, or should we go multiline in this case:
callThisFunction(
/* 1st /
1,
/

* 2nd
*/
2
)
And what if there are splats?

@zmthy
Copy link
Collaborator

zmthy commented Oct 19, 2010

Didn't there used to be restrictions about where you could put a block comment? Right now they're just expressions which means they can be used just about anywhere with all sorts of funny effects.

@StanAngeloff
Copy link
Contributor

Thinking out loud, but can the grammar be updated so instead of producing a node for the comment, we attach it to the next generated node? We can then tweak block comments to appear in most places, incl. in the middle of a line.

% coffee -en 'Hello World'
Expressions
  Call
    Value "Hello"
    Value "World"

% coffee -en 'Hello ### there ### World'
Expressions
  Call
    Value "Hello"
    Value "World", comment "there"

It may actually be a pain to update the lexer to ignore all these comment nodes so the above still compiles to a Call.

Another possible implementation would be to pass on the comment in the lexer to the generated token. The parser could then persist this across the generated node (if that's at all possible).

Just my thoughts, anyway.

@zmthy
Copy link
Collaborator

zmthy commented Oct 19, 2010

I started implementing exactly that a few hours ago, but only in specific places, where it made sense. I got tired of wrestling with the grammar though. I might go back and have another crack at it after I get some sleep.

@jashkenas
Copy link
Owner

Stan's approach has always been the most appealing tactic in theory -- but in practice, it seems quite difficult. Almost every line of node.coffee compiles a node in some form or another, and at compile time we'd have to take special care compiling it if the node happened to have a comment (or two, or three) attached.

It sounds great, but I think I'll believe it when I see it in action ... is what I'm saying.

@StanAngeloff
Copy link
Contributor

OK... mmm... zaach added an option to support error recovery in Jison. I recall experimenting with it, but not exactly what I did. My thinking is -- can a rule be produced which says Expression error and error Expression (both needed to support comments anywhere?) From within the rule we examine the erroneous token and if it's a block comment, we can recover yielding the Expression and either push the comment to the stack (to be applied to the following expression) or apply it to the preceding expression.

Long shot at best...

@jashkenas
Copy link
Owner

Nah, error handling is just as difficult an approach as comment-tagged nodes, with no benefit.

@jashkenas
Copy link
Owner

Tesco: I noticed your branch where you make Comments Lines instead of Expressions ... how's that working out for you?

@zmthy
Copy link
Collaborator

zmthy commented Oct 25, 2010

It's not. Comments are fundamentally broken at the moment, I need to take about a day to redo their logic.

@jashkenas
Copy link
Owner

master now treats block comments as statements instead of expressions, which solves this issue by making it impossible to write in the first place. This could be looked at as a step backwards, but is actually just making it so that you can only write block comments in spots where they won't interfere with the compilation of your code. Closing the ticket.

@GeoffreyBooth
Copy link
Collaborator

Inline block comments that aren’t treated as expressions happens now via #4572. Sorry it took awhile.

@GeoffreyBooth GeoffreyBooth removed the bug label Aug 3, 2017
This issue was closed.
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

6 participants