Raku
What makes `unit` be too late?
- The docs state (and have stated for many years) that a
unitdeclaration at the beginning of a file may be preceded only by comments andusestatements. - However, any declaration of
sub EXPORTmust precede theunitdeclaration. - Neither requirement seems to be tested in any roast tests that I could find (but I'm still a novice at searching in the roast repo).
The blocked docs issue https://github.com/Raku/doc/issues/2148 is over seven years old, and the problem it describes is still in the current docs.
The statement at issue in the docs is in https://docs.raku.org/language/syntax#package,_module,_class,_role,_and_grammar_declaration and is currently worded as:
you can declare a
unitpackage at the start of the file (preceded only by comments orusestatements),
The conflicting (assuming that unit packages can make use of sub EXPORT) statement is in https://docs.raku.org/language/modules#EXPORT :
Please note that
EXPORTcan't be declared inside a package because it is part of the compunit rather than the package.
This issue is a re-open of the closed rakudo issue https://github.com/rakudo/rakudo/issues/2020 as a problem-solving issue, as suggested at the time that issue was closed.
does this mean that unit cannot be used with sub EXPORT -or- that you can declare sub EXPORT before the unit line?
[not asking for ROAST info - just what do es hte latest rakudo do in practice]
@librasteve, the original issue stated that you can in fact declare any number of subs before a unit package. I just tested declaring an empty sub EXPORT followed by a unit package and got no errors
There was some discussion of that on the other issues linked above, and there's reluctance to document things that ROAST doesn't require, which makes sense, since all such behavior is technically implementation detail and not part of the language we're documenting.
Discussion to come to a consensus (about what ROAST should require here) got bogged down in the now-closed rakudo issue https://github.com/rakudo/rakudo/issues/2020, which is why I opened this one, because lack of such consensus is what's blocking the docs issue https://github.com/Raku/doc/issues/2148.
My own opinion about what the consensus seemed to be groping toward is that sub EXPORTand the like should be allowed (like comments and use statements) before a unit declaration, but that any sub not explicitly allowed there should be disallowed.
By 'and the like' I mean any other ALL-CAPS subs clearly connected to the namespace in question (as EXPORT is) but which for some reason have to live outside that namespace. This is intended to cover both future developments and also possibly other existing language features that I haven't learned about yet: the general principle is that there's an allowlist for this, and anything not on it would cause squawking.
So should I be trying to write my first ROAST tests then? I think for this one, we want to add it to the spec before changing the doc.
Not sure how helpful this is, but here's an old discussion of this issue from 2016, that is linked to from current doc.
@arkiuat - agree that adding to ROAST first is a good plan.
I have written (literally) a couple of ROAST tests - having seen you work in the docs, I am sure that you will find it straightforward (and of course there are many out there to help if you get stuck)
@librasteve thanks, but it's not that I'm hesitant to submit a PR for ROAST, or even that I'm not sure how to test for this particular thing. It has just become clear to me that this isn't going to make it to the top of my priorities anytime soon, if ever.
At worst, the status quo is that anyone can add a unit class/module/package/whatever to the end of any file that doesn't define other classes/packages/etc, as long as it's the last thing in the file, but the docs say that you can't do this, perhaps in hopes of preventing people from making a habit of it. I'm okay with leaving that as is because there are bigger fish to fry, so I'll leave it for someone who cares about it more than I do.
Originally I was just trying to knock off an old blocked docs issue, but the scope has creeped. We're just talking about a way to save a level of indentation here.
OK - thanks for explaining - we all have our various foci and time constraints.
On a matter of "issue etiquette" I personally prefer "issues that we know are real, but have no prospect of getting resourced since we consider them too low priority" be Closed (ie both this problem-solver and the referenced doc issue above), and perhaps marked with a label such as "later" or "punted".
That way we can try to keep the issue stack tidy and avoid creating new issues that will still be here in 7 years time.
ymmv ;-)
Ah, just because it's too low-priority for me doesn't mean it will be too low-priority for the next volunteer who steps up. As you say, mmmv.
I wouldn't want to close this one without also closing the docs issue that spawned it. Also, this issue, which explicitly seeks to find out what kind of things such a ROAST test should prohibit, has only been open for a couple of months: not enough time for all knowledgeable parties to weigh in on that question.
Which, come to think of it, is another reason why I'm not eager to try to write a ROAST test for this right now: I'm not sufficiently knowledgeable to make that particular decision.
This issue will be discussed in the first Raku Resolutions meeting, see more information at https://dev.to/lizmat/raku-resolutions-17g7
