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.

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.

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

@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.

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

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.

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