Reserve more keywords in KCL

[jtran]

Before 1.0, we'd like to reserve more keywords so that users don't use them as variable names.

This is the list that was proposed:

• _ (underscore)
• as
• new
• interface
• type
• record
• struct
• object

I think we should add to this list:

• self Pipelines, tagging, and for loops kcl-experiments#15
• array - Could be a runtime conversion function or the type. We already support optional type annotations, like string, number, and sketch. We use [] for the type, but it still may be useful to refer to the type or constructor by name.

Should we consider others? Here's JavaScript's and Python's.

• Something for error handling?
• implements to use the interface?
• data, datatype, or enum; match, case, or switch.
• Something for block syntax? do or yield? Constraints design doc kcl-experiments#20

These will not be reserved:

• from - It's used in import statements, but because of the syntax chosen, it's unambiguous. This will likely be used for named parameters.

[jtran]

type is used for the keys of objects in the stdlib. For example, see ImportFormat, which is the options of the import() function. Our options:

1. Disallow all keywords and types as object members and change all stdlib usage of type to kind, format, type_, or some other alternative.
2. Allow all keywords and types as object members by changing the parser to accept keywords or types in object literals and in dot notation when accessing members
3. Special-case type, specifically, to allow it, but not other keywords and types
4. Never treat type as a keyword. I.e. the proposed change is not wanted.

My inclination is to not special-case things, keep things simple, and go with option 1.

Update: from is another one that we'll probably want to use for named arguments.

[nrc]

IMO, import should become a full keyword too.

[jtran]

For import, the parser doesn't let you define something that's the same name as any stdlib function. See into_valid_binding_name() in parser_impl.rs. So I think we're fine for now. But we should be aware of this if we rename, refactor, make namespaces, etc.