* 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/
