jqlang / jq

Command-line JSON processor

Home Page:https://jqlang.github.io/jq/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

$end as a variable

pkoppstein opened this issue · comments

Shouldn't one be able to use $end as a variable?

$ jq -n '1 as $end | 2'
1 as $end | 2      1 compile error

True, the same thing happens with other keywords, so perhaps this is not exactly a bug, but ....

It could be done. I'm not sure it's a good idea: if $if then $then else $else // $end end is hardly worth making possible! But it could be done. For me this would be a low priority.

Note that it's possible to use --arg end whatever, it just can't be accessed from the program. Also, whenever we add keywords we have a backwards-compat problem unless we allow symbols with the new keyword names to remain. while, for example, is not a keyword, but foreach, try, and catch are, and they are recent additions. I think that's reasonably OK at this stage: backwards incompatible changes that yield compilation errors are much, much better than backwards incompatible changes that yield subtle run-time behavior changes.

For now I'm setting a milestone far in the future. Though I'll consider a PR.

The issue is in lexer.l: '$' and IDENT are lexed as two separate tokens, rather than one token \$[a-zA-Z_][a-zA-Z_0-9]* called VAR_IDENT. Another unintended consequence of this is that $ foo parses.

Right. This can be fixed. Should we?

I like fixing it for $ foo, but I'm... hesitant with things like $end, $foreach, etc...
Even though those words wouldn't be keywords in the context and it should work just fine, allowing them to be used as IDENTs just concerns me. I can see confusion in the future down that road. Not necessarily errors. But absolutely confusion.

Should --arg end ... yield a warning or an error? Or should we have all --args available as an object in addition to having them as $var bindings?

We'd make the lexer output something like a DOLLAR_IDENT token and we'd change all the parser rules that match '$' IDENT to match DOLLAR_IDENT. That's five rules, so very little impact.

That sounds good, actually. I'm also working on the parser. It makes lots
of top blocks, so I'm working on removing the extrast. It'll also allow
removal of unused inline defs, hopefully.
On Aug 4, 2014 6:37 PM, "Nico Williams" notifications@github.com wrote:

We'd make the lexer output something like a DOLLAR_IDENT token and we'd
change all the parser rules that match '$' IDENT to match DOLLAR_IDENT.
That's five rules, so very little impact.


Reply to this email directly or view it on GitHub
#526 (comment).

I noticed the surfeit of TOPs. What happened?

We were inserting them in too many places. Interestingly, things fail
assertions if I only remove some of the extras, but not if I remove them
all. Just an interesting anecdote, I'm removing all of the extras.
On Aug 4, 2014 7:48 PM, "Nico Williams" notifications@github.com wrote:

I noticed the surfeit of TOPs. What happened?


Reply to this email directly or view it on GitHub
#526 (comment).

One can now use any keyword as an object key, but I think this is where we should stop, for now.

The issue is in lexer.l: '$' and IDENT are lexed as two separate tokens, rather than one token \$[a-zA-Z_][a-zA-Z_0-9]* called VAR_IDENT. Another unintended consequence of this is that $ foo parses.

Hahaha, that's almost exactly what I said in #2675 (comment)