Re: perl 6 requirements
[email protected] (Glenn Linderman) Mon, 31 Jul 2000 08:40:14 -0700
| Newsgroups | perl.bootstrap |
|---|---|
| Organization | Glenn and Elaine Linderman, at home |
| Message-ID | <[email protected]> |
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 > [email protected] -- 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