Front page | perl.bootstrap |
Postings from July 2000
Re: perl 6 requirements
Thread Previous
|
Thread Next
From:
Glenn Linderman
Date:
July 31, 2000 08:38
Subject:
Re: perl 6 requirements
Message ID:
39859DDE.28B48362@Linderman.com
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.
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.
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).
The problem with pack/unpack in this scenario is not so much the syntax that
describes the datatypes (that could be preprocessed with a module for people
that dislike it, to allow any syntax), but the fact that a sequence of data
isn't individually accessible, requiring the complete
unpack/access/modify/repack cycle to update a single data value: or very
obscure structure-specific substring manipulations containing offsets derived
by hand from the pack description. Not fun.
Older versions of BASIC allowed variables to be overlaid on buffers (RSET/LSET
to access), which is a technique that might have promise; or support for
full-flavored structure data as a supported data type (could it look like a
hash is use, but really be a structure, with constrained data types, sizes,
offsets for each member?).
Jonathan Scott Duff wrote:
> On Mon, Jul 31, 2000 at 12:17:58PM +0100, Hildo Biersma wrote:
> > In issue 3.5.1 (data types), I would strongly propose that any strong
> > data typing of perl is done sanely: using the C/C++ approach of
> > 'natural' data sizes.
> > This means 'int' means 'whatever your architecture usefully supports as
> > an int'.
>
> Keep in mind that there are insane people like myself who don't care how
> many bits a numeric scalar is as long as it can hold whatever number I
> put in it. :-) I'd like to see Perl have smart type promotion (and
> demotion) built-in. (i.e. char <-> int <-> long <-> arbitrary as
> needed)
>
> -Scott
> --
> Jonathan Scott Duff
> duff@cbi.tamucc.edu
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
Thread Previous
|
Thread Next