Re: Native data structure for parrot?
Brent 'Dax' Royal-Gordon
> What I'm thinking is that in Parrot, as is in Perl, we have dynamic data
> structures, like dynamic HASH and ARRAYs, with SCALARs that can grow as they
> want. To write our code this help a lot, but some parts of our algorithms
> need memory and speed, specially if we are working with big matrix and hash
> tables.
In Perl 6, you'll be able to get an array with a compact
representation by using a lowercase type name with it:
our bit @array;
At the Parrot level, this would probably be represented by a PerlBitArray PMC.
You can also get at a C-level struct using the ManagedStruct and
UnManagedStruct PMCs, though access is a bit clumsy IIRC.
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Leopold Toetsch
> Will be nice to can write this directly on Perl6:
>
> int the_matrix[10][10] ;
Perl6 and thus Parrot supports arrays of native types like int and
bitarrays.
> Also, will be nice to can use the same idea with hash tables:
>
> int , bool static_hash{1000} ;
But while plain integer keys will be supported, bit values don't save
any space (compared to plain ints), as you need one word of storage per
boolean hash value.
> Regards,
> Graciliano M. P.
leo
Luke Palmer
> Will be nice to can write this directly on Perl6:
>
> int the_matrix[10][10] ;
Or rather:
my int @matrix is dim(10,10);
Perl 6 has been planning support for such "naive data structures" for a
long time.
I'm not sure about hashes. They have enough internal structure that
they're going to be pretty big no matter what the return type is
declared to be.
Problems like this are what the CPAN is adept at solving anyway. Just
find a module that does it.
Luke
Bernhard Schmalhofer
> Graciliano M. P. <gmpo...@terra.com.br> wrote:
>
>>What I'm thinking is that in Parrot, as is in Perl, we have dynamic data
>>structures, like dynamic HASH and ARRAYs, with SCALARs that can grow as they
>>want. To write our code this help a lot, but some parts of our algorithms
>>need memory and speed, specially if we are working with big matrix and hash
>>tables.
This sounds somewhat like a Piddle, which is the data structure of the
Perl Data Language, http://pdl.perl.org/. AFAIK there is already a hook,
that allows you to use your own data lying somewhere in your memory.
It might be worthwile to create a Piddle PMC, that brings this
functionality to all Parrot languages.
> You can also get at a C-level struct using the ManagedStruct and
> UnManagedStruct PMCs, though access is a bit clumsy IIRC.
With NCI it should be possible to create a Piddle PMC, that hooks into
the shared library
of PDL for Perl5. Of course, one could also just steal the code or roll
your own code.
CU, Bernhard
--
**************************************************
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
Luke Palmer
> This sounds somewhat like a Piddle, which is the data structure of the
> Perl Data Language, http://pdl.perl.org/. AFAIK there is already a hook,
> that allows you to use your own data lying somewhere in your memory.
>
> It might be worthwile to create a Piddle PMC, that brings this
> functionality to all Parrot languages.
Which of course would entail bringing the functionality that comes with
Piddles to Parrot. Which is like writing a library.
> >You can also get at a C-level struct using the ManagedStruct and
> >UnManagedStruct PMCs, though access is a bit clumsy IIRC.
>
> With NCI it should be possible to create a Piddle PMC, that hooks into
> the shared library
> of PDL for Perl5. Of course, one could also just steal the code or roll
> your own code.
Well, we could do that temporarily, I suppose. It would be a pain
considering all the wrappers and such that we'd have to do, since we
don't have ponie at our disposal yet.
However, both Parrot and Perl 6 are offering many new possibilities to
PDL. I think it would be wise to rethink the overall architecture
before making any hooks or trying to write another PDL.
If there's anyone interested in working on PDL for Parrot, drop me a
line. I've had my eye on this task for a while now, and it would be
neat to get started.
Luke
Craig DeForest
mailing list at jach.hawaii.edu...)
I'm definitely interested in helping out but am probably too busy
keeping my PDL/perl5 stuff going to do much core hacking for Parrot.
The PDL core should be pretty straightforward to port over, since it's
mostly written in C. The biggest deal would be reworking the code
generator for PDL/perl5 (most of PDL is written in a metalanguage,
"PP", that is compiled into C and PerlXS files), which currently
contains some unnecessarily hairy code. The current core is hairy in
part because it started as prototype code that was not overhauled for
cleanliness, and in part because it includes functionality (such as
general data pipelines) that turned out not to be used very much (read:
at all). Keeping only the extremely successful bits (type promotion,
threading over redundant axes, and dataflow for subfields) would
simplify the job quite a bit.
Most of the PDL distribution is additional libraries in a hybrid of PP
and Perl; those parts might not need to be translated, provided that
the infrastructural core was done Right.
There are some definite warts with the current implementation that one
would want to avoid (mostly unavoidable seams between PDL and perl 5),
but this is perhaps not the place to enumerate all of them.