in reply to Two more Features Perl 5 Maybe Needs
in thread Five Features Perl 5 Needs Now

I most wholeheartedly agree with the 6., but do not see any need for the 7. The sigils we have are great, the system works and makes sense (and the change in the system of sigils is gonna cause a heluva lot of wasted time while seasoned Perl5 developers struggle to relearn sigils working the Perl6 way), but there is no need to complicate it any more. BTW, IMnsHO the changes to sigils and the concatenation and method call operators were both bad ideas.

Besides, after a lot of thinking, I (hopefully correctly) inferred the intended meaning of the array examples, but still have no idea whatsoever what did you mean by the first line.

Jenda
Support Denmark!
Defend the free world!

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

Replies are listed 'Best First'.
Re^2: Two more Features Perl 5 Maybe Needs
by LanX (Saint) on Dec 22, 2008 at 04:11 UTC
    The new sigils represent all references. The currency symbols are just other representations of $.

    So ¥hr={} means $hr={} and analogous with €ar=[] but the handling is easier. 

    --- New                --- Internally
¥hr                ==  $hr
¥hr{k1}            ==  $hr->{k1}  
¥hr{k1}=¥hr2       ==  $hr->{k1} = $hr2
keys ¥hr           ==  keys %$hr
keys ¥hr{k1}{k2}   ==  keys %{ $hr->{k1}{k2} }
print €ar[1]       ==  print $ar->[1]
print @€ar[1]      ==  print @{ $ar->[1] }

    [download]
    hope that's clearer ...

    Tomorrow I'll try to hack a codefilter as a proof of concept.

    Actually if point 7 is realized, one don't really need point 6 any more ... 

     
sub foo {
  return ( [], {} ) 
}
my (€ar,¥hr) = foo();

    [download]

    But your right the first line was misleading! ... I got confused with the new idea of compability to perl6 syntax...but now I think that's far to complicated to achieve with the perl5 parser.

[reply]
[d/l]
[select]

      The additional sigils complicate Perl, the aliases would simplify it. With the aliases I could declare a hash as being the same as the one referenced by some complicated expression, with the sigils I would still have to make distinction between a hash and a hash ref and the only thing I would save is an ocassional -> or %{}. For the price of introducing another special character.

      Lexical aliases should have been in the language since 5.0. Additional sigils should not be there at all. IMHO of course.

      Jenda
      Support Denmark!
      Defend the free world!

[reply]
        > with the sigils I would still have to make distinction between a hash and a hash ref

        why??? €arr is an arr_ref ¥hash is a hash_ref nothing else. You wouldn't need to use @arr and %hash anymore (but you still could, if you want, it's compatible)

        > the only thing I would save is an ocassional -> or %{}

        well following PBP I always try to postfix references with _ref, or sometimes with "_aref", "_href" and "_cref". With more sigils there is no need for this anymore. And "occasional" @{} are really ugly to read.

        what is easier to read and maintain?

        for $x ( @{ $hash_ref->{k1}[2] } { ...}

        or

         for $x ( @¥hash{k1}[2] ) { ... }

        as a subconscious proof of bad maintainability I forgot a paren in the first example.

        You are already used to all these occasional extra symbols, but try to think about beginners who struggle to understand them and eventually switch to other languages.

        I can understand that symbols beyond char 127 are not optimal, but the perlparser is so overloaded with antique features and patches that you can't move a millimeter anymore. Just have a look at how complex it is to allow slices with hash- and array-refs! Slicing with Arrow-Operator possible in 5.12?

        This could be cleaned up with € and ¥. And contrary to perl6 my approach is still compatible, because you can transform them back into standard perl5.

        Cheers Rolf

[reply]
[d/l]
[select]

In Section Perl News