"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
>[...]
> So if you *knew* you were dealing with
> 16-bit unsigned integers, you could say
>
> my uint16 @numarray;
>
> and it would generate the optimal code for such an array. You could
> instead say:
>
> my Int @numarray is ctype("unsigned short int");
>
> .... but that's obviously more work, and we still have to support all
> possible combinations of unsigned/long/short/int/etc.
But if we had a (compile-time) range property, then the compiler can infer
the use of a smaller type. For example:
my int $a is range(1000..1255) is unchecked;
could be stored in just one byte (plus overhead). If you add these
properties as an optimisation (rather than to make code more expressive),
then it is good to make it a bit verbose.
> So the decision, I think, is whether or not using such types should be
> encouraged, or discouraged. I'd actually like to encourage them, for
> expert users: using primitive types when you want fast, primitive
> behaviors.
OK. My bias is slightly different: I prefer to have declarative properties
that experts use to guide the optimiser. I'd also like to see the
inter-language integration so good that it feels natural to move things into
(e.g.) c/c++ when extreme optimization is needed. If we can bind (tie?) an
array to a c++ std::vector<int>, then we can create efficient code. But this
doesn't require primitive types in the core language.
> (One of my own "broad goals" is to see Perl be a valid choice for
> things like gif/jpeg manipulation -- not as fast as C, but not crippled
> either -- and other binary data. I think having enough builtin types
> to mirror the C types would make that goal more explicit.)
Yes, it would make it more explicit. I guess that's why it makes me
uncomfortable. Most of the benefits could be achieved with a simple "packed
array" concept: a property on an array that says that the array is a single
value (and therefore its members can't have run-time properties, etc.).
Combined with a C<range> compile-time property, the compiler could optimize
storage: possibly better then you could (e.g. packed, 5-bit values); and
definitely more portably. The more options you pile on, the better it can do
(e.g. direct the optimizer for time vs space). Of course, someone has to
write the optimizers: but hopefully they'll be pluggable modules.
If you have an oft-used type, that is a combination of 5 or 6 properties:
then there is a mechanism to create an alias (typedef/class) of that
composite.
Dave.
