Jon Lang wrote:
On Wed, Sep 30, 2009 at 11:58 PM, <pugs-comm...@feather.perl6.nl> wrote:
+C<Complex> is an immutable type. Each C<Complex> object stores two numbers,
+the real and imaginary part. For all practical purposes a C<Complex> with
+a C<NaN> in real or imaginary part may be considered a C<NaN> itself (and
+C<(NaN + 1i) ~~ NaN> is C<True>).
I'm not sure that I feel comfortable locking C<Complex> into
rectilinear coordinates as its internal storage method, as there will
be cases where the code operates more smoothly if you're using polar
coordinates to store the numbers: we should leave the inner workings
up to the Parrots to decide. But whichever approach gets used, if
either component is NaN, then the complex number should also be NaN.
I'm not sure if the idea is applicable to Perl 6 because Perl 6 already has an
alternative but ...
One of the features of my Muldis D language is called possreps (possible
representations) where you may define more than one alternative set of
attributes for a data type (and if more than one, you also define functions to
map between each attribute set) and then the implementation can choose for
itself which of those representations (or it can pick yet another one of its
own) is the actual one used physically behind the scenes and which is virtual,
and the user could use either as if it were the real one.
What Perl 6 could do with this concept is for example it can define for some
classes multiple possible object attribute sets, so users know they can use any
of those, and then each Perl 6 implementation can choose what to do natively.
So the Perl 6 spec can and should enumerate the various reasonable alternative
sets of attributes that a Complex object could have, and the Parrots can choose
which to use internally, or could use more than one on a case-by-case basis.
Note that ideally this would be a feature that user-defined classes can use, and
not just language built-in ones.
Now that I think about it, one way this could work within Perl 6's existing
features is that Complex could be a role and each of the possible
representations could be a class that does that role. On the other hand ...
Perhaps how my actual proposal could be realized is as sugar in the language
where one could write say:
class A {
possrep B {
has $c;
has $d;
}
possrep E {
has $f;
has $g;
}
my submethod E_from_B ($c, $d) { <returns $f, $g values> }
my submethod B_from_E ($f, $g) { <returns $c, $d values> }
}
Then users could say for example:
my A $x = A.B.new( :c<1>, :d<2> );
my A $y = A.E.new( :f<4>, :g<5> );
my $c = $y.B.c;
my $f = $x.E.f;
Of course, actual details or syntax could be different, but I think this general
idea would be useful.
Note that in my actual proposal, B and E are *not* classes so doing "my E $foo"
is invalid; the only class here is A. Now Perl 6 may choose to design differently.
Now in Muldis D this system is strict and requires that one can round-trip
between any 2 possreps and have identical attribute values to what one started
with, so the Complex example where conversion would by nature be approximate
wouldn't work there; but in Perl or a language where nonidentical round-trips
are allowed, this may work for Complex too. But then the implementation would
have to always use the same physical representation for all objects of the same
class, or else it wouldn't always DWIM when some one tries an exact equality
test with objects.
-- Darren Duncan
