On Thu, Mar 20, 2008 at 11:03:11AM -0400, Mark J. Reed wrote: : > > Besides, there is nothing that inherently : > > associates the "/" symbol with division - it's only an ASCII : > > approximation of fraction notation. : > : > We all know that ASCII is a rather limited char set but one : > that has the widest support. Unicode has got U+2215 and U+2044 : > for division and fraction composition. : : Not to mention good old ÷, which is even in Latin-1.
At this point in our history, slash for division is so ingrained into the culture that it would be very difficult to change without widespread grumbling. People have a hard enough time accepting things the extra typing of «+», and I suspect we get away with that only because the user feels the construct is very powerful, and hence worth the agony. Huffman coding can be tweaked in several ways, and power / cost might be one of them. Division is perceived as a very basic operation, so not worth much cost to type. Another minor psychological factor is comes into play is that, besides being "too hard to type", ÷ is visually a symmetrical operator, while division is inherently an asymmetric operation. You'll notice that other asymmetric operators invented by mathematicians tend to convey that asymmetry visually. And even with division, the notion of "over" is asymmetrical, which / is of course proxying for. But perhaps the overriding reason to avoid ÷ is that it's perceived as something that's only used in grade school that you "grow out of". : > Using / for paths has several drawbacks. First, it is not : > the universal directory separator, \ is in widespread use also. : : Meh. Even on Windows you can use / everywhere in the API, and Windows : folks are used to seeing the forward slash used this way in URLs if : nothing else. Mac OS X uses POSIX paths under the covers, and we sure : aren't going to get the colon for this anyway... Well, then there's VMS... :) : > Second, a path is much more like a string than a number. : : Right. Which means there's no room for confusion with division, : 'cause you can't divide strings! Ambiguity gone, problem solved, no : worries. Er, except for hordes of Perl 5 programmers who think you can... :) : > Third, you have to make sure that at least one of the concatenated types is a Path so that : > you are dispatching to the intended implementation. : : Yes, I was sort of assuming there'd be a simple constructor for that. : Maybe even a lexically-enablable path literal syntax. #P"..." anyone? : :) Been trying to avoid tokens that start with # to keep the parsing rules simple...er, less complex... We don't even allow # for user-defined quotes any more, since it's legal to have whitespace (and hence, a comment) between the q and the quote char. But I'd suggest that path() would be much more readable, and Path() is already a built-in coercion if you have a Path type. And how often do you really type path literals? And maybe it would better be handled by some kind of url-ish string that gets mapped to the local conditions transparently. Or just use arrays, which are much more convenent for directory tree traversals, and convert to path at the last moment. : > Instead of overloading ~ for paths I think inventing ~/ or ~\ as : > path concatenating operators is well in line with the Perl 6 operator : > set. And ~. could be the extension concatenator. : : I would be pretty happy with ~/ and ~. Especially if we also got : unary ~/ for making absolute paths in a natural fashion. Those would work, though I wouldn't exactly call 'em pretty... Nice visual correspondence though. I'd even let you have ~: for the drive. :) : > And I also feel that overloading ~ for file concatenation or photo stitching is good practice. : : File concatenation, maybe; photo stitching is inherently a more : complex operation than concatenation. Overloading ~ for that would : be, in my mind, analogous to overloading * for vectors: there's more : than one way to do that, so which operation does it mean? At some point it becomes silly to define an operator when you can just say mystitch(@pix). : > BTW, operator overloading does not allow to change the precedence, : > associativity and commutativity of the operator because these are : > parser features. : : That depends on the degree to which you can munge the parser, though. : And I got the impression that in Perl6 the parser is pretty mungible. : You just have to get to it early enough... Not disagreeing with either of you, but more in the way of an explication... You can add or change operator syntax in Perl 6, but such changes are mandatorily lexically scoped, as are all macros and grammatical tweaks. It's quite possible for a given operator parser to adjust its own precedence and associativity on the fly. Indeed, the assignment operator has to decide at parse-time, based on its left argument, whether its precedence is that of an item assignment or a list assignment. What you guys are calling operator overloading above, I'd just call multiple dispatch, which is *optionally* lexically scoped. (S13 discusses overloading in terms of multiple dispatch.) Operator overloading is a rather useless term when all operators are just functions and all functions are fundamentally regarded as overloaded, even if it turns out there's only one candidate. The parser can decide when to call infix:</>, but it doesn't pay much attention to exactly where that call will be dispatched to, except insofar as the candidate list is generated lexically (which is why you can have lexically scoped multis; they only add themselves to the candidate list within their scope). One way to look at "only" subs is that we have them so that the candidate list can be reduced to a single candidate in a lexical scope, which makes the candidate a more obvious target for optimizations such as inlining. Indeed, we still regard an "only" function as overloaded with its Junctional variants so that we can do autothreading, but we handle that as a special case so as not to pessimize the optimizer. : > We already had the issue of overloading / with div for Int operants. : > And IIRC the conclusion then was that / is a Num operator and thus : > 2/3 != 0 but 2/3 == 0.6666. : : What I'd really like (blue skies, smiling at me...) to see come back : from / is a sort of abstract result-of-division object, which you can : then extract what you want out of it: quotient as float, quotient as : integer, modulus, list containing the latter two, rational fraction, : whatever. Of course, it should automatically Numify to some default, : probably the floating point quotient, and be optimized to yield that : directly when the parser can figure out that it can do that... Hmm, well, that's a deep subject. We've gone a little in that direction in that, if you do Int / Int, you get a Num, but the Num type represents the result lazily as a Rat, and only does the division when forced to. Hence, numeric calculations involving money tend to stay in the Rat type with a divisor of /100, so remain exact. Though perhaps "tend to" is not a strong enough guarantee for most financial folks. :) : > > The P in Perl stands for Practical, not Pedantic. : > : > I consider well designed interfaces as practical not pedantic ;) : : Of course, good design is extremely practical. Just not necessarily : objectively measurable. :) If no one objects, it's objectively good. :) Larry
