Re: Operator overloading [was Re: 7.0 wishlist?]

Jerry Gerrone wrote:
On Nov 16, 11:27 pm, Joshua Cranmer <Pidgeo...@xxxxxxxxxxxxxxx> wrote:
A reason why immutability is a good thing. In any case, the intent I
attempted to convey was the fallacy of naïve translation of mathematical
concepts to programming.

Somehow, I doubt Harry was proposing that the translation be naïve. :)

It's Harold. Only my wife calls me Harry.

As I understood the proposal, it would have to break encapsulation to
do so, and the semantics of well-behaved code wouldn't be dependent on
the exact order of evaluation, although the performance might be.

Poorly-behaved code would behave in a manner that would require
language-lawyering, just like it already does with multiple "i++" in
one line of code. An example I think Harry'd mentioned explicitly.

I had. And see above.

Worrying about how the presentation might degrade at 3x3 is like
worrying about how you'll get to work the next day if your car goes
over that cliff at 40mph, when you happen to be in that car.

Cute. And true.

I doubt a change that would break either of these conditions would fly:

* User-overloaded operators would evaluate in the same order as the
operators they are based on, i.e. operands are evaluated as they appear
and associate as the operators (left-to-right except for the few
right-to-left ones).
* An expression involving user-overloaded operators can be rewritten as
an expression (not a series of statements) using the base methods.

I don't see why the second one is necessary.

Nor do I. Indeed, if Java had thus far lacked the trinary operator ?:, and someone was proposing to add it, Joshua's second criterion would torpedo it, since the equivalent pre-trinary code is if (foo) tempVar = bar; else tempVar = baz.

One step at a time, I'd say. Pin down the implementation of regular
operator overloading before trying to extend it.

I thought this was now about implementing these interfaces and some
compiler tweaks, then adding operator overloading later as a layer on
top?

Harry?

Yeah, I thought so too.

And see above.

Hmm...

public interface CumulativeAddable<Param, Return> extends
Addable<Param, Param, Return> {
public Return add(Param... params);

}

Erk. I think I prefer Accumulator.

Yeah, me too.

fully generalize this -- left-summand type, right-summand type, and
result type; StringBuilder would implement
Accumulator<String,Object,String> since it can add any Object to a
String and return a String, for instance.
But it can also add any String to an Object and get a String. Unfortunately.

As I understood Harry's latest proposal, this would basically be
StringBuilder, not String.

Yes. (And see above.)

Eh, then the third type parameter's not needed. Or the first isn't.
It'd just be Accumulator<Object,String>, left hand argument is what
you can add, right hand argument is the type of the running sum and of
the result. Addable<Object,String> on String, also, since it can be
added to any Object to get a String.

Eh. You also need a way to get the "zero" for the accumulation.
Addable needs a getIdentity() method, and ugly-enough this needs to be
non-static for an interface to specify it. For strings it would return
"", for numbers zero.

I think you have a point here.

Then again, this could be generalized further. Accumulation of
products, with identity 1; of logical-ors, with identity false; of
logical-ands, with identity true; and so forth. Maybe some notion of
generalized commutative, associative operations? Mathematicians call
that an abelian group. We'd need something less exotic and easier to
type. And yes, we'd need to be able to implement the same interface
with multiple sets of generic parameters in a single class. That would
need reified generics, since otherwise method foo taking an
Addable<Foo,Bar> that's also an Addable<Baz,Quux> and doing its add
won't know whether to call Bar add(foo) or Quux add(bar) at runtime
due to erasure.

Sounds difficult.
.

Relevant Pages

  • Re: Cantor and the binary tree
    ... >> Virgil wrote: ... >>> How does one determine, in a maximal binary tree, which two nodes get ... in representing a path by a string. ... Mathematicians are notorious of understanding complicated thnigs quite ...
    (sci.math)
  • Re: Set Theory: Should You Believe
    ... elements in a set, or from a group, in a string... ... Green apples are poison. ... challenges those simple ideas and foundations then mathematicians won't ... listen unless the philosopher is also a mathematician. ...
    (sci.logic)
  • Re: Set Theory: Should You Believe
    ... See term models/henkin models, you can ... A string is already an act, and anything that appears in that string, ... challenges those simple ideas and foundations then mathematicians won't ... listen unless the philosopher is also a mathematician. ...
    (sci.logic)
  • Re: [OT] My First C# (warning - long post)
    ... or string,. ... public string IBreturn ... interface block with the new return code. ... It is unwieldy to keep referencing substrings of an 8K string ...
    (comp.lang.cobol)
  • Re: Explicit Linking of DLLs in VB.net
    ... yes this technique will only work on managed assemblys (exe or dll) ... "YourObject" is a form and is limited to the form methods. ... Wel implement propertys, methods, events in your interface and start ... Public Shared Function LoadMeByName(ByVal vstrAssemblyName As String, ...
    (microsoft.public.dotnet.languages.vb)