Perl6 module namespace

I'm going to talk about that which I know very little, but looking at the Perl6 Module Directory, I see a namespace that's already storing up pain. Why are there so many modules in the top level namespace that make no sense for a language that has designs on world domination? I can believe that in the early days of development there's an intoxicating freedom to give your module a snappy name, but didn't we learn these lessons 20 years ago? What happened to Noun::Adjective::Adjective as the guiding principle?

If you're determined to re-invent the wheel, at least try to invent a better one. - Camel Book, 2nd ed. p277. footnote on False Impatience.

Let's unfairly single a couple out. Chess Why is this not under the Games space along with Druid? I'm not saying that there should be hard and fast rules about what's allowed in the Top Level, but if you browse through CPAN, the reason for choosing descriptive names should become obvious after a while. This is something that people agonize about on the module-authors mail list. Don't you want people to use your module, rather than duplicating it out of ignorance? How are they going to find it when the module directory starts to page? Plan for a very big future or there won't be one.

On a separate and mostly unrelated rant, I see some people denigrating Perl6 as people's "hobby language". (it wasn't dagolden, but flashed past my eyes sometime in January)

What's so wrong with having a hobby and getting excited about it? The best thing in life (next to crushing your enemies, seeing them driven before you and hearing the lamentations of their support staff) is to be paid to do your hobby someday, n'est-ce pas? Now, I'm not going to stop writing Perl5 any time soon, but I am going to learn the new language eventually by gradually porting my old modules over, ready for the time that the Bug takes off. Looks like fun.

Like the advert says - Be more dog!


It would be nice if it was better organized but that's probably not going to be easy in such a decentralized project. In any case its no worse than npm or github. It makes discovery harder, yeah that's a problem, the only thing I can think of is we all need to talk more about the stuff that works for us.

The root namespace in Perl 6 module land is not the same as Perl 5 due to auth:

`use HTTP:ver(v1.0):auth('cpan:GMANE')`

This means your module's name does not have to be predetermined by the content storages (cpan, or any 3rd party that indexes/curates) it will uploaded to. Maybe the name 'HTTP' is already taken on cpan but not on $some-darkpan where it has to be named 'HTTP'.

Imagine an author moving something from a darkpan to a cpan service (some business open sourcing a piece of code). If the namespace they used internally is already taken on cpan, will they go through the trouble of converting everything to a new namespace or just say fuck it? Some would probably say fuck it, so the public would lose out on that code. But Perl 6 is bent on world domination so it will glady accept it because it has mechanisms for providing access to any number of modules named HTTP::SuperClient.

For indexing/discovering there are other attributes that are better suited such as the tags field of the META6. Namespaces as the main source of description does not work well, especially with the constraint of being unique; If I want to fetch a web page do I search Net::, HTTP::, Web::, WebService::...? This is not helpful. Instead of struggling to find a unique description to use as a namespace, you can use the best description (even if its not unique) and let the indexer search a different part of the meta data. We still have the problem of what tags one has to search for, but without the unique namespace restriction on the author (This could actually allow more consistent namespaces, as one does not have to look for prior art before naming their module HTTP::SuperClient or Net::SuperClient). But the point is that what is really needed is a better tool for searching/categorization.

Note: If someone does not wish to be explicit with their use and depends then naturally this could bite them in the ass. So being explicit with your use and depends would be a good practice.

Sometimes the taxonomy makes sense, and sometimes it's just annoying. That someone understands what the module does and how it relates to other modules should be the most important thing. A Chess module for games of Chess uses the most used meaning of the word and it probably doesn't have to relate to other modules (like HTTP::Request and HTTP::Response are related to each other, or how HTPP::Cookies::Mozilla relates to HTTP::Cookies).

I wouldn't want to see WebFramework::RouteBased::Mojolicious, for instance.

The error you're making is you're assuming Perl 6 module names function exactly like in Perl 5.

In Perl 5, the module names are unique identifiers and, to a large extent, the descriptive, searcheable name of a thing.

In Perl 6, the ambiguity among multiple 'Chess' modules is resolved with the :auth adverb and tags key in the META file addresses the issues about finding modules you raise.

In fact, I'd argue that your post is suggesting we repeat Perl 5's mistakes and release modules with wordy names to rectify the problems that no longer exist.

but trying to find out about them was tricky

It's documented in the S22 speculation, I believe:

use Mail:approved-by('LWALL')

That's not at all what I was talking about. The distribution's META file has a tags field that let any "distribution accumulators" (such as a CPAN site) to use those tags when trying to figure out what the user wants to find. Just like the posts on this website can be tagged with say, 'Perl 6' tag, and then searching for 'Perl 6' would bring up such articles.

So, I don't know where I would have run across the :auth tag if I hadn't spouted off which, to me, is a part of the process.

I don't think there's yet any decent support for the :auth adverb.

I'd like to be convinced that it "makes the easy things easy".

I won't be one to do that. IMO, the :auth adverb is no different ::Foo in module name. If you don't specify it explicitly, you leave an ambiguity in your code. I'm yet to learn how such an ambiguity is resolved and what its implications are. And so far, I'm of a negative opinion of using :auth as a way out of requiring unique distribution names, even if :auth addresses the concerns you brought up in the original post.

Leave a comment

About Enkidu

user-pic I am a Freelance Scientist** and Perl is my Igor.