subclass Parrot types to real M ones

[GoogleCodeExporter]

As mentioned in the Cell Arrays issue, currently we implement matrices as a
ResizablePMCArray of ResizablePMCArrays (RoR). 

We either need to subclass our internal types into similar M classes or
implement the class() function to return the nearest M type. An other
alternative is store a map of variables against their best-guess types
(sounds like a bad idea).

Here is list of M array types we should (#already) support: -

logical
char
#int32 (Integer)
int64 (x64/amd64 Integer or BigInt)
#double (Float)
#dcomplex (Complex - this type only exists on FreeMat).
cell
struct
#function_handle (Sub)

Here is a list of array types that will be difficult to support since PIR
does not give access to computer unsigned ints or do not seem important. 

uint8
uint16
uint32
uint64

Here is a list of M array types that do not seem important :- 

single
int8
int16

I am assuming Parrot uses computer doubles for Float/num.

One advantage to using RoRs is they aren't type-strict so one can mix and
match complex/double types; however, in some routines we will need to
determine if an array is Complex/Float/Integer so that we can call the
relevant and optimized BLAS/CLAPACK routine. It may be slow performing a
seek for the super class type within an array, i.e. any Complex, any Float,
etc...

There is also need to implement cells which basically are RoRs that can be
any other type including other RoRs (i.e. matrices or more cells).

Original issue reported on code.google.com by blai...@gmail.com on 30 Mar 2009 at 11:10

[GoogleCodeExporter]

Another option might be adding custom attributes/properties to PMC types 
holding a
string name of their M equivalent. I'm not sure if Parrot supports custom 
attributes
but this option would be a very quick win until we need to refactor it to 
something
more class based in the future.

Original comment by blai...@gmail.com on 31 Mar 2009 at 7:22

[GoogleCodeExporter]

Another advantage of using custom attributes is interoperability with other 
HLLs - a
major goal. It would be far easier for Rakudo or Pynie to decipher a RoR rather 
than
an abstract Matrixy class.

Original comment by blai...@gmail.com on 31 Mar 2009 at 7:31