Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
1 commit merged into from
Oct 23, 2018
Merged

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

1 commit merged into from
Oct 23, 2018

Conversation

masak
Copy link
Owner

@masak masak commented Oct 23, 2018

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.

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
Copy link

ghost commented Oct 23, 2018

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
Copy link
Owner Author

masak commented Oct 23, 2018

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.

@@ -78,6 +82,24 @@ class _007::Parser::Actions {
}

method statement:expr ($/) {
if $<export> {
# For now, we're just enforcing that there's a `my` at the far left, according to the
Copy link

@ghost ghost Oct 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...)

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

"export syntax is not allowed if the 'my' variable is missing";
}

done-testing;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 (...) ?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • 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.

@ghost ghost merged commit f2b68ee into master Oct 23, 2018
@masak masak deleted the masak/export-keyword branch October 23, 2018 14:32
masak pushed a commit to masak/007-ascii-header-printer that referenced this pull request Oct 23, 2018
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement (semantically void) 'exports', now
1 participant