Don't know what you mean ... all my examples were parenthesized so precedence problems shouldn't occur !?!

There was no example with slices but I think

€ar[1][5..6]    ==  @{ $ar->[1] } [5..6]
[download]

Actually it's practically impossible to implement this with a simple code-filter, (see my first approach) because one can't tell by static parsing where the dereferencing ends ( here the last array-index ) and where to put the closing curly.

Or do you mean it's not necessarily clear at compiletime if the last expression (here [5..6]) is a list and leads therefore to slicing-syntax???

Don't know what you mean ... all my examples were parenthesized so precedence problems shouldn't occur !?!

I mean exactly:

Actually it's practically impossible to implement this with a simple code-filter, (see my first approach) because one can't tell by static parsing where the dereferencing ends ( here the last array-index ) and where to put the closing curly.

In other words, you're arguing to add more syntax to Perl, syntax that's difficult to type, to make the simple cases easy (except that they're more difficult to type) -- except that the syntax doesn't actually make the difficult cases any easier, because either it's ambiguous to parse because of the precedence and associativity of the new dereferencing operator, or you enforce a fixed amount of dereferencing and have to use the existing syntax to isolate and disambiguate the reference.

I won't say that it's impossible to get this to work, but it's going to be very difficult, and the exceptions are probably going to be difficult to understand, and no one's going to use it.

          Contrary to Perl 6 my approach is still compatible, because you can transform them back into standard Perl 5.

      ... until the first time you run into a precedence problem, for example with hash or list slices.

    Don't know what you mean ... all my examples were parenthesized so precedence problems shouldn't occur !?!

I mean exactly:

    Actually it's practically impossible to implement this with a simple code-filter,...

My point is that the proposed transformation rules are well-defined and backwards-compatible within perl5, contrary to perl6. One can always take code with new sigils and transform it back into normal sigils and parentheses to run it with an old perl 5 version.

The implementation of these rules with static code filters can of course only be - like I already said - an ersatz to demonstrate the concept. This is certainly not meant for production.

For the realisation: If it's not possible to extend the perl parser accordingly, a real macro system is needed (which is N° 8 on my wishlist) That means changing the code after compilation but before execution!

>In other words, you're arguing to add more syntax to Perl, syntax that's difficult to type, to make the simple cases easy

well I think most languages, including perl6, consider it easier that arrays are primarily references and only transformed into a list if it's indicated by a modifier.

Maybe I should express these transformation rules with plain words instead of code, to make them clearer:

1. €arr is a scalar $arr which holds a array_ref
2. €arr[][] can be dereferenced without any arrow-operator, that means is identical to $arr->[]->[].
3. Dereferencing of €arr has higher precedence than transformation to an array:  @€arr[][] == @{€arr[][]}
4. In situations where the parser wants an array to follow (*), e.g. forced by prototype (\@) , €arr is passed directly. That means push €arr,expr is identical to push @$arr,expr
I think all perl-experts (like you are), might think it's getting more complicated this way, but I bet most beginners will consider it much easier and experts will adapt easily. Because it's huffman-coded, the frequent use cases are getting much easier, and the others don't get more complicated! And IMHO anyway there is no need anymore to use @arr or %hash if one can seemlesly use references!

Cheers Rolf

(*) more precisely in these situations an @ has to follow but only the reference is passed.