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
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
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
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 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
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
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
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);
>
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
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 -
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
11 matches
Mail list logo
