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