Darren Duncan wrote: > Jon Lang wrote: >> 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.
This sounds a bit like how the "multi" keyword applies to Perl 6 routines to define several routines that share one name. Perhaps there's a way to say "multi class", letting you define several "classes" that are different implementations of the same thing, with each class definition within the multi class being a "possrep". I'm not exactly sure how this would work (you'd need some way to distinguish between the different class definitions, much like multi routines each have a unique long name even though they share the same short name); but it strikes me as being more in keeping with the nature of Perl than nesting several possrep blocks within a single class definition. Perhaps a multi class would involve some sort of implicit version control, with each class definition being given a slightly different version? (Do we still have proto routines to go along with multi routines? If so, you could use a proto class to define common features shared by all of the implementations, such as identifying which roles the multi class does.) Whatever mechanism gets established, the basics would involve being able to establish more than one possible implementation for a class, combined with an ability to identify each implementation's relative strengths and weaknesses so that the compiler has a way to choose which one to use. > 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. If only there was a way for Perl to track exact values for irrational numbers like it does for rationals, rather than trying to approximate them with Num; then one _could_ set up a round trip between rectilinear and polar coordinates that preserves the original values (in theory, at least; you'd still have to figure out how to address the "0 = 2 * pi" problem). -- Jonathan "Dataweaver" Lang
