Yes, that's quite possible. Sigils are clues to the human interpreter as well as the machine interpreter. But what are they clues of? Don't they tell you what you can and cannot do with that piece of data?
In some respect, perhaps sigils represent the contract between Perl and the programmer, just like the rest of Perl grammar.
Perl does have a rich syntax. Would it be richer if you could operate on scalars in ways you can't currently? Or is the operation set not orthogonal enough -- is this a lose because of context ambiguity? That's sort of what I'm working through.
substr() exists. Every C-based language gets it for free. But I think the reason Perl doesn't have strcat() is because the dot-operator is better. In other words, subroutines lose if there's a better metaphor (for some value of "better").
So, assuming Perl6 makes @foo[4] the proper way to index lists, why can't we say $foo[4] is the 'shorthand' for substr()? No, no, I'm not submitting an RFC... I'm just asking, "does it make sense?" and "is it better than substr($foo,4,1)"? And then the next step is to ask, if some PMC of the future stores strings as lists, has Perl therefore gained quite a bit of power while, at the same time, streamlined its interior logic?
I'm working through these thoughts. I don't know the answer.
| [reply] |
You can’t say that because in Perl6, $foo[4] is what you’d write $foo->[4] in Perl5.
Makeshifts last the longest.
| [reply]
[d/l]
[select] |
