For the record, I am opposed to any restriction on operator
overloading that requires mathematical properties to hold. ANYTHING
is fair if you predeclare. Besides, there is nothing that inherently
associates the "/" symbol with division - it's only an ASCII
approximation of fraction notation. I want to be able to define / as
a path constructor and not give a flying flip that (path 2) * (path 3)
/ (path 5) - whatever the heck * might mean on paths - is not the same
as (path 2) / (path 5) * (path 3).
The P in Perl stands for Practical, not Pedantic.
On 3/19/08, TSa <[EMAIL PROTECTED]> wrote:
> 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
>
--
Mark J. Reed <[EMAIL PROTECTED]>
