in reply to Re^2: Two more Features Perl 5 Maybe Needs
in thread Five Features Perl 5 Needs Now

Quoting part of that might help separate out a lot of false positives.

Results 1 - 93 of 93 for perl beginner problem "nested arrays"

  • Comment on Re^3: Two more Features Perl 5 Maybe Needs

Replies are listed 'Best First'.
Re^4: Two more Features Perl 5 Maybe Needs
by LanX (Saint) on Dec 21, 2008 at 19:19 UTC
    I don't know how to produce an accurate google statistic for the biggest beginner problem. You might also search for "arrays of arrays" (1490 results), or compare the stats for other common obstacles like "list context".

    But I bet the non-reference character of @array will be the number one or at least on top three.

    Almost every propaganda against perl I've seen so far lists this as a problem, and I haven't met any perl hacker til now, who didn't run into this trap.

    I just wanted to propose extended sigils helping to destroy this argument without breaking compability like perl6 does.

    And these sigils can be seen as a replacement of the PBP-rule to flag every reference variable with a trailing "_ref".

    Which symbols to choose for these sigils is a matter of debate, since the characters less than 128 are already overloaded with syntactical meaning. Especially € is mapped on different positions.

    UPDATE:

    I know some people who decided only to use refs of arrays and hashes to avoid these problems. I tried this myself, but it's not that easy. e.g. you cant write push $arr_ref, expr;, slices with -> are not possible $arr_ref->[1..5] and nested structures need to be put in parens to get the listform: 
    for ( @{ $arr_ref->[idx1][idx2] } ) {
  ...
}

    [download]
    compare this with 
    push €arr, expr; # (*)
€arr[1..5];
for ( @€arr[idx1][idx2] ) { ... };

    [download]
    (*) prototype mechanism has to be extended for this.
[reply]
[d/l]
[select]

      I can tell you feel strongly about it, but I remain utterly and absolutely unconvinced that Perl needs to add more sigils in order to stay relevant. In fact, I believe that that would be going in exactly the wrong direction. Perl should drop sigils entirely. That would do a lot to convince the rest of the programming world that Perl is, or even could be, relevant.

      (Of course, making such a change would entail changing other aspects of the language, such as context. But that would be OK, imho. Whatever is necessary to kill the sigil silliness.)

      Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
[reply]
        Perl should drop sigils entirely.

        Having actually patched the Perl 5 parser and lexer multiple times, I'm going to pull an argument from authority and say that if you like never getting new features in Perl, dropping the sigils is a wonderful idea.

        To make Perl work without sigils, you probably have to drop context, you definitely have to drop barewords, you likely have to drop prototypes, you may have to drop import() in some cases, and you can probably get rid of BEGIN. Alternately, you have to namespace or prefix new keywords to prevent collisions.

        I can't imagine a pleasant result.

[reply]
[d/l]
[select]
        Perl should drop sigils entirely.

        No! The conveniences of having sigils surely outweigh the inconveniences (whatever they are). Although, I know naught of other languages so I cannot give a convincing argument to why things should or should not change. I can, however, say that the current way works great for me :D

        That would do a lot to convince the rest of the programming world that Perl is, or even could be, relevant.

        I think I am confused about the word 'relevant' in this discussion. Relevant to what?

        And you didn't even know bears could type.

[reply]
        Well Princes of Perlport ... Sigils or not sigils, is this here the question?

        Many styleguides in many languages tell the programmers to use a naming convention e.g. special post- or prefixes to distinguish which datatype you use. (e.g. Hungarian notation)

        For me, well done sigils are just a build-in naming convention and perl6 tries to go this way, by making @arr[1] acting like $arr[1].

        And IMHO Perl without sigils already exists, it's called Ruby! ; )

        UPDATE: seriously, changing the parser such that he accepts variables without sigils IMHO results in reinventing Ruby...

[reply]
[d/l]
[select]

In Section Perl News