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
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. W
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
--- 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. big
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 gu
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", w
Damien Neil wrote:
>
> 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
>
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 b
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,
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 us
> "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 e
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 ce
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
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 things to be in a platform convenient size.
I t
At 01:31 PM 12/27/00 -0800, Daniel Chetlin wrote:
>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)
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 ou
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 w
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
flattenin
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
> "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 abo
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); 2
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
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*=
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 Po
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
28 matches
Mail list logo
