* TSa <[EMAIL PROTECTED]> [2008-03-19 16:00]: > Aristotle Pagaltzis wrote: >> Something like >> >> path { $app_base_dir / $conf_dir / $foo_cfg . $cfg_ext } >> >> where the operators in that scope are overloaded irrespective of >> the types of the variables (be they plain scalar strings, >> instances of a certain class, or whatever). > > Assuming there are Path, Extension, Directory and File types, > the better approach would be in my eyes to overload string > concatenation.
That presumes you will never want non-path concatenation semantics on filesystem path values. Then how do I write `die "Couldn't open $abspath: $!\n"`? >> When you leave the broader domain of mathematical and “para-” >> mathematical abstractions behind and start to define things >> like division on arbitrary object types that model aspects of >> domains which have nothing even resembling such concepts, >> you’re rapidly moving into the territory of obfuscation. > > Indeed mathematics is all about distilling abstract properties > from problem domains and then proving abstract theorems. That > means when applying mathematics you only have to meet the > preconditions and get all consequences for free. But > overloading a symbol that means product with something that > does not adhere to the algebraic properties of products is a > bad choice. Which was my point. >> Note that even with mathematical abstractions, there are cases >> where scope-bound overloading is a win over type-bound >> overloading. Consider a hypothetical Math::Symbolic that lets >> you do something like this: >> >> my $x = Math::Symbolic->new(); >> print +( $x**2 + 4 * $x + 3 )->derivative( $x ); >> >> I hope it’s obvious how such a thing would me implemented. > > No, I find that far from obvious. Time to read up on operator overloading then. :-) When I say “hypothetical” I mean merely in the sense that “it doesn’t exist on the CPAN in this form” – I did not imply that this would require anything outside the currently available semantics. Kragen Sitaker wrote that precise library in Python 2.x; it could easily be recreated in Perl 5. > Your derivative method should have type :(Code --> Code) No. There are no code blocks or parse trees anywhere in sight, only an expression representation built up the Math::Symbolic object internally as its methods for the various overloaded operations were called. >> Now, if you used type-bound overloading, then the following >> two expressions cannot yield the same result: >> >> ( 2 / 3 ) * $x >> 2 * $x / 3 >> >> But if overloading was scope-bound, they would! > > First of all I would allow the optimizer to convert the latter > into the former unconditionally. […] Hmm, thinking twice, the > above optimization is admissible only if multiplication is > commutative irrespective of the type of $x. Exactly. > I think your statement makes only sense when the polymorphism > on the type of $x is dropped in scope-bound overloading. That’s what I was talking about all along: a way to overload operators monomorphically for the duration of a scope. Operators in Perl are monomorphic, as a rule of thumb. String concatenation requires that you use the string concatenation operator, not the addition operator overloaded by the string type to mean concatenation. So I’d like directory-scope path qualification to have its own operator; what the `path {}` syntax does is override the operator bound to the slash and dot symbols for the duration of the block, regardless of the type of operands they operate on. > In other words $x is then always converted into the suitable > form. Yes. That’s exactly how Perl already works. You say `$x + $y`, it converts $x and $y into numbers somehow. You say `$foo eq $bar`, it stringifies $foo and $bar in whichever way it can. You say `if ( $quux )` and it boolifies $quux in whatever way it knows to do so. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>