iankressin / eql

Query language to interact with EVM chains
https://eql.sh
MIT License
68 stars 7 forks source link

Support lower case keywords #31

Open iankressin opened 3 months ago

iankressin commented 3 months ago

Describe the solution you'd like At the moment EQL only supports upper-case keywords like GET, FROM, ON, and that can be annoying for someone that's looking for speed instead of differentiating between keywords and other elements

Additional context The solution is simply ignoring case for the keyword defined on production.pest

yulesa commented 3 months ago

I thought about doing this as well in the PR that fixed the EOI rule. It's a simple ^ to the rules. I can still add it. But is this something we really want? I like that EQL differentiates commands from entities, fields, entity_ids and chains.

iankressin commented 3 months ago

But is this something we really want? I agree that differentiating keywords from fields and variables is good, but I don't think we should do that with casing. Typing uppercase words can be a pain for some people depending how they set up their keyboards.

In my case, I have caps lock mapped to esc in all my keyboards, since it makes faster to switch between vim modes, and it is a common practice among the people who use vim motions. This means that I have to type the keywords holding down shift, which is inconvenient.

By supporting lower-case keywords, we still allow people to differentiate between keywords and identifier using upper-case/lower-case words, but we support those who prefer a smoother typing experience as well.

rizdarmwn commented 3 months ago

There's a problem with this.

"from" is also included in the tx_field_list, so it parses "from" as fields instead of FROM ~ entity

 --> 1:25
  |
1 | get nonce, balance from account 0x00000000219ab540356cBB839Cbe05303d7705Fa on eth
  |                         ^---
  |
  = expected fields

any suggestion how to solve this?

maybe we can use a special case for this? like how postgres does it (using double quotes, a block "[ ]") or changing the 'from' field name

iankressin commented 3 months ago

@rizdarmwn I'm thinking about using another keyword to replace FROM and avoid this conflict, like OF. It's shorter than 'FROM' and holds the same semantics.

rizdarmwn commented 3 months ago

hmm, I see. but that will trip users off when using it. expectations was it's SQL for the EVM networks.

i think we can just use the special case for the "from" fields, no? when using lowercases FROM, so it doesn't change the base queries. or we can support both FROM and OF

iankressin commented 3 months ago

i think we can just use the special case for the "from" fields, no? when using lowercases FROM, so it doesn't change the base queries. or we can support both FROM and OF

I'm not a big fan of the special characters approach. I'd like the syntax to look as clean as possible, and that's a step in the other direction.

hmm, I see. but that will trip users off when using it. expectations was it's SQL for the EVM networks.

The "SQL for EVM networks" is just a way to quickly communicate what EQL is, it shouldn't mean that we need to follow the language specs. We've already introduced GET and ON keywords, that differs from SQL syntax.

rizdarmwn commented 2 months ago

Sure, then I'll try to change it to of

Krishn1412 commented 1 week ago

Is it okay if I take this?

iankressin commented 6 days ago

Hey @Krishn1412! This issue is taken, but maybe you can take a look a this one https://github.com/iankressin/eql/issues/56. It's also a good first issue.