Re: [Vala] Operator overloading

[Yu Feng <rainwoodman gmail com>]

Would it be reasonable to write some Vala compiler modules that
implements these types internally?

The implementations can then be shared across the entire vala user base.
Yet these modules can be release under different packages, eg,
vala-ccode-currency, vala-ccode-vector, vala-ccode-complex ...

Also with these backend modules, one can have far more
optimizations(assembly, sse, implicit parallism..) than those achievable
within vala itself.


Yu


On Tue, 2009-03-24 at 16:22 -0700, William Swanson wrote:
> It seems useful to catalog the use-cases for operator overloading at
> this point, since folks are missing the big picture by focusing on
> only one or two:
>
> --- Non-standard number representations ---
> * Arbitrary-sized large integers
> * Fractional (int/int) number represtations
> * Base-10 floats for rounding issues
> * Arbitrary-precision floating-point numbers
> * 16-bit floats for OpenGL textures
> These types would implement the four basic operators (+ - * /) as well
> as modulo (%) for the integer types. Xavier Bestel says, "Math
> operators should be limited to
> purely math operations, on integers and reals." Well, Xavier, these
> *are* integers and reals, and they want operator overloading.
>
> --- Complex numbers ---
> Like the real numbers, these numbers have well-defined versions of the
> four basic operators (+ - * /). There is no ambiguity or lack of
> clarity when someone says "complex1 + complex2" or "complex1 /
> complex2". Many programming languages even have complex numbers as a
> built-in type, including C99.
>
> --- Quaternions ---
> Quaternions are complex numbers generalized into four dimensions. As
> with complex numbers, all four basic operators  (+ - * /) are
> well-defined. Quaternions are used to represent rotations in 3D, among
> other things.
>
> --- Vectors ---
> Vectors can come in fixed sizes like <x, y> to <x, y, z, z>, or they
> may be arbitrarily sized. Depending on the application, vectors can be
> represented with integers, floats, or doubles. In every case, the +
> and - operators perform member-wise addition, and the * and /
> operators perform scaling. Vectors also support other operations like
> the dot product and cross product, but those should be implemented as
> named functions as Frederik says earlier.
>
> --- Matrices ---
> Like vectors, matrices come in all sizes and types. Like vectors, the
> + and - operators operate member-wise, while the * and / operators
> perform scalar multiplication. In addition, matrices define a *
> operator that works on any two properly-sized matrices. The other
> matrix operations like transpose and inverse would be named functions.
> ---
>
> These are the applications I can think of, and I am sure there are
> others. Each of these use-cases is a mathematical object, and the
> operators that apply to these objects are well-established by
> mathematical convention. Any programmer using these entities already
> has the mathematical background to know how the operators should
> behave. If not, they can always read the documentation. Named
> functions, on the other hand, make reading documentation mandatory. Is
> the member-wise addition function called "plus," "add," "add_to," or
> what? Which of these functions modifies the original object, and which
> does not? With operator overloading, the answer is simply "+" or "+=".
> Isn't saving a trip to the documentation the nature of clear,
> self-explanatory code?
>
> I hear a lot of strong terms like "nightmarish" and "horror story" in
> relation to operator overloading, but not a lot of concrete examples
> to back them up. I agree that using << for IO is ugly, but that is
> hardly justification for eliminating the entire feature. I suspect the
> problem isn't operator overloading itself, but C++'s excessively
> flexible nature. A locked-down implementation that supports only the
> basic math operators (+ -  * / %), forces those operators to be
> "const" to eliminate side effects, and forces the assignment operators
> (+= -= *= /= %=) to behave predictably would fully support the use
> cases above and would not leave much room for "nightmarish horror
> stories". This isn't C++, where you can overload the [] or ->
> operators to shoot yourself in the foot.
>
> -William Swanson
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list