new compilation tutorial #3082
new compilation tutorial #3082
Conversation
doc/Language/compilation.pod6
Outdated
|
|
||
| When looking through candidates, the Installation repository will smart match a module's long name against this | ||
| DependencySpecification or rather the individual fields against the individual matchers. | ||
| Thus a matcher may be some concrete value, a version range or even a regex. |
There was a problem hiding this comment.
or even a regex
This is not entirely valid. For instance .api-matcher and .version-matcher will always be used via~~ Version.new($foo.api-matcher). i.e. the user should not expect an .api-matcher of /.*/ to do anything useful.
There was a problem hiding this comment.
What would be a better way of saying this?
Perhaps an example such as C<:ver(+3.0.1)> ?
There was a problem hiding this comment.
api/ver-matcher take a string that will be turned into a Version for comparisons, which does include 3.0.1+ (but not +3.0.1).
|
|
||
| C<Raku> has both paradigms. At the B<top level> a Raku program is interpreted, but if code that is separated out into a | ||
| Module will be compiled and the preprocessed version is then loaded when necessary. In practice, Modules that have been | ||
| written by the community will only need to be pre-compiled once by a user when they are 'installed', for example by a |
There was a problem hiding this comment.
Why the caps for Modules? Also, any module is going to be pre-compiled, not only those written by the community.
| =item when developing a new program a developer may want to have the modules written by both Alice and Bob installed locally. | ||
| So it is not possible simply to have only one version of a module with a single name installed. | ||
|
|
||
| C<Raku> enables all of these possibilities, allowing for multiple versions, multiple authorities, and multiple APIs to be present |
There was a problem hiding this comment.
Here "difficulties" become "possibilities", and "enabled" by Raku. Maybe you meant "tackles all these difficulties"? Or maybe you meant possibilities instead of difficulties above?
There was a problem hiding this comment.
Ah. Interesting. They are difficulties in other langages, but resolved in Raku, so they become possibilities.
But I will reword
| is explained L<elsewhere|Language/typesystem#Versioning_and_authorship>. This tutorial is about how C<Raku> handles these | ||
| possibilities. | ||
|
|
||
| =head1 Introduction |
There was a problem hiding this comment.
If the introduction starts here, what's all that above this?
There was a problem hiding this comment.
Introduction is where niner's talk starts. Before was my preface.
There was a problem hiding this comment.
Can you maybe just change the section name?
| The Installation repository is where the real smarts are. When requesting a module, you will usually either do it | ||
| via its exact long name, or you say something along the lines of "give me a module that matches this filter". | ||
| Such a filter is given by way of a C<CompUnit::DependencySpecification> object which has fields for | ||
| =item short-name, |
There was a problem hiding this comment.
Undocumented, too. You can't link it, but please open an issue so that's it's documented or index it so that anyone looking for it arrives here.
Documenting PrecompUnit
Issue #3043
New tutorial
Although this does not address the issue directly, the aim is to provide more context for developers and users than is currently available. The tutorial is based on niner's talk. It was in a link he provided in issue #502