> > However, if you access the last element using the length of the array,
> > it may try to flatten, and fail:
> >
> > my @flat = (1..Inf, 1..10);
> > $last = @[EMAIL PROTECTED] - 1]; # Kaboom!
How about negative indices? We have negative indices in the slice()
semantics; what if
Damian Conway wrote:
b) The argument passed here must be something that will definitely
not cause the program to crash and burn, and we'll verify
that at
compile-time.
I'm arguing that the former is well-nigh useless, and that the latter is
what large systems developers and
Damian Conway:
# a) The argument passed here must be something that
# could conceivably
# not cause the program to crash and burn, and
# we'll verify that at
# run-time if necessary.
#
# or:
#
# b) The argument passed here must be something that will
# definite
Luke Palmer wrote:
Not that that couldn't be done with a closure anyway...
{
my Class %valClasses;
sub Val($N) returns Class {
my Class $rclass = %valClasses{$N} //= class {
multi *isa ($obj, $rclass $class) { $obj ~~ $N }
}
}
}
multi fact
> or, supposing we have some form of parameterized types, you could create
> something more generic like:
>
> class Val($N) {
> multi *isa ($obj, Val($N) $class) { $obj ~~ $N }
> }
>
> # and then...
>
> multi factorial (Int&Val(0) $g) { 1 }
Yes, YES! Marvelous
Luke Palmer wrote:
So, now that we have binding, is it possible to overload the
assignment operator?
Not really. The problem is that C<&infix:=> is really an operator on
*containers*, not on *values*. So, in order to overload C<=>, you'll still
need to define an appropriate C method on the app
Piers Cawley wrote:
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Probably not. We did discuss whether multimethods should be able to be
overloaded by value, but conclude
Larry Wall wrote:
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But if I say:
:
: sub foo(@a is Array of Int) {...}
: ...
: foo(@x);
:
: then I'm saying: "within &foo, @a is just another name for @x". So they are
: (temporarily) the same thing. That can only (be allowed to
Brent Dax writes:
> Damian Conway:
>
> # Brent Dax wrote:
> #
> # > method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
> # >
> # > Yikes. And I thought we were trying to get *away* from
> # > line noise?
> # > :^)
However that's an example explicitly demonstrating
Simon Cozens <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Piers Cawley) writes:
>> Well... I've finally got my act together and invoice ORA for the
>> summary money that's destined for TPF and I would dearly love to see
>> all of that lump of cash go to Larry.
>
> Yay, another attempt to confu
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> > A lightweight, typedef-like mechanism behaves differently:
> >
> > class Foo is Bar;
> > typedef Baz is Bar;
> >
> > Foo.isa("Baz") == TRUE;
>
> Ah, I get it. But why would you want that -- treating Foo and Baz as
>
> synonymous?
Treati
> Ah, I get it. But why would you want that -- treating Foo and Baz as
> synonymous? Shouldn't you always be using Baz instead of Foo, if you
> really mean Baz and not Foo, and vice versa? Because later on, if you
> changed it such that:
>
> class Foo is Bar;
> typedef Baz is Bar is
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
: This may have been asked before, and I apologize if I somehow missed it,
: but can junctions be used for multiple properties?
:
: I can see it possibly being useful in a situation like the
: following(which may be completely off, as
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> On Thursday, March 13, 2003, at 01:05 PM, Austin Hastings wrote:
> > More to the point:
> >
> > type sigfunc is interrupt is reentrant;
> >
> > sub sig_ign() is sigfunc {...}
> > sub sig_kill() is sigfunc {...}
> > sub sig_intr() is sigfunc {...}
>
On Thursday, March 13, 2003, at 01:23 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa("Baz") == FALSE;
A lightweight, typedef-
On Thursday, March 13, 2003, at 01:05 PM, Austin Hastings wrote:
More to the point:
type sigfunc is interrupt is reentrant;
sub sig_ign() is sigfunc {...}
sub sig_kill() is sigfunc {...}
sub sig_intr() is sigfunc {...}
This is WAGging based on A6, but I guess I see things like this as
being imp
On Thursday, March 13, 2003, at 02:13 PM, Jonathan Scott Duff wrote:
I don't think that junctions make sense here. Besides, the "is" is
optional:
class Foo {
method bar is public rw const frob knob { ... }
}
Ah yes, I'd forgotten about this. Thanks. Still I wond
Michael Lazzaro wrote:
Defining a Class for this is also overkill.
Ye.. well, no. Why?
class Foo is Bar; # normal inheritance
class Baz is Bar; # the thing that we are over-killing
Foo.isa("Baz") == FALSE;
A lightweight, typedef-like mechanism behaves differently:
class Foo is Bar;
ty
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
> > What we do need is some way of bundling a bunch of traits together
> > under a simple name.
>
> Yes, yes, yes.
>
> > Defining a Class for this is also overkill.
>
> Ye.. well, no.
On Wednesday, March 12, 2003, at 04:07 PM, Piers Cawley wrote:
Michael Lazzaro <[EMAIL PROTECTED]> writes:
Can we get a final answer, for the (documented) record?
@list is variadic
@list is slurpy
@list is greedy
@list is slurpificatious
@list is slurptacular
@list is bloa
On Thursday, March 13, 2003, at 12:04 PM, Mark Biggar wrote:
What we do need is some way of bundling a bunch of traits together
under a simple name.
Yes, yes, yes.
Defining a Class for this is also overkill.
Ye.. well, no. Why?
So instead of saying:
my %pet is Hash of Array of Array of
Jonathan Scott Duff wrote:
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be
> I don't see a problem. Scalar == Int|Num|Str|Ref, so
> Scalar.isa("Int").
Scalar.isa("Int") && Int.isa("Scalar")
__
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
On Thu, Mar 13, 2003 at 01:13:27PM -0600, Jonathan Scott Duff wrote:
: I don't think that junctions make sense here. Besides, the "is" is
: optional:
:
: class Foo {
: method bar is public rw const frob knob { ... }
: }
That feature is still in Schroedinger's little bo
On Thu, Mar 13, 2003 at 11:31:30AM -0800, Austin Hastings wrote:
: "Everyone Knows" that an Int is a Scalar, and therefore a sub that has
: a Scalar parameter can safely be passed an Int. This is normal.
:
: What I want is the ability to do the opposite: Silence the warning that
: occurs when I pa
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > But what's the vision for p6?
> >
> > My expectation is that the type-checking stuff will be heavily used
> > for:
> >
> > 1- Large scale projects.
> >
> > 2- CPAN modules.
> >
> > I expect that the folks who want to
On Thu, Mar 13, 2003 at 01:47:19PM -0500, Chris Dutton wrote:
> This may have been asked before, and I apologize if I somehow missed it,
> but can junctions be used for multiple properties?
>
> I can see it possibly being useful in a situation like the
> following(which may be completely off, as
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar is p
On Thu, Mar 13, 2003 at 06:28:00PM +0100, Angel Faus wrote:
:
: Damian Conway wrote:
: > But large projects -- where typing will be most important --
: > *can't* deal with that. That's the point of typing: to specify and
: > enforce interface contracts. At compile-time if at all possible.
:
: One
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But if I say:
:
: sub foo(@a is Array of Int) {...}
: ...
: foo(@x);
:
: then I'm saying: "within &foo, @a is just another name for @x". So they are
: (temporarily) the same thing. That can only (be allowed to) ha
Damian Conway wrote:
> But large projects -- where typing will be most important --
> *can't* deal with that. That's the point of typing: to specify and
> enforce interface contracts. At compile-time if at all possible.
One quick question about this. If I write:
sub foo (Bar $f) {..}
my $x
On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But what we can't allow is a reference parameter to coerce its argument.
: For example:
:
: sub loggedincr (Int $i is rw) {
: print $log: "Incremented $i.id()\n";
: $i++ unless $i.constant;
:
> The sugar I'm using here is to go from
>
>$db.do_sql("select * from Foo");
> to
>$db.select * from Foo;
Since we're fishing, call it a circumfix operator, something like
sql...execute.
Like this:
$db.sql select * from Foo;
execute;
_
[EMAIL PROTECTED] (Piers Cawley) writes:
> Well... I've finally got my act together and invoice ORA for the
> summary money that's destined for TPF and I would dearly love to see
> all of that lump of cash go to Larry.
Yay, another attempt to confuse me and ORA's payments division. ;) I'll
see wha
Damian Conway <[EMAIL PROTECTED]> writes:
> And don't write off the Perl Foundation yet. TPF is just about to do a
> survey of what people think they (TPF) should be funding. If you
> believe Larry and/or myself and/or other members of the design or
> implementation teams are worth sponsoring, I'd
Damian Conway <[EMAIL PROTECTED]> writes:
> Austin Hastings wrote:
>
>> But what's the vision for p6? My expectation is that the
>> type-checking stuff will be heavily used
>> for:
>> 1- Large scale projects.
>> 2- CPAN modules.
>> I expect that the folks who want to do one-liners will still want
Mark J. Reed wrote:
2- Yeah! ... umm, are we *paying* you for this?
Not any more. In fact, like Larry and several others on the design team,
I'm now paying for the privilege of doing it. ;-)
If the TPF isn't supporting you folks anymore, what's the best
way for those of us out in the field to con
Austin Hastings wrote:
But what's the vision for p6?
My expectation is that the type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
I expect that the folks who want to do one-liners will still want to be
able to say C
So the "strict" bits have to be forgivin
[snip]
> effort on properties), so I started to put down a tentative
> class hierarchy of the Perl6 language (I call it P6FC for
> Perl6 Foundation Classes, but the name may (should? :-) very
> well change).
A very good idea, but i am afraid that this ML isnt the right
audience.
PS: But befor
hello everybody,
I'm just a poor newbie here, so please bear with me :-)
while reading the last Apocalypse I thought that maybe
time has come to write things down (like the recent
effort on properties), so I started to put down a tentative
class hierarchy of the Perl6 language (I call it P6FC for
So, now that we have binding, is it possible to overload the
assignment operator? Does the assignment operator mean "value copy"
instead of "reference copy"?
Luke
41 matches
Mail list logo
