Syntax of "use"/"require"
Rob Kinyon
I'd like to start writing the Module::Build/ExtUtils::MakeMaker for
Pugs. One of the first things that was mentioned was that the syntax
for use needs to support specifying the exact version or range of
versions you want to have. There has also been mention of the fact
that module installation needs to tag the author, as well as other
features.
Would someone please mind listing all the functionality desired for
module installation as seen from "use"?
Thanks,
Rob
Rob Kinyon
Note: I've read S11. I was asking more for the backstory.
1) Does this mean that there can be two different Dog-1.2.1, one by
cpan:JRANDOM and another by cpan:KRANDOM?
2) Is @INC still searched in order, providing the first one that
matches the full specification?
Some related questions:
1) Is it possible for "use" to expose the functionality it uses to
find the right module to other modules? For example, the module
installer I want to write would have to have that logic and I'd rather
not duplicate it.
2) That functionality I referred to - theorbtwo on Perlmonks asked for
the ability to provide mixins that would direct how some of the
functionality worked. Would this be possible?
3) The P6 version of XS - will it be handled at the VM level or the
Perl level? I'm assuming the VM level, which then leads to:
4) "use" and non-Perl code - One of the touted things about using
Parrot is that a P6 program will be able to access code in any
language that targets Parrot. How on earth will that work?
5) Mixed-language distributions - how should a P6 distro builder
handle that? How should a P6 distro installer handle that? How should
C6PAN handle that?
6) Is there a useful distinction to be made between modules/classes
and distributions? I think there is when discussing uninstalling. I
install Dog and it provides Dog::Retriever. If I uninstall Dog, it
should also uninstall Dog::Retriever.
7) This leads to the thought that a distribution should have a name
separate from any of the components within it. I expect that, like URI
or Template Toolkit, there will be a component in the distribution
that has the same name as the distro, but that will be custom and not
law.
Sorry for the self-reply, but I realized I hadn't provided enough information.
Thanks,
Rob
Rod Adams
>On 5/28/05, Rob Kinyon <rob.k...@gmail.com> wrote:
>
>
>>(This thread is referencing http://www.perlmonks.org/?node_id=461105)
>>
>>I'd like to start writing the Module::Build/ExtUtils::MakeMaker for
>>Pugs. One of the first things that was mentioned was that the syntax
>>for use needs to support specifying the exact version or range of
>>versions you want to have. There has also been mention of the fact
>>that module installation needs to tag the author, as well as other
>>features.
>>
>>Would someone please mind listing all the functionality desired for
>>module installation as seen from "use"?
>>
>>
>
>Note: I've read S11. I was asking more for the backstory.
>
>1) Does this mean that there can be two different Dog-1.2.1, one by
>cpan:JRANDOM and another by cpan:KRANDOM?
>
>
Yes
>2) Is @INC still searched in order, providing the first one that
>matches the full specification?
>
>
No, it searches for the _best_ match. Best is defined by first filtering
based on given Name/Version/URI conditions given in the use statement.
Then it picks the highest version number. If there are still multiple
candidates around, I believe Larry settled on throwing an error, rather
than create a tiebreaker that authors would jockey for on CPAN.
>Some related questions:
>1) Is it possible for "use" to expose the functionality it uses to
>find the right module to other modules? For example, the module
>installer I want to write would have to have that logic and I'd rather
>not duplicate it.
>
>
Likely yes, but I think that might be a p6c question.
>2) That functionality I referred to - theorbtwo on Perlmonks asked for
>the ability to provide mixins that would direct how some of the
>functionality worked. Would this be possible?
>
>
"All's fair if you predeclare". At a minimum you could redefine the part
of the grammar that parses and evaluates the "use" statements. Higher
levels of exposure have not been discussed, AFAIK. Proposals welcome.
>3) The P6 version of XS - will it be handled at the VM level or the
>Perl level? I'm assuming the VM level, which then leads to:
>
>
Definitely VM.
>4) "use" and non-Perl code - One of the touted things about using
>Parrot is that a P6 program will be able to access code in any
>language that targets Parrot. How on earth will that work?
>5) Mixed-language distributions - how should a P6 distro builder
>handle that? How should a P6 distro installer handle that? How should
>C6PAN handle that?
>6) Is there a useful distinction to be made between modules/classes
>and distributions? I think there is when discussing uninstalling. I
>install Dog and it provides Dog::Retriever. If I uninstall Dog, it
>should also uninstall Dog::Retriever.
>7) This leads to the thought that a distribution should have a name
>separate from any of the components within it. I expect that, like URI
>or Template Toolkit, there will be a component in the distribution
>that has the same name as the distro, but that will be custom and not
>law.
>
>
I don't think any of this has been deeply considered yet.
Here are my musings on the topic after roughly 45 seconds of thought:
Rather than have a concept of a "perl 6" libpath, only have a "parrot"
libpath. Then, whenever a module is searched for, it matches against
anything in the parrot repository, which would contain all parrot
bytecode, from various source languages. Therefore, installing mixed
language packages is simply a matter of shipping pre-compiled versions
of the library out, and there may be a split between bytecode/doc
distros, and full source distros.
I have no thoughts on how to handle the (un)installation of collections.
-- Rod Adams