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:
Cheers Rolf
(*) more precisely in these situations an @ has to follow but only the reference is passed.
In reply to Re^8: Two more Features Perl 5 Maybe Needs
by LanX
in thread Five Features Perl 5 Needs Now
by Arunbear
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |