Steve Fink wrote:
On Oct-24, Leopold Toetsch wrote:
... is there anything perl-specific about PerlInt? PerlNum?
This depends. The PerlScalars change there types on demand.
add PerlInt, PerlInt, PerlNum
changes the type of the LHS to a PerlNum. Other languages might prefer
to round the result to an int and keep the type -- I dunno.
Although if we're going to change PerlInt to Int (or just make a new Int base class that PerlInt would inherit from), then we should probably handle the question of how many bits these integers should have, and possibly create a couple of PMCs -- Int32, Int64, IntAtLeast32, NativeInt, UnboundedInt, IntAsBigAsYourHead, etc.
Int's with size <= sizeof(INTVAL) will be handled natively (or by Int.pmc) + some bit adjustment/sign promotion ops. Integers bigger then INTVAL need there own class. Fixed sized ints could be mapped at configure time to an appropriate type.
Dan, do you have any design guidance to kick in here? What Parrot Int/Num PMCs do we need, and how should PerlInt relate to them?
IMHO we should currently concentrate on the PerlScalars - as we don't have other major HLs now. But as soon as they start using parrot, we will know, how these scalars should behave.
A long with the variable/value split, we will get some more modular VTABLE. Eventually we will have a scalar constructor like:
new Int, [ size 32, tieable yes, morph_type perl, taint_check yes ]
and put appropriate VTABLE pieces together, to achieve the desired behaviour.
[ past 0.0.9 ]
Fair enough. Although it looks like this release is still going to take some time to stabilize; there are still an uncomfortable number of warnings and GC bugs.
These warnings and GC bugs should definitely be weeded out, yes. leo
