At 8:32 AM -0500 3/11/03, Clinton A. Pierce wrote:
At 01:04 AM 3/11/2003 -0500, Benjamin Goldberg wrote:
Does anyone have a precompiled parrot binary for Win32, on an ftp or web
site somewhere?
I'm practicing writing parrot assembler, and I'd like to be able to test
my evil creations on my own mac
At 8:33 PM +0100 3/12/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 6:03 PM +0100 3/12/03, Leopold Toetsch wrote:
So my proposal is, to reduce the amount of parameters passed in registers
Okay, done! Checkin to follow soon.
Wow, really fast, thanks.
Still remaing - probably /me not unders
Dan Sugalski wrote:
[ lotta explanation skipped ]
Objects first, though--PDD 15 beckons. *Then* you and I can work out the
fuzzy bits so it both makes sense and IMCC can work with it well.
Thanks for the details. And as objects probably will shed some more
light on calling conventions, I'm fin
> If we can't find anothr home for it, I can make a spot on
> ftp.sidhe.org for it. Not a *fast* home, since it's either 128k or
> 192k upstream (depending on which interface is active, don't ask) but
> it will work.
Maybe when 0.10 is released, Clinton will do another windows build and
we can
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
--- 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.
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
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
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 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-
--- 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 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
> 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
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
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
[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
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
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
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
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
--- 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
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
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
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
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
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
> 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:
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
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
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
> > 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
[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
> 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;
_
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;
:
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 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
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
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 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
--- 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 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
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
> 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
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
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
45 matches
Mail list logo
