develooper Front page | perl.bootstrap | Postings from July 2000

Re: perl 6 requirements

Hildo Biersma
July 31, 2000 08:59
Re: perl 6 requirements
Message ID:
Glenn Linderman wrote:
> I agree with Scott: make it easy to write the scripts, getting correct results
> without being picky about details of data types except where necessary.
> Personally, I was initially surprised that the "standard" Perl datatype was
> floating point, which has precision problems for large integers, but in
> practice it hasn't been problematical.
> There is, for scripts that get used often but run slowly, the need of somehow
> optimizing them, and it may be helpful to choose fixed size data types to
> relieve the interpreter of choosing the size dynamically.

Can you explain what you mean here?  As far as I know, the space
consumption in perl is not so much of what size of int we use (16, 32,
64) but that an array or hash must be willing to support any data type -
int and float and string, all in one array.  In Chip's talk at TPC, he
indicated the biggest savings could be accomplished by telling perl
'this array stores integers', allowing perl to avoid SV* and SVs and
directly having int*.

> My current personal preference would have the default (untyped) variable just
> like today's float or string with a data-conformable type, and have available
> specifically sized integers, floats, and strings available for speed, or more
> importantly (for correct script writing), for type checked interfaces.

I personally feel this is the wrong approach.  Instead of using
specifically typed data sizes, use whatever is natural for your
machine.  Checked interfaces can then verify "can I always safely
convert", not "did the user specify the exact bit-size that I need",
which leads to madness.

On the TPC, Jan Dubois from ActivateState had a presentation on a
perl.NET compiler compiling perl for the Microsoft .NET virtual
machine.  Has code was full of 'Int32 $a', 'Int32 @b', etc, which makes
calling strictly typed interfaces very simple. I feel it would be far
more perlish to say 'Integer' and have perl convert at the moment of
method call - possibly throwing an exception for values out of range.

Also, I don't understand the love affair so many people have with
stricly sized variables. You're basically saying "when my code is run on
a better CPU than I have, the user will have to port my code to make use
of it" instead of saying "use whatever float is right for this
machine".  Especially for floating point, the Java model has nasty
run-time issues on non-IEEE floating point CPUs such as the IBM 390
architecture.  If you really need exact floating-point guarantees for
accuracy, you're probaly better off doing C, C++ or Fortran anyway...

> This leads down the road to the "pack/unpack" scenario: really the primary use
> for pack/unpack is to access/present data from/to type-checked, non-scalar
> interfaces (structs, objects, arrays of X, whatever).

Why?  Let perl do the work for you.  I known that perl will always be
able to store an integer of any size in a normal untyped scalar.  If I
want to store an arbitrary scalar, the language could define that (a) an
out of range value is truncated or (b) an out of range value throws an
exception.  If I want to cast everything, I would be coding C++ in the
first place, you could in perl to get away from all that...

Hildo Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About