Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> What is it about automatic conversion to bigints (done well) that scares
> you?
Well, consider the following perl5 code:
sub factorial {
my $n = shift;
my ($f,$i) = (1,0);
$f *= ++$i while $i < $n;
$f;
}
Someone might b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, I'm thinking the core will have four distinct perl variable types
> internally:
>
> * Scalar
> * Hash
> * Array
> * List
Are the lists (aka lazy arrays) you're proposing really a separate core
type, or are they just a variant of the array type -
At 11:52 AM 12/28/00 +, David Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Okay, I'm thinking the core will have four distinct perl variable types
> > internally:
> >
> > * Scalar
> > * Hash
> > * Array
> > * List
>
>Are the lists (aka lazy arrays) you're proposing really a s
At 11:07 AM 12/28/00 +, David Mitchell wrote:
>Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> > What is it about automatic conversion to bigints (done well) that scares
> > you?
>
>Well, consider the following perl5 code:
>
>sub factorial {
> my $n = shift;
> my ($f,$i) = (1,0);
>
Nathan Torkington wrote:
>
> By "pluggable" you mean that sort() should be overridable?
use D::Oh s s\?s.s;
--
John Porter
What would Gabrielle do?
Dan Sugalski wrote:
> And, unless Larry objects, I feel that all vtable methods should have
> the option of going with a 'scalar native' form if the operation if it's
> determined at runtime that two scalars are the same type, though this is
> optional and bay be skipped for cost reasons. (Doing
On Wed, Dec 27, 2000 at 09:27:05PM -0500, Dan Sugalski wrote:
> While we can evaluate the list lazily, that doesn't mean that's what the
> language guarantees. Right now it's perfectly OK to do:
>
>$foo = ($bar, $baz, $xyzzy);
>
> and if $bar and $baz are tied, that'll execute their FETCH m
At 09:45 AM 12/28/00 -0800, Damien Neil wrote:
>On Wed, Dec 27, 2000 at 09:27:05PM -0500, Dan Sugalski wrote:
> > While we can evaluate the list lazily, that doesn't mean that's what the
> > language guarantees. Right now it's perfectly OK to do:
> >
> >$foo = ($bar, $baz, $xyzzy);
> >
> > and
At 09:11 AM 12/28/00 -0800, Peter Buckingham wrote:
>Dan Sugalski wrote:
> > And, unless Larry objects, I feel that all vtable methods should have
> > the option of going with a 'scalar native' form if the operation if it's
> > determined at runtime that two scalars are the same type, though this
At 03:43 PM 12/28/00 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >
> >use sort qw(radix_sort);
> >sort \&radix_sort @data;
>
>Isn't that the slot where the comparison function goes?
>Maybe something more like this:
>
>use sort::radix_sort;
>sort @data; # magically uses radix_sort inst
Jarkko Hietaniemi wrote:
>
> If someone wants to play with such ideas there's Perl 5.7 which has a
> new mergesort as the incore sorting algorithm, while Perl 5.6 and before
> used quicksort.
I'm triggering on the word "incore" there...
I seem to recall someone suggested on perl6-language a whil
On Wed, Dec 27, 2000 at 06:36:56PM -0600, 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.
Radix sorts are great if the data cooperates, radix sorts can really
fly in su
At 06:36 PM 12/27/00 -0600, 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.
I don't see any reason to not allow this--perhaps a lexically scoped
assignment to CORE::GLOBAL:
Dan Sugalski wrote:
>
>use sort qw(radix_sort);
>sort \&radix_sort @data;
Isn't that the slot where the comparison function goes?
Maybe something more like this:
use sort::radix_sort;
sort @data; # magically uses radix_sort instead of default.
--
John Porter
What would Gabrielle do?
On Thu, Dec 28, 2000 at 03:43:21PM -0500, John Porter wrote:
> Dan Sugalski wrote:
> >
> >use sort qw(radix_sort);
> >sort \&radix_sort @data;
>
> Isn't that the slot where the comparison function goes?
> Maybe something more like this:
>
> use sort::radix_sort;
> sort @data; # magicall
At 04:34 PM 12/28/00 -0500, John Porter wrote:
>I seem to recall someone suggested on perl6-language a while back*
>(or was it perl6-internals?) that perl ought also to support efficient
>sorting of large volumes of data by using disk, the way unix sort does.
>Pluggable algorithms would make this
On Wed, 27 Dec 2000, Dan Sugalski wrote:
> As for types presented to extensions, we can certainly provide I8, I16,
> I32, and friends.
But we can't guarantee that every platform has integral types of those
sizes. For example, in perl5, I32 is sometimes 32 bits, and sometimes 64
bits. Some Cra
On Wed, 27 Dec 2000, Dan Sugalski wrote:
> I honestly can't think of any reason why the internal representation of an
> integer matters to the outside world, but if someone can, do please
> enlighten me. :)
Passing parameters to library functions via extensions is tricky no matter
how you do i
I browsed this books on the shelves at Barnes and Noble and remember
mocking it because of the section on "what makes a successful
language" (orthogonal, minimal, clearly defined, ...).
While we won't be using C++, it looks like this might be an
interesting read if you're interested in learning h
19 matches
Mail list logo
