Improve block statements and import rules

[savq]

• Rename _expression_list to _block. "block" is the name used in Julia ASTs. See: https://docs.julialang.org/en/v1/devdocs/ast/#Block-forms
• Rename compound_expression to compound_statement
• Fix empty compound and let statements
• Fix import/export statements
  • Add relative qualifiers
  • Add import aliases
  • Allow operators and macro identifiers in imports and exports
• Update tests

---

Closes #13, closes #15, and closes #58 (duplicate)
Closes #28
Closes #59

[ChrHorn]

I think it would be better to use block instead of _block. Makes it easier to do tree sitter based selection, for example select only the body of the function etc. That's how it is done for most grammars.

Exception for source_file, there _block should be OK.

[savq]

That's how it is done for most grammars.

Is it? As far as I know, Lua is the only algol-like language that has explicit blocks.

For now, I only wanted to rename to _block to align with Julia terminology and because it's easier to grep/jump to. But I'm not sure about making the rule visible... Neovim manages to match inner blocks, so it's doable.

@ChrHorn, could you open an issue to revisit that idea later?

[ChrHorn]

@ChrHorn, could you open an issue to revisit that idea later?

Will do!

[ChrHorn]

What is the reason for the renaming? Aren't begin ... end block technically expressions? Same with let and if (and probably more), these are also expressions, right?

[savq]

Yes, they are. Julia is an expression based language and all forms are expressions that return some value.

_statement does conflate a few of things:

1. Forms that hold blocks, like quote … end
2. Forms that "never return" a value like return and break
3. Forms that can only be at the top-level, like import

I would like to have a separate name for the first one, because we have quote_statement for quote … end and quote_expression for :(…). Similarly, we'd have compound_statement and parenthesized_expression, which aren't distinguished in the IR (they both form block Exprs). I think this is more consistent.

I have no opinion on the second category.

I don't think the third one should have any special treatment, because you can write those expressions inside quotes (which are not necessarily top-level).

_statement is a "subtype" of _expression in the grammar, so this more of a naming problem than a parsing problem.