Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upLambda literal arguments invalid after formatting #651
Comments
|
For what it's worth, these were my notes from tracing what grammar might be used for each case:
tLAMBDA: `->`
f_larglist: `(...)`
f_args: `optional = !something?`
f_optarg: `f_opt`
f_opt: `f_arg_asgn '=' arg_value`
arg_value: `arg`
arg: `lhs '=' arg_rhs`
arg_rhs: `arg`
arg: `primary (almost anything)`
lambda:
brace_body: `{ ... }`
opt_block_param: `none | block_param_def`
block_param_def:
- `'|' opt_bv_decl '|'`
opt_bv_decl: `bv_decls`
bv_decls: `bvar | bv_decls ',' bvar`
bvar: `tIDENTIFIER`
<!-- matches the above before this? -->
- `'|' block_param opt_bv_decl '|'`
block_param: `f_block_optarg`
f_block_optarg: `f_block_opt`
f_block_opt: `f_arg_asgn '=' primary_value`
primary_value: `primary`
primary: `(almost anything...)` |

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.

Documenting this here and will open a PR for it.
Metadata
Input
Current output
Expected output
Reasoning
The current output is invalid ruby syntax. I did my best to read through the ruby grammar (
parse.y) and determine why a unary (!) would be valid in->(...), but not indo |...|and I was grasping at straws a bit. I'm not experienced enough with the grammar there to determine if there's a bug in the parser and it's picking the wrong matcher for args indo |...|where a unary isn't allowed, but nonetheless it breaks.Example:
Without determining exactly what the parsing grammar allow and disallows, I found it difficult to propose a change that would conditionally use
->vs.lambda {when a particular arg pattern was detected. It was my assumption that detection of exceptions where->must be used was futile. As a result, I think the best course of action is to use->for everything, since the args patterns it allows are a superset ofdo |...|(block params) and it is likely unsafe to transform a->(...)intolambda { |...|.