Re^7: Two more Features Perl 5 Maybe Needs

a built-in naming convention

That's sounds paradoxical; and in any case seems to violate the timtowtdi spirit of Perl.

by making @arr[1] acting like $arr[1]

And that's part of my argument: One of the few situations where sigils actually serve a constructive semantic purpose is being eliminated. Sigils are being rendered more gratuitous, not less. And sigils clearly violate the "Huffman encoding" philosophy of Perl grammar.

Anyway, I've argued this in the past, and it's clear that @larry are quite undivorceably married to the idea of sigils, so they're staying. I have faith that Perl can cling to its relevance by other means.

it's called Ruby!

Need I say more.

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

Replies are listed 'Best First'.
Re^8: Two more Features Perl 5 Maybe Needs by LanX (Saint) on Dec 21, 2008 at 21:34 UTC
> That's sounds paradoxical; and in any case seems to violate the timtowtdi spirit of Perl. Well my "language" might be creative but I think you got the point! ; ) But I can't imagine to easily eliminate sigils while continuing the mechanisms of perl's contexts... I'd prefere having even more sigils, also for coderefs and objects, since single symbols are better to read than ..._cref, ..._aref, ..._href and ..._oref >> it's called Ruby! > Need I say more. Actually Ruby HAS sigils ... just at other places! And I really like the concept e.g. of distinguishing instance- and class-variables! While it's ugly to double sigils `@@classvar` it's much more readable to write `@instvar` than `$self->{instvar}` So for readability I'm in favour of much more sigils! And by making them optional to use: `use Sigil qw{ € Ą ˘ ° };` [download] you still have MTOWTDI! I'd ask "so why don't you use Ruby straight away?" if the answer wouldn't be obvious... "Because it's not compatible with CPAN". So compability must be the crucial feature of any language extension. New sigils beyond standard ASCII can lead to this compability without many conflicts with old code. either in the coderange from 128-255 or Unicode! Keymapping of the editor might be a problem, so there might be a fallback solution like `$@arr` instead of `€arr`, like the fallback solution in perl6 for » with >>. and all these extra sigil could be automatically translated in plain perl code.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^8: Two more Features Perl 5 Maybe Needs
by LanX (Saint) on Dec 21, 2008 at 21:34 UTC

> That's sounds paradoxical; and in any case seems to violate the timtowtdi spirit of Perl.

Well my "language" might be creative but I think you got the point! ; )

But I can't imagine to easily eliminate sigils while continuing the mechanisms of perl's contexts...

I'd prefere having even more sigils, also for coderefs and objects, since single symbols are better to read than ..._cref, ..._aref, ..._href and ..._oref

>> it's called Ruby!
> Need I say more.

Actually Ruby HAS sigils ... just at other places!

And I really like the concept e.g. of distinguishing instance- and class-variables! While it's ugly to double sigils @@classvar it's much more readable to write @instvar than $self->{instvar}

So for readability I'm in favour of much more sigils!

And by making them optional to use:

 
use Sigil qw{ € Ą ˘ ° };
[download]

I'd ask "so why don't you use Ruby straight away?" if the answer wouldn't be obvious... "Because it's not compatible with CPAN".

So compability must be the crucial feature of any language extension. New sigils beyond standard ASCII can lead to this compability without many conflicts with old code.

either in the coderange from 128-255 or Unicode! Keymapping of the editor might be a problem, so there might be a fallback solution like $@arr instead of €arr, like the fallback solution in perl6 for » with >>.

and all these extra sigil could be automatically translated in plain perl code.

[reply]
[d/l]
[select]