keywords as selectors

[ozanh]

I've realized that keywords cannot be used as selectors. Followings are not parsed;
https://tengolang.com/?s=2dbaf9a98cff105d9231209806f40f87ef51c105

object := {}
object.error = "an error" // Parse Error: expected selector, found 'error'
object.in = true // Parse Error: expected selector, found 'in'
object.export = "ok"  // Parse Error: expected selector, found 'export'
// etc. etc.

Is it possible to use keywords as selectors by changing the parser? I can try to create a PR for this.
I want to do console.log.error("this is an error) or use other keywords as selectors. What do you think @d5 @geseq ?

[geseq]

Good catch @ozanh . I think it’s a good idea to fix this.

[ozanh]

Yes @geseq I think I should create a PR for this. But I will keep parsing map element literal as it is because {in: true} this also throws error and should stay like this. What do you think?

[geseq]

Yes I think map element literals should be defined by whatever type they are (in your example a string so it should be within quotes)

[ozanh]

@d5 if you are OK with using keywords as selectors I will create a PR. Let me know please.

[d5]

When implementing the first version, I simply followed Go's struct syntax where struct field name cannot be a keyword. But I think the problem here is that

a.for = 1

is invalid, but

a["foo"] = 1

is valid in Tengo. So we have 3 options here:

1. allow using keywords as field name.
2. disallow them in both forms (a.for and a["foo"]).
3. keyword field name is allowed only via a["foo"] form. (<- basically the current implementation)

My concern for option 1 is that we might introduce some edge cases in parser and compiler. Option 2 implementation can be really tricky and even have a performance overhead. Option 3 is not ideal I guess but maybe we can just clarify that in the documentation?

[ozanh]

Tengo consistently uses lower cases for keys, function names and underscores in the documentation and somehow it has bitten me while writing engine.log.error("this is an error) in my library. If I had used engine.log.errorln(...), I would not have realized that. As I have read all tengo documentation many times, I could catch it but not documented. For Option 1 I created a somewhat hackish branch a while ago. It does not allow {in: true} but allows a.in. If you want to see I can create a PR.

[d5]

Yeah I'd prefer adding some documentation about this limitation (option 3) rather than adding more complexities/overhead in parser/compiler/runtime.

[qzb]

@d5 Actually, using keywords as selectors (a.error) is quite easy to implement, it requires only minor changes in the scanner. Using keywords as keys ({ error: true }) in completely different story...