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...)


Reply via email to