On Thu, Mar 20, 2008 at 10:01 AM, TSa <[EMAIL PROTECTED]> wrote: > Hmm, my idea is more about defining interfaces that allow to detach > implementation of (numerical) algorithms from datatypes. E.g. the > Euclidean algorithm to find the gcd requires division and a remainder > that decreases in absolute value. This is like sorting objects that > do the Ordered role.
Sure. But that's different from saying "Ok, you can only define an / operator for numberish things". > > 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. > 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... > 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. > 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? :) > 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. > 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? > 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... > 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... > > 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. :) -- Mark J. Reed <[EMAIL PROTECTED]>
