Introduce 'export' on 'func'/'macro'/'my'

[masak]

This keyword doesn't have any semantics at all yet, since we haven't
started implementing modules, not even behind a feature flag. The
idea to have this keyword now is to be able to write 007 code that's
closer to what modules will eventually look like when we do have
them. Less to change to make them work.

To be extra safe, and avoid having to break backwards compatibility
later, we make sure that if an expression is exported, then it has
a leftmost my to export.

Closes #404.

[ghost]

Where is the link to an import statement (as stated in the documentation)? I understand that this is two different things, just curious if there is any code for this yet?

[masak]

Nope, no code for import yet! The full issue for this is #53, and work on that hasn't begun, although it's been designed in fair detail at this point.

Again, this export keyword is just a short-term stopgap, in order to

be able to write 007 code that's
closer to what modules will eventually look like when we do have
them.

That is, we're currently "exporting to nothing in particular", but with the expectation that what's clearly module code will need less change once we have modules.

[ghost]

I am sure this is me being wrong, but I've look and looked at this.

1. A comment states that 'we're just enforcing that there's a "my" [...]' at line 86, but that is not true since...
2. more things a included: My, $, Prefix, Postfix and Infix. Ok. so that comment don't (if I am correct here) everything that happends but - and this is important (perhaps) - why is not func included in the same file (Actions.pm6). func is 'exportable' in the file Syntax.pm6, I guess (not sure... NOT the same kind of syntax for this...)

I guess it passes the test (line 13) in t.pm6? But... I am very confused and I don't know if this is me not understanding the code (the seperation of things) or if the structure is strange. To me infix, postfix (and so on) IS different types of functions, but apperently - for reasons beyond my capacity - it's seen as something else... Hmm. Is everything realy accurate here?

Anyways... The comment should be more inclusive? (Another solution would be erasing the My-part...)

[masak]

Note that this comment is already limited to expressions. Here's the problem: we want to be able to export my declarations, but my declarations were recently turned from statements into terms in 007. (See #279 and #369.) As a consequence, the expression might be something like

export my name = "Bond";

but it might also be something like

export say(my name = "Bond");

We want the former one to be legal, and the latter one to be a compile-time error. The comment is to be read in that context: if we're parsing a statement, and if it has an export modifier keyword, then the next thing needs to be a my.

[ghost]

Now... As I said, perhaps I missunderstand something. But it seem to me - glancing at the code - that infix, postfix and more is included - IS exportable - but in that case, where is the tests? This only focus on my and func? Further, it seem to me that the tests is more comprehensive for my than func (...)? Why? Yes, that may be because of the comment but... hmm... in that case why the added lines with infix (...) ?

[masak]

• Operators are exportable by virtue of being functions. Granted, we could have a dedicated test for that case, but it will just work out, since an operator definition is a function definition.
• The tests are more comprehensive for my because of the reasons I gave in the other comment: func and macro always have an exportable name (and so there are no "cases" to consider); an expression may or may not have a my declaration at the beginning; and if it doesn't, it's not valid to put an export there.