On 2008-Feb-24, at 2:28 pm, Jonathan Lang wrote:
{ use text; if $a > "49" { say $a } }
...with the result being the same as Perl5's 'if $a gt "49" { say
$a }' (so if $a equals '5', it says '5'). Am I following you? If
so, I'm not seeing what's so exciting about the concept;
The whole point is to be not exciting: instead of being kept on the
edge of your seat wondering what possible meaning ">" has this time,
it's right there explicitly, boringly in front on you. As indicated,
that has advantages and disadvantages. In general, I tend towards
solutions that do what human beings would do (as opposed to
programmers, although of course that isn't always feasible).
One thing humans do, when faced with a dot product, say, is to use a
dot; and happily, Perl 6 makes it easy to define Unicode operators so
we don't have to overload operators that mean something else.
Something else humans do, however, is to overload symbols: e.g. "/"
for a filepath separator and for division. I'm not convinced that
scope-based overloading is the way to go in this particular case,
though. It is the way to go for regexes, which overload all sorts of
symbols that have other meanings, because regexes come in self-
contained lumps anyway. (Although similar overloadings are used in
Signatures, which are another limited scope, come to think of it).
Of course, using a slash for division is a slightly ugly hack anyway,
because typewriters didn't have the proper symbol (U+00F7). P6 could
use "รท" for division, and "/" for portable path-separation. (Which is
kind of tempting, at least to me; I must admit I've been pondering the
use of "/" for filenames for some time.)
On the other hand, I think that in real code, it should be fairly
obvious whether you're doing arithmetic or working with files, so
perhaps the solution is to add unambiguous alternatives for those
exceptional cases when you want to make it absolutely explicit:
open($dir fs ($filename ~ $total div $count)).
(I also expect that files will be treated more consistently in P6,
without as many issues about whether a "file" is a string or a handle
or an object...)
-David
