FAQ
Hello,

I've been experimenting with Perl 6 for quite a while, and so now and
then I upgrade my Rakudo installation. Today, I upgraded to Rakudo
star.

I have some issues with the behavior related to array references and
their actual replacements known as "captures" (as far as I'm correct).

Suppose that I do this:

my $x = [3, 4]; my @y = 1, 2, $x, 5, 6; say @y.perl;

Then I'll get `[1, 2, [3, 4], 5, 6]`, but if I do this...

my @x = (3, 4); my @z = 1, 2, \@x, 5, 6; say @z.perl;

...then, some time ago, I got `[1, 2, [3, 4], 5, 6]`;

...but nowadays I get `[1, 2, \(3, 4), 5, 6]`.

I expected the behavior from some time ago, actually. Is that wrong?

`@y[2].WHAT` results in 'Array()',
`@z[2].WHAT` results in 'Capture()'

...but are they really different in behavior? Are there any caveats?
If so, what is the proper way to get the "old" behavior? Is that
even necessary?

And what about this?...

my $x = [3, 4]; my @y = 1, 2, |$x, 5, 6; say @y.perl;

...I actually expected `[1, 2, 3, 4, 5, 6]`, since I was under the
impression that the '|' was some kind of "flatten" or
"interpolation" operator.

But I got `[1, 2, \(3, 4), 5, 6]` instead.

How can I do this? Is this normal behavior? I find this confusing,
but perhaps there is some deeper hidden meaning?

Perhaps it is language nit-picking, but I'm really curious.

Thanks,

Greetings,

Raymond.

Search Discussions

  • Darren Duncan at Jul 30, 2010 at 3:55 am

    R. Dresens wrote:
    I have some issues with the behavior related to array references and
    their actual replacements known as "captures" (as far as I'm correct).
    Captures are not replacements for Arrays in general; they serve different purposes.

    Use an Array when you want to have a simple ordered collection of items, like in
    any language.

    Use a Capture when you want to have a collection of arguments for a routine,
    especially when there's a mixture of positional or named or other complexities.

    You could say a Capture is a replacement for the @_ of Perl 5 though.

    At least that's my understanding of it.

    I would imagine that in most code an Array is what you want.

    -- Darren Duncan
  • Richard Hainsworth at Jul 30, 2010 at 7:24 am
    The number of modules available to proto has grown considerably.

    I am not aware that there is a convenient way of obtaining a short
    description about each module, other than just the name?

    In order to make the perl6 internet-wide environment useful, there needs
    to be some form of directory information.

    I think its an excellent idea that modules are held in a distributed
    manner - git seems to be the preferred system at present - rather than
    having a centralised depository. But this means that there needs to be a
    central registory and some minimum documentation/metadata standards.

    proto already has a list of modules and their locations.

    Would it be possible to require that any module listed in the proto list
    should also have a file METADATA in the root directory of the module's
    depository? This file should contain (in pod format??) a minimum number
    of sections, eg.,
    SUMMARY
    AUTHOR
    REVISION
    LICENSE
    LASTUPDATE

    proto inclusion already requires a dependency file, and /t and /lib
    directories are provided for.

    If all modules conform to a minimum metadata standard, then it would be
    possible to write tools that access the proto projects.list, then access
    each project and extract the metadata, dependency checking,
    absence/presence of tests.

    The user can then decide which modules to download with proto.
  • Moritz Lenz at Jul 30, 2010 at 8:31 am

    Am 30.07.2010 09:24, schrieb Richard Hainsworth:
    The number of modules available to proto has grown considerably.

    I am not aware that there is a convenient way of obtaining a short
    description about each module, other than just the name?
    http://modules.perl6.org/ contains a short description, which is the
    tagline from the github repository.

    Would it be possible to require that any module listed in the proto list
    s/require/suggest/
    should also have a file METADATA in the root directory of the module's
    depository? This file should contain (in pod format??) a minimum number
    of sections, eg.,
    SUMMARY
    AUTHOR
    REVISION
    LICENSE
    LASTUPDATE

    proto inclusion already requires a dependency file,
    No. It's perfectly fine to have none, if the module has no other Perl 6
    modules as dependencies
    and /t
    Also optional.

    Which is exactly the point: proto tries not to be intrusive, and tries
    to impose little structure on the modules it can distribute.
    If all modules conform to a minimum metadata standard, then it would be
    possible to write tools that access the proto projects.list, then access
    each project and extract the metadata, dependency checking,
    absence/presence of tests.
    Agreed. Though the "minimum metadata standard" should be about the file
    format of the meta data, not about presence of certain information.

    Things like LASTUPDATE and REVISION look superfluous to me, that can be
    obtained from the repo meta data.

    Some kind of meta data standard should exists, I guess that'll be a good
    topic for discussion at YAPC::EU (I'm looking at you, Martin and Carl :-)

    Cheers,
    Moritz
  • Richard Hainsworth at Aug 2, 2010 at 8:48 am

    On 07/30/2010 12:31 PM, Moritz Lenz wrote:
    Am 30.07.2010 09:24, schrieb Richard Hainsworth:
    Would it be possible to require that any module listed in the proto list
    s/require/suggest/
    proto inclusion already requires a dependency file,
    No. It's perfectly fine to have none, if the module has no other Perl
    6 modules as dependencies <snip>
    Which is exactly the point: proto tries not to be intrusive, and tries
    to impose little structure on the modules it can distribute.
    Fair enough.
    If a module does not have a METADATA file, then information about it
    cannot be gathered and shared, which will make it a poor target for others.
    That should provide the incentive to include data.

    Time to write a proof of concept tool....

    Richard
  • Steffen Schwigon at Jul 30, 2010 at 9:27 am

    Richard Hainsworth writes:
    The number of modules available to proto has grown considerably.

    I am not aware that there is a convenient way of obtaining a short
    description about each module, other than just the name?
    Just an opinion: imho every effort should go towards integrating CPAN
    in any way.

    Perl without CPAN feels like Kung-Fu on stack-heel shoe.

    Maybe any of those META2.0, cpanminus, CPAN::Packager,
    CPAN::Dpendency, MyCPAN::*, POD6 thingies could be assembled into
    something to integrate Perl6 with CPAN?

    And, yes, I consider it valid to have a Perl5 toolchain doing that.

    Kind regards,
    Steffen
    --
    Steffen Schwigon <ss5@renormalist.net>
    Dresden Perl Mongers <http://dresden-pm.org/>
  • Jan Ingvoldstad at Jul 30, 2010 at 11:52 am

    On Fri, Jul 30, 2010 at 11:27, Steffen Schwigon wrote:

    Just an opinion: imho every effort should go towards integrating CPAN
    in any way.

    Perl without CPAN feels like Kung-Fu on stack-heel shoe.

    Maybe any of those META2.0, cpanminus, CPAN::Packager,
    CPAN::Dpendency, MyCPAN::*, POD6 thingies could be assembled into
    something to integrate Perl6 with CPAN?

    And, yes, I consider it valid to have a Perl5 toolchain doing that.
    There is a problem with that, and that is that we may want to re-use the
    same package names that are already in use on CPAN, in order to avoid evil
    Klingon naming contortions (good Klingon naming contortions are of course
    QaQ).

    I also think that it's important packages are cryptographically signed by
    their maintainers.
    --
    Jan
  • Darren Duncan at Jul 30, 2010 at 6:07 pm

    Jan Ingvoldstad wrote:
    On Fri, Jul 30, 2010 at 11:27, Steffen Schwigon wrote:
    Just an opinion: imho every effort should go towards integrating CPAN
    in any way.

    Maybe any of those META2.0, cpanminus, CPAN::Packager,
    CPAN::Dpendency, MyCPAN::*, POD6 thingies could be assembled into
    something to integrate Perl6 with CPAN?
    There is a problem with that, and that is that we may want to re-use the
    same package names that are already in use on CPAN, in order to avoid evil
    Klingon naming contortions (good Klingon naming contortions are of course
    QaQ).
    I believe that there were good proposals for this made as well as specced a few
    years ago for a new or updated format for distributions and metadata so that it
    would work for multiple programming languages.

    I don't recall the url ATM, though it may be in the Pugs repo.

    Part of the deal was having several pieces of metadata that combined for the
    fully-qualified name of a module, such as language (eg, Perl_6 vs Perl_5 vs
    doc-only vs Javascript etc) plus base name (eg, Foo::Bar::Baz) plus authority
    (eg, cpan:DUNCAND or http://example.com) plus version (eg, 1.2.3).

    Done this way, distinct languages can have the same module base name
    (Foo::Bar::Baz) but the Perl_6 or Perl_5 part would effectively make them not
    conflict. Similarly, differing authorities wouldn't conflict, as each one would
    typically represent a fork.

    A related example from the Perl 6 spec (S11):

    use Whiteness:from<perl5>:name<Acme::Bleach>:auth<cpan:DCONWAY>:ver<1.12>;
    use Whiteness:from<perl5 Acme::Bleach cpan:DCONWAY 1.12>; # same thing

    ... this that the metadata would generalize.

    I *really* want to use a multi-language-savvy spec like this to distribute with.

    -- Darren Duncan
  • Guy Hulbert at Jul 30, 2010 at 6:21 pm

    On Fri, 2010-30-07 at 11:07 -0700, Darren Duncan wrote:
    I *really* want to use a multi-language-savvy spec like this to
    distribute with.
    CPAN will also have to be able to handle modules written in arbitrary
    natural languages (chinese, arabic etc) will it not ?

    --
    --gh
  • Richard Hainsworth at Jul 30, 2010 at 12:08 pm

    On 07/30/2010 01:27 PM, Steffen Schwigon wrote:
    Richard Hainsworth<richard@rusrating.ru> writes:
    The number of modules available to proto has grown considerably.

    I am not aware that there is a convenient way of obtaining a short
    description about each module, other than just the name?
    Just an opinion: imho every effort should go towards integrating CPAN
    in any way.

    Perl without CPAN feels like Kung-Fu on stack-heel shoe.

    Maybe any of those META2.0, cpanminus, CPAN::Packager,
    CPAN::Dpendency, MyCPAN::*, POD6 thingies could be assembled into
    something to integrate Perl6 with CPAN?

    And, yes, I consider it valid to have a Perl5 toolchain doing that.
    Perl5 toolchain - not the issue: proto is a perl5 script!

    CPAN as a concept is not the issue. CPAN IS what makes perl so superior.

    The problem at the moment is the variety of suggested enhancements to
    CPAN, which does have its own issues.

    There is an inevitable transition period between now (the release of the
    Rakudo Star distribution) and some point down the timeline when it will
    become clear how to arrange a CPAN-type setup for Perl6 (not just the
    Rakudo implementation of perl6).

    All I am suggesting is that the directories containing modules also
    contain a METADATA file with some standard items, and that this metadata
    is required for a module that is registered. Even if there is a CPAN
    system, the metadata would still be needed, so there is no extra work
    for developers.
  • Guy Hulbert at Jul 30, 2010 at 1:42 pm

    On Fri, 2010-30-07 at 16:08 +0400, Richard Hainsworth wrote:
    All I am suggesting is that the directories containing modules also
    contain a METADATA file with some standard items, and that this
    metadata
    is required for a module that is registered. Even if there is a CPAN
    system, the metadata would still be needed, so there is no extra work
    for developers.
    I'd like a better cpan ... i don't know exactly what that is but ...

    1. I tend to discover good modules by accident.
    2. I don't like huge lists of dependencies.
    3. I found that the 'cpan' command caches index files
    which are easy to search with 'grep' -- at least for module names

    So it would nice if the METADATA format were incrementally downloadable.

    It might be nice if CPAN were segmented so partial mirrors were useful
    as long as the METADATA is complete on each mirror. A peer-to-peer
    network would be interesting ...

    As everyone is using github now perhaps using git as the storage format
    would be better than tar ...

    --
    --gh
  • Patrick R. Michaud at Jul 30, 2010 at 4:33 pm

    On Fri, Jul 30, 2010 at 04:08:49PM +0400, Richard Hainsworth wrote:
    On 07/30/2010 01:27 PM, Steffen Schwigon wrote:
    Richard Hainsworth<richard@rusrating.ru> writes:
    I am not aware that there is a convenient way of obtaining a short
    description about each module, other than just the name?
    Perl without CPAN feels like Kung-Fu on stack-heel shoe.
    CPAN as a concept is not the issue. CPAN IS what makes perl so superior.

    The problem at the moment is the variety of suggested enhancements
    to CPAN, which does have its own issues.

    There is an inevitable transition period between now (the release of
    the Rakudo Star distribution) and some point down the timeline when
    it will become clear how to arrange a CPAN-type setup for Perl6 (not
    just the Rakudo implementation of perl6).
    Amen.

    Speaking as the overall manager for Rakudo-related stuff, Rakudo's
    current stance on anything module-management related is going to be
    "rough consensus and running code". In other words, ideas and
    proposals are welcomed, but actual code and implementations are
    likely to have the greatest influence on the ultimate details and
    specfication.
    All I am suggesting is that the directories containing modules also
    contain a METADATA file with some standard items, and that this
    metadata is required for a module that is registered. Even if there
    is a CPAN system, the metadata would still be needed, so there is no
    extra work for developers.
    I would also like to express a desire that we follow many of the principles
    expressed by Miyagawa's excellent "cpanminus" utility[1] for CPAN. In
    particular, it should be possible to have a basic module installer and
    manager that performs basic module functions and has few (ideally zero)
    external module dependencies.

    Pm

    [1] http://search.cpan.org/~miyagawa/App-cpanminus-1.0006/lib/App/cpanminus.pm
  • R. Dresens at Jul 30, 2010 at 4:26 pm

    On Thu, 29 Jul 2010 20:55:39 -0700 Darren Duncan wrote:

    R. Dresens wrote:
    I have some issues with the behavior related to array references
    and their actual replacements known as "captures" (as far as I'm
    correct).
    Captures are not replacements for Arrays in general; they serve
    different purposes.
    Yes, but aren't captures somehow replacements for references in
    general... and therefore also array references? The reason why I
    assume that is that I (wrongly?) expected a "real" 'Array()' when I
    used the `\` prefix in an expression such as `\@x`. `@x` is an
    array, but ` \@x` has become a 'Capture()' in recent rakudo
    releases, not an 'Array()' anymore. Hence my assumption.

    ...but an "anoymous array" (if I may call it that?) assigned to `$x`
    is still an 'Array()'. So I'm really confused about the
    intricate difference between...

    my $x = [1, 2, 3]

    ...and...

    my @y = (1, 2, 3); my $x = \@y

    ...apart from the question whether it has really an impact on
    practical code. I'm more or less trying to create a model of perl 6
    in my mind right now, and I really wonder how to explain this
    behavior.
    You could say a Capture is a replacement for the @_ of Perl 5
    though.
    At least that's my understanding of it.
    Indeed,

    But there seems to be more than meets the eye here, and I'm
    a little confused about that.

    The official specs probably contain the answer, but I haven't
    found it yet. Let's see what this weekend brings ;)

    Greetings,

    Raymond.
  • Leon Timmermans at Jul 30, 2010 at 5:06 pm

    On Fri, Jul 30, 2010 at 6:21 PM, R. Dresens wrote:
    Yes, but aren't captures somehow replacements for references in
    general... and therefore also array references? The reason why I
    assume that is that I (wrongly?) expected a "real" 'Array()' when I
    used the `\` prefix in an expression such as `\@x`.  `@x` is an
    array, but ` \@x` has become a 'Capture()' in recent rakudo
    releases, not an 'Array()' anymore. Hence my assumption.
    Captures in Perl 6 are needed much less than references in Perl 5.
    That's a feature, not a bug. References often make things more
    confusing that they should be. You shouldn't need captures in most
    Perl 6 code.
    ...but an "anoymous array" (if I may call it that?) assigned to `$x`
    is still an 'Array()'. So I'm really confused about the
    intricate difference between...

    my $x = [1, 2, 3]

    ...and...

    my @y = (1, 2, 3); my $x = \@y
    The latter should be written as

    my @y = (1, 2, 3); my $x = @y;

    Yeah, that requires some unlearning of Perl 5 idioms. $x and @Y are
    indeed mostly the same, except that @y acts listy and $x not.
    ...apart from the question whether it has really an impact on
    practical code. I'm more or less trying to create a model of perl 6
    in my mind right now, and I really wonder how to explain this
    behavior.
    I think the crucial step it to stop thinking you need the \ operator
    for anything until you really need it.

    Leon
  • R. Dresens at Jul 31, 2010 at 7:19 am

    On Fri, 30 Jul 2010 19:06:09 +0200 Leon Timmermans wrote:

    On Fri, Jul 30, 2010 at 6:21 PM,
    R. Dresens wrote:
    is still an 'Array()'. So I'm really confused about the
    intricate difference between...

    my $x = [1, 2, 3]

    ...and...

    my @y = (1, 2, 3); my $x = \@y
    The latter should be written as

    my @y = (1, 2, 3); my $x = @y;
    ...and my @x = (3, 4); my @z = 1, 2, \@x, 5, 6;

    ...should be my @x = (3, 4); my @z = 1, 2, $(@x), 5, 6;

    This does what I expect/want (especially when I `@x.push(4.5)`).
    Yeah, that requires some unlearning of Perl 5 idioms. $x and @Y are
    indeed mostly the same, except that @y acts listy and $x not.
    That's actually my biggest hurdle at this moment: I write Perl 5
    code almost every work day.

    Thanks,

    Greetings,

    Raymond.
  • Leon Timmermans at Jul 30, 2010 at 12:31 pm

    On Thu, Jul 29, 2010 at 8:30 PM, R. Dresens wrote:

    And what about this?...

    my $x = [3, 4]; my @y = 1, 2, |$x, 5, 6; say @y.perl;

    ...I actually expected `[1, 2, 3, 4, 5, 6]`, since I was under the
    impression that the '|' was some kind of "flatten" or
    "interpolation" operator.

    But I got `[1, 2, \(3, 4), 5, 6]` instead.

    How can I do this? Is this normal behavior? I find this confusing,
    but perhaps there is some deeper hidden meaning?
    I think that you meant to do is this:

    my $x = [3, 4]; my @y = 1, 2, @($x), 5, 6; say @y.perl; # untested

    Leon
  • R. Dresens at Jul 30, 2010 at 4:30 pm

    On Fri, 30 Jul 2010 14:31:31 +0200 Leon Timmermans wrote:
    On Thu, Jul 29, 2010 at 8:30 PM, R. Dresens wrote:

    And what about this?...
    my $x = [3, 4]; my @y = 1, 2, |$x, 5, 6; say @y.perl;
    I think that you meant to do is this:

    my $x = [3, 4]; my @y = 1, 2, @($x), 5, 6; say @y.perl;
    Yes, that works!

    Thanks,

    Greetings,

    Raymond.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-users @
categoriesperl
postedJul 29, '10 at 6:36p
activeAug 2, '10 at 8:48a
posts17
users9
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase