Open iankressin opened 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.
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 bothFROM
andOF
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
Is it okay if I take this?
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.
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 elementsAdditional context The solution is simply ignoring case for the keyword defined on production.pest