Bruce Gray (via RT) wrote:
# New Ticket Created by Bruce Gray
# Please include the string: [perl #21547]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=21547
In config/gen/makefiles.pl, Perl is called with inplace
--- Gopal V [EMAIL PROTECTED] wrote:
If memory serves me right, Benjamin Goldberg wrote:
whine
I suppose if there isn't a windows binary out there, I could try
downloading and installing a C compiler (gcc? djgpp?) and then
compiling my own parrot... but I don't want to do that much
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
Thinking a little bit more about parrot calling conventions and register
assignment, I fear that the described calling conventions can't be done.
The pod states:
I5 through I31
The first 26 integer parameters.
S5 through S31
The first 27 string parameters.
At 6:03 PM +0100 3/12/03, Leopold Toetsch wrote:
So my proposal is, to reduce the amount of parameters passed in
registers to some lower value, to take some pressure off the
register allocator.
x5 through x15
would be still a lot of params.
Okay, done! Checkin to follow soon.
--
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 understanding the following:
The following
I think the issue of type coercion (forcing one type to another) should
be decided separately from the issue of implicit types (recognizing
when an untyped variable can be KNOWN at a given point to hold a
specific type, even if it isn't explicitly stated.)
As far as true coercion goes: for the
Agreed. It should do compile-time verification, not runtime.
That said, I still think there *might* be something to be said for
compile-time 'hints' for explicitly _untyped_ values.
Perhaps there should be a distinction between untyped and Object.
Something that is explicitly an Object
On 2003-03-13 at 05:44:09, Damian Conway 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
--- Mark J. Reed [EMAIL PROTECTED] wrote:
On 2003-03-13 at 05:44:09, Damian Conway 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
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.
3- speed
When you are not on perl one liners, but maybe some inner tight loops of
some algorithm or whatever, where speed
Larry Wall replied:
: my Database $db = MySqlDatabase.connect(...);
: $db.select * FROM Foo WHERE Foo.bar LIKE a%b;
To answer your actual question, you either need to have some keyword out
front to start the alternate parsing, or you need to treat .select
as an infix macro that has an
On 3/12/03 1:50 AM, Mark Biggar wrote:
John Siracusa wrote:
From A6:
I worry that generalized wrappers will make it impossible to compile fast
subroutine calls, if we always have to allow for run-time insertion of
handlers. Of course, that's no slower than Perl 5, but we'd like to do
better
Larry Wall writes:
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!
Still, we should be able to detect the attempt to flatten an infinite
list and
--- John Siracusa [EMAIL PROTECTED] wrote:
From A6:
I worry that generalized wrappers will make it impossible to
compile fast
subroutine calls, if we always have to allow for run-time insertion
of
handlers. Of course, that's no slower than Perl 5, but we'd like to
do better
than Perl
--- Damian Conway [EMAIL PROTECTED] wrote:
Various folks have suggested that the default assignment syntax:
sub foo(?$bar is copy = 1) {...}
be considered merely a shorthand for something like:
sub foo(?$bar is copy is default(1)) {...}
thereby allowing:
sub
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
You're treading dangerously close to the SM line there...
Sure. That's exactly what types are for.
Granted.
Does it make sense to say Cuse strict params; for this stuff?
I'd much rather that simply using typed
On Wed, Mar 12, 2003 at 01:45:53PM +1100, Damian Conway wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Larry
Joe Gottman [EMAIL PROTECTED] writes:
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
Michael Lazzaro [EMAIL PROTECTED] writes:
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one
Dave Whipp wrote:
(OK, thats not a good example, but you get the gist). If sure it would
be possible to write the macro in such a way that it looks at its LHS
arg -- and ignores itself if its not a Database object ... but that
places an overly large burden on the macro writer. To avoid
Luke Palmer wrote:
Well, if you did that, it surely couldn't be polymorphic, which kind
of defeats most of the purpose of making it a method.
I disagree. Consider the template method patten. This uses a
non-polymorphic method in a base class to invoke a set of polymorphic
methods in a standard
Sort of a rehash on an old topic, but there's new stuff now with A6.
Mike Lazarro had been making a list of all the operators that Perl6 has.
The latest version I could find was Take 6 (at
http://archive.develooper.com/[EMAIL PROTECTED]/msg12130.html).
So, my questions:
1. Is there a more
On Wednesday, March 12, 2003, at 05:03 PM, Deborah Ariel Pickett wrote:
Sort of a rehash on an old topic, but there's new stuff now with A6.
Mike Lazarro had been making a list of all the operators that Perl6
has.
The latest version I could find was Take 6 (at
On Wed, Mar 12, 2003 at 03:35:58PM -0800, Dave Whipp wrote:
: Larry Wall replied:
: : my Database $db = MySqlDatabase.connect(...);
: : $db.select * FROM Foo WHERE Foo.bar LIKE a%b;
:
: To answer your actual question, you either need to have some keyword out
: front to start the alternate
Luke Palmer wrote:
I'm not quite sure I follow you (I'm not familiar with that pattern).
But the macromethod I imagine is the non-polymorphic one, and the one
it expands to is the polymorphic one, if I'm guessing correctly. And
you certianly could do that.
yes:
Dave Whipp:
# But you're right, there are situations where the (base) type
# might not
# be knowable: and these could result in syntax errors.
Except they wouldn't, at least not always.
$db.select * FROM Foo WHERE Foo.bar LIKE a%b;
$db.select() *
FROM(
Brent Dax wrote:
Dave Whipp:
# But you're right, there are situations where the (base) type
# might not
# be knowable: and these could result in syntax errors.
Except they wouldn't, at least not always.
[snip]
The only part of that I'm not sure about is infix:LIKE, since such an
operator hasn't
- Original Message -
From: Damian Conway [EMAIL PROTECTED]
To: Perl6 [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 9:35 PM
Subject: Re: A6: overloading multis on constness of parameters
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the const-ness of
a
On Tue, Mar 11, 2003 at 06:08:59PM -0800, Michael Lazzaro wrote:
:
: On Tuesday, March 11, 2003, at 12:39 PM, Austin Hastings wrote:
: You want Cmulti to tell the compiler to build in multiple dispatch.
: Any invocation of Cfoo after Cmulti foo is going to be a penny
: dropped into the great
On Wed, Mar 12, 2003 at 01:35:08PM +1100, Damian Conway wrote:
: Joe Gottman wrote:
:
:Will it be possible in perl6 to overload multis on the const-ness of a
: parameter, like C++ does? For instance,
:
:multi getX(Foo $self:) returns Int {...} #const version
:multi getX(Foo $self:
On Tue, Mar 11, 2003 at 04:39:05PM +0100, Matthijs van Duin wrote:
: Will infix operators be allowed to be macros instead of subs?
Yes, but they can't retroactively change the rules under which the left
argument was parsed. At most they can rearrange the returned parse
tree. The right argument
Austin Hastings wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 ) {...} # OKAY
my $bar is constant = 1; # OKAY
On Tue, Mar 11, 2003 at 05:35:34PM -0800, Dave Whipp wrote:
: The effect of a macro is lexical; but the name may be installed in
: either a package or a lexical scope. If the name is installed in a
: class, can it be invoked via a variable of that class?
:
: Example (SQL query integrated via
On Tue, Mar 11, 2003 at 05:35:34PM -0800, Dave Whipp wrote:
: The effect of a macro is lexical; but the name may be installed in
: either a package or a lexical scope. If the name is installed in a
: class, can it be invoked via a variable of that class?
:
: Example (SQL query integrated via
On Wed, Mar 12, 2003 at 10:04:47AM -0500, John Siracusa wrote:
: On 3/12/03 1:50 AM, Mark Biggar wrote:
: John Siracusa wrote:
: From A6:
: I worry that generalized wrappers will make it impossible to compile fast
: subroutine calls, if we always have to allow for run-time insertion of
:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically wrap the @input array in a
make-it-an-int converter. This, to me, is DWIM.
But to
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Riiight! Thank-you, General Haig.
Of course, Cis variadic (my own
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
On Wed, Mar 12, 2003 at 11:23:56AM -0800, Michael Lazzaro wrote:
: On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
: Larry wrote:
:
: : I agree. As long as it's not Cis slurpy!
: Of course not. We're trying to encourage the use of line noise,
: and discourage the use of the long
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
The design team has already considered this idea, and my problem
with it then (and now) is that it's inconsistent with other forms
of variable declaration:
my sub foo( ?$bar is constant = 1 ) {...} # OKAY
Larry wrote:
: Can we get a final answer, for the (documented) record?
No. I have to wait till Damian isn't looking.
Ah, so it's *never* going to be revealed?
;-)
Damian
Austin Hastings wrote:
But this isn't really a cognitive dissonance,
I think it is. Constructs that mean two different things in two different
contexts are always dissonances. Mind you, humans are normally quite good at
coping with that kind of contextually sensitive dissonance. Right up to
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically wrap the @input
--- Damian Conway [EMAIL PROTECTED] wrote:
Larry wrote:
: I agree. As long as it's not Cis slurpy!
Of course not. We're trying to encourage the use of line noise,
and discourage the use of the long variants, so the long one would
have to be Cis slurpificatious.
Riiight!
On Wednesday, March 12, 2003, at 11:07 AM, Damian Conway wrote:
Austin Hastings wrote:
In this case, I rather like the idea of being able to say
sub foo(@a is Array of Int) {...}
my @input = read_a_bunch_o_data();
foo(@input);
Where the compiler will automatically wrap the @input array
- Original Message -
From: Damian Conway [EMAIL PROTECTED]
To: Perl6 [EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 9:35 PM
Subject: Re: A6: overloading multis on constness of parameters
Joe Gottman wrote:
Will it be possible in perl6 to overload multis on the
47 matches
Mail list logo
