HaloO,
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. The only drawback is that one of the operants
of ~ has to be e.g. a Path to dispatch to &infix:<~>:(Path, Str
--> Path). Subsequent concatenations will continue to dispatch
to path concatenation because of the return type. With path and
ext being unary casts to Path and Extension we get:
path $app_base_dir ~ $conf_dir ~ $foo_cfg ~ ext $cfg_ext;
I suspect though that having the object carry the semantics
around with it is still going to be preferred.
No, the semantics should come from a set of operations that
blend together. The object type should be used only to dispatch
to specific implementations of these semantics.
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.
OTOH, overloading ~ with an operation that behaves like a monoid
is a bad idea too when the new operation doesn't feel like
concatenation. Actually I would argue that ~ could be overloaded
for ints in the sense that 1 ~ 2 == 12 numerically, but I'm unsure
how that would be implemented without an intermediate string.
A lot of C++ programmers could sing a song about that.
Oh yes, not being able to invent new symbols for new
operations is a pain.
But math itself is not free of such things. E.g. there's no
commonly accepted notation for conjugation. Some use an overbar,
others a dagger or asterisk postsuperscript. The latter might
ask for a unary postscript * which I think is technically possible
in Perl 6. But * as a symbol is already heavily overloaded.
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. Your derivative method
should have type :(Code --> Code) i.e. it returns {2*$^x + 4}
when given {$^x**2 + 4 * $^x + 3}. But I fail to see how
the type Math::Symbolic of your $x should instruct the parser
to hand over the parse tree to .derivative or some such.
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. Then I think your statement makes
only sense when the polymorphism on the type of $x is dropped in
scope-bound overloading. In other words $x is then always converted
into the suitable form. But how is that performed in general? IIRC,
the only generically available form is stringification.
Hmm, thinking twice, the above optimization is admissible only if
multiplication is commutative irrespective of the type of $x.
Regards, TSa.
--
The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being. -- Attributed to Hermann Weyl
