At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]:
For integers, we have two types, platform native, and
bigint. No guarantees
are made as to the size of a native int. bigints can be
of any size.
I'm not sure about the wisdom of
On Mon, 25 Dec 2000, Dan Sugalski wrote:
For integers, we have two types, platform native, and bigint. No guarantees
are made as to the size of a native int. bigints can be of any size.
So a native int could be 8 bits big? I think that's allowed according to
ANSI. Not very useful, though.
At 10:46 AM 12/27/00 -0500, Philip Newton wrote:
On Mon, 25 Dec 2000, Dan Sugalski wrote:
For integers, we have two types, platform native, and bigint. No
guarantees
are made as to the size of a native int. bigints can be of any size.
So a native int could be 8 bits big?
Yup, if that's
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]:
For integers, we have two types, platform native, and
bigint. No guarantees
are made as to the size of a native int. bigints can
be
At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
Thus spake the illustrious Dan Sugalski [EMAIL PROTECTED]:
For integers, we have two types, platform native, and
bigint. No guarantees
are
On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote:
So a native int could be 8 bits big? I think that's allowed according to
ANSI.
ANSI/ISO C states:
char = short = int = long
char = 8 bits
short = 16 bits
int = 16 bits
long = 32 bits
C99 adds "long long", which is
At 10:56 AM 12/27/00 -0800, Damien Neil wrote:
I'd be in favor of defining Perl's "native int" type to be at least
32 bits long. I would recommend against using the compiler's default
int type in all cases, as there are compilers which define int as 16
bits for backwards compatability reasons.
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Our integers will be generally unbounded in size--what I want is
DS for the platform people to have the option of choosing a fast
DS version of integer scalars that can be used when appropriate, and
DS switching to the slower bigint
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
I don't recall the bit sizes to be in ANSI C. Which paragraph is that
in?
You need to deduce the bit sizes, as the standard doesn't speak in
terms of bits. I don't have a copy of C89 available, but section
5.2.4.2.1 defines the
Damien Neil wrote:
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
I don't recall the bit sizes to be in ANSI C. Which paragraph is that
in?
You need to deduce the bit sizes, as the standard doesn't speak in
terms of bits. I don't have a copy of C89 available, but
On Wed, Dec 27, 2000 at 02:51:57PM -0500, Hildo Biersma wrote:
This seems likely, but we must take care not to take these assumptions
too far. For example, (and this is not realted to this discussion),
pointers may well be smaller than integers (MVS defines 32-bit ints and
31-bit pointers)
At 02:15 PM 12/27/00 -0500, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Our integers will be generally unbounded in size--what I want is
DS for the platform people to have the option of choosing a fast
DS version of integer scalars that can be used when
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The semantics haven't been set down either from a perl or internals
DS standpoint yet. Perl level is Larry's problem, internals is ours. Luckily
DS they can be hammered out mostly independently.
i can see things changing very easily.
At 11:21 AM 12/27/00 -0800, Damien Neil wrote:
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
I seriously doubt Perl will ever run on an architecture too small
to provide a 32-bit type. I am certain it will never run on an
architecture with no 16-bit type.
I'm reasonably
On Wed, Dec 27, 2000 at 04:08:00PM -0500, Uri Guttman wrote:
i can see things changing very easily. but to me, how perl handles
overflow is a language semantic as much as implementation. in 5 it is
well defined (ilya not withstanding) and you are talking bigint stuff
which scares me. i don't
At 04:08 PM 12/27/00 -0500, Uri Guttman wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The semantics haven't been set down either from a perl or internals
DS standpoint yet. Perl level is Larry's problem, internals is ours.
Luckily
DS they can be hammered out mostly
At 01:48 PM 12/27/00 -0800, Damien Neil wrote:
On Wed, Dec 27, 2000 at 04:17:21PM -0500, Dan Sugalski wrote:
The issue isn't support, it's efficiency. Since we're not worrying about
loss of precision (as we will be upconverting as needed) the next issue is
speed, and that's where we want
Okay, I'm thinking the core will have four distinct perl variable types
internally:
* Scalar
* Hash
* Array
* List
Scalars, hashes, and arrays are pretty much what you'd expect. Lists,
though, are the interesting bit.
The big reason for them is efficiency--we're basically deferring
On Wed, Dec 27, 2000 at 05:17:33PM -0500, Dan Sugalski wrote:
The part I'm waffling on (and should ultimately punt to Larry) is what to
do with lazy data, and what exactly counts as lazy data anyway. For
example, tied variables certainly aren't passive data, but should they be
evaluated if
"DC" == Daniel Chetlin [EMAIL PROTECTED] writes:
DC Which of these two behaviors do you find more useful:
DC [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c'
DC 7.25741561530799e+306
DC [~] $ perl -le'$c=1;$c*=$_ for (2..171);print $c'
DC inf
i am not worried about those
Is there a perl6 sort committee yet? AFter reading Cawley's
method here, I wonder if using it we could make radix-sorts the
default sort method.
Original Message
Return-Path: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 10490 invoked from network); 29
At 02:51 PM 12/27/00 -0800, Damien Neil wrote:
On Wed, Dec 27, 2000 at 05:17:33PM -0500, Dan Sugalski wrote:
The part I'm waffling on (and should ultimately punt to Larry) is what to
do with lazy data, and what exactly counts as lazy data anyway. For
example, tied variables certainly aren't
At 06:15 PM 12/27/00 -0500, Uri Guttman wrote:
"DC" == Daniel Chetlin [EMAIL PROTECTED] writes:
DC Which of these two behaviors do you find more useful:
DC [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c'
DC 7.25741561530799e+306
DC [~] $ perl -le'$c=1;$c*=$_ for
David L. Nicol wrote:
Is there a perl6 sort committee yet? AFter reading Cawley's
method here, I wonder if using it we could make radix-sorts the
default sort method.
Perl6 ought to support pluggable sort algorithms, just as Perl
now supports pluggable comparison functions.
--
John
John Porter writes:
Perl6 ought to support pluggable sort algorithms, just as Perl
now supports pluggable comparison functions.
By "pluggable" you mean that sort() should be overridable?
Nat
25 matches
Mail list logo
