Nicholas Clark wrote:
> On Wed, Mar 12, 2003 at 12:18:33PM +1100, Damian Conway 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 consta
On 03/14/2003 3:22 PM, Dan Sugalski wrote:
There's a difference between "Fund project X" and "Fund person X".
Funding a project, and having one person suitable to do the project, is
OK, generally speaking. (Though I expect the feds still peer pretty
closely) Funding a specific person is dodgier.
On Wed, Mar 12, 2003 at 12:18:33PM +1100, Damian Conway 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 allo
At 8:07 AM -0800 3/14/03, Austin Hastings wrote:
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 3:07 PM + 3/14/03, Piers Cawley wrote:
>Brad Hughes <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley wrote:
>> [...]
>>> Nope, send it to TPF as discussed. It's what I've said in all
the
>>>
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:07 PM + 3/14/03, Piers Cawley wrote:
> >Brad Hughes <[EMAIL PROTECTED]> writes:
> >
> >> Piers Cawley wrote:
> >> [...]
> >>> Nope, send it to TPF as discussed. It's what I've said in all
> the
> >>> summaries after all. I just hope that a
At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes <[EMAIL PROTECTED]> writes:
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up t
Brad Hughes <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> [...]
>> Nope, send it to TPF as discussed. It's what I've said in all the
>> summaries after all. I just hope that a chunk of it ends up in Larry's
>> pocket.
>
> Does anyone know if TPF is set up to allow earmarked contributions?
D
Piers Cawley wrote:
[...]
Nope, send it to TPF as discussed. It's what I've said in all the
summaries after all. I just hope that a chunk of it ends up in Larry's
pocket.
Does anyone know if TPF is set up to allow earmarked contributions?
brad
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
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
[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
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
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 C!
>>> Of course not. We're trying to encourage the use of line noise,
>>> and discourage the use of the long variants, so the long
--- "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 T
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 fo
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > : I agree. As long as it's not C!
> >
> > 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 C.
>
> Riiight! Thank-you, G
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 the
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
--- 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 ) {..
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 C!
: >>Of course not. We're trying to encourage the use of line noise,
: >>and discourage the use of the long v
On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
Larry wrote:
: I agree. As long as it's not C!
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 C.
Riiight! Thank-you, General Haig
Larry wrote:
: I agree. As long as it's not C!
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 C.
Riiight! Thank-you, General Haig.
Of course, C (my own preference for the name of this trait) w
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 Wed, Mar 12, 2003 at 01:45:53PM +1100, Damian Conway wrote:
: I agree. As long as it's not C!
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 C.
Larry
--- 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:
>
>
> I don't know that that means we couldn't have an C
> spelling, though. And C (or something easier to spell)
> for the * case. If we have C and C, I think
> it would be appropriate to have names for the other linenoise as
well.
I'd say "please".
> (Percentage of me that really cares: 20%.
Michael Lazzaro asked:
Are you concerned about having an C spelling at all
No, not at all. It really is a shorthand for a trait, after all, so it should
almost certainly have a trait name. Besides, C is probably needed
for non-parameter variables too:
my %nickname is default("Bruce") = (
On Tuesday, March 11, 2003, at 05:18 PM, Damian Conway 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)) {...}
I don't know...maybe I'm worry
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 foo(?$bar is default(1) is copy ) {...}
and hence (mirabile dictu
On Tuesday, March 11, 2003, at 08:41 AM, Brent Dax wrote:
Almost makes you wish for those backwards declarations from C that
computer scientists always gripe about, eh? :^) Well, what about
this?
multi substr(Str $str, $from = $CALLER::_ is optional, $len =
Inf is optional, $new is optional)
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?
# > :^)
# >
# > Seriously, can't we use something rather prettier, like this?
# >
# > metho
> The problem is that if you have multiple optional or named
> parameters, things start getting uncomfortably prolix, and default
> values end up a long way from their owners:
>
> multi substr(Str $str, $from is optional = $CALLER::_,
> $len is optional = Inf, $new is optional) {...
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
>
> Yikes. And I thought we were trying to get *away* from line noise?
>
> Seriously, can't we use something rather prettier, like this?
>
> method x($me: $req, $o
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? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
*%
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
*%named, [EMA
37 matches
Mail list logo
