I thought it was useful information for people who did not know this. Of course Wikipedia would have sufficed, too: "Raku, formerly known as Perl 6 [...]".
I hear you were coming from the angle of being useful. In a sense that's what matters most, and I love that you have that spirit.
If Wikipedia has deadnamed Raku with grace then that might be a model to follow, but in general it's far from helpful unless it's done carefully. There's a reason why the community embarked on the somewhat painful multi decade process of renaming it. To try clarify my understanding I'll summarize it here.
Because of the original name for Raku, people assumed for a long time (long after it became problematically misleading) that it shared semantics, or syntax, or compiler tech, or libraries, or something technical like that, with some other programming language(s).
This was partly because Raku did indeed take some inspiration philosophically and/or technically from some existing languages (traces of a half dozen or so are evident), and partly because Raku and its compiler tech features the ability to use Python code and compilers, and C code and compilers, and Perl code and compilers, and so on, as if they were native Raku code/compilers.
But Raku was never C, or Python, or Perl, and the old name is unfortunately a form of deadnaming -- which is to say, something that is seldom helpful, especially if some commentary like this comment is not included.
At least, that's how I experience it.
That said, regardless of my view, I love your impulse of being helpful, which is why I've written this -- and I hope it does help any readers.
Actually, a module can implement any export heuristics by supplying an EXPORT subroutine, which takes positional arguments from the `use` statement, and is expected to return a Map with the items that should be exported. For example:
sub EXPORT() { Map.new: "&frobnicate" => &sum }
would import the core's "sum" routine, but call it "frobnicate" in the imported scope.
Note that the EXPORT sub can also be a multi, if you'd like different behaviour for different arguments.
neat! i've never needed more than i could get away with by just sneaking the base stuff into the mandatory exports and keying the rest off a single arg, but that'll be handy when i do.
They are, and I am entitled to not associate with them in any way, and tell others to do the same, for this specific comment alone. It says a lot about his views. Like seriously, because the UK a long time tried to conquer parts of the world, mass migration to the UK today is somehow OK? Slavery should be OK, too, according to him, then, since all races have been enslaved at some point in time of history. It is extremely poor reasoning, in poor taste. You should know better.
My comment made zero moral judgements. History has consequences. Spreading the English language to over a billion people while enriching Britain means a lot of people will want to live in a rich place where they can speak the language, for generations to come. Whether immigration is good or bad is kind of irrelevant to the argument.
You appealed to what "UK" did in the past, though.
Same thing applies to slavery, then, since every race has been enslaved before. Would you say slavery is OK, too, considering it has been common practice by then by race or nationality X?
The Raku Programming language allows one to specify the required version, the required authority and API level:
use Foo::Bar:ver<0.1.2+>:auth<zef:name>:api<2>;
would only work if the at least version 0.1.2 of the Foo::Bar module was installed, authored by "zef:name" (basically ecosystem + nick of author), with API level 2.
Note that modules can be installed next to each other that have the same name, but different authorities and different versions.
Imports from modules are lexical, so one could even have one block use one version of a module, and another block another version. Which is handy when needing to migrate date between versions :-)
reply