A6: Signature zones and such
Brent Dax
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, *@list) { ... }
I can deal with one really funny character in a signature, but three is
a bit much.
In any case, it looks like it's time to re-work Perl6::Parameters...but
then I knew this was coming anyway.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Damian Conway
> method x ($me: $req, ?$opt, +$namedop, *%named, *@list) { ... }
>
> 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, *@list) { ... }
It's quite possible that the following equivalences might hold:
?$x same as $x is optional
+%y same as %y is named
So that you could choose.
> I can deal with one really funny character in a signature, but three is
> a bit much.
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) {...}
vs:
multi substr(Str $str, ?$from = $CALLER::_, ?$len = Inf, ?$new) {...}
Damian
Paul
--- Brent Dax <bren...@cpan.org> wrote:
> method x ($me: $req, ?$opt, +$namedop, *%named, *@list) { ... }
>
> Yikes. And I thought we were trying to get *away* from line noise?
>
>
> method x($me: $req, $opt is optional, $namedop is named,
> *%named, *@list) { ... }
I think the sigils are a good thing (note no caps), but that explicit
attributes like "is optional" and "is named" would be a Good Thing.
Accordingly, if the compiler could accept either and do the Right
Thing, that would be rather sweet. :)
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Paul
> 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) {...}
>
> vs:
>
> multi substr(Str $str, ?$from = $CALLER::_, ?$len = Inf, ?$new)
> {...}
What kind of wrench-in-the-works would this cause?
multi substr(Str $str, ($from = $CALLER::_) is optional,
($len = Inf) is optional, $new is optional) {...}
Brent Dax
# Brent Dax wrote:
#
# > method x ($me: $req, ?$opt, +$namedop, *%named, *@list) { ... }
# >
# > 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,
# > *@list) { ... }
#
# It's quite possible that the following equivalences might hold:
#
# ?$x same as $x is optional
# +%y same as %y is named
#
# So that you could choose.
Sweet.
# > I can deal with one really funny character in a signature,
# but three
# > is a bit much.
#
# 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) {...}
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)
It's unambiguous, since $CALLER::_ and Inf have both been declared
already, so the traits can only refer to the
in-the-process-of-declaration variables. (Right?)
Michael Lazzaro
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)
Well, if we have alternate spellings of all the markers:
$arg is default(1) # same as $arg = 1
$arg is optional # same as ?$arg
$arg is named # same as +$arg
@list is variadic # same as *@list
@list is slurpy # (possible alternate spelling)
@list is greedy # (possible alternate spelling)
This would lend a little more credence to the notion that you can put
the C<=> in whatever order you want. Well, maybe. OK, maybe not. But
if you have an C<is default> spelling, you wouldn't care so much...
Wimpy, readable code:
multi substr (
Str $str,
$from is default($CALLER::_) is optional,
$len is default(Inf) is optional,
$new is optional
) {...}
# is same as
multi substr (
Str $str,
$from is optional is default ($CALLER::_),
$len is optional is default(Inf),
$new is optional
) {...}
Manly, expert code:
multi substr (
Str $str,
?$from = $CALLER::_,
?$len = Inf,
?$new
) {...}
MikeL
Damian Conway
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):
sub foo(?$bar = 1 is copy ) {...}
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
my sub foo( ?$bar = 1 is constant ) {...} # OKAY
my $bar = 1 is constant; # KABOOM!
and thereby lays a cognitive trap for programmers.
I don't know...maybe I'm worrying too much.
But then, that's part of my job. ;-)
Damian
Michael Lazzaro
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 worrying too much.
> But then, that's part of my job. ;-)
Are you concerned about having an C<is default()> spelling at all, or
just about optional placements of C<=>? I agree that the C<is constant
= 1> vs. C<= 1 is constant> is a potential point of confusion, and
probably not worth the grief.
I don't know that that means we couldn't have an C<is default()>
spelling, though. And C<is variadic> (or something easier to spell)
for the * case. If we have C<is optional> and C<is named>, I think it
would be appropriate to have names for the other linenoise as well.
(Percentage of me that really cares: 20%. But I suspect others might.)
MikeL
Damian Conway
> Are you concerned about having an C<is default()> 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 default> is probably needed
for non-parameter variables too:
my %nickname is default("Bruce") = (
Wall => 'Wierd Al',
Lazzaro => 'Big Mike',
Khan => 'Ghengy",
);
print "We'd better just call you %nickname{$name}\n";
> or just about optional placements of C<=>? I agree that the C<is constant
> = 1> vs. C<= 1 is constant> is a potential point of confusion, and
> probably not worth the grief.
Yes, that's my concern.
> I don't know that that means we couldn't have an C<is default()>
> spelling, though. And C<is variadic> (or something easier to spell) for
> the * case. If we have C<is optional> and C<is named>, I think it would
> be appropriate to have names for the other linenoise as well.
I agree. As long as it's not C<is slurpy>!
Damian
Paul
> I don't know that that means we couldn't have an C<is default()>
> spelling, though. And C<is variadic> (or something easier to spell)
> for the * case. If we have C<is optional> and C<is named>, 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%. But I suspect others
> might.)
Percentage of me that really cares: ~65%
Degree of concern in that portion : ~72%
Importance of that portion as opposed to the 35% that couldn't find any
interest: 10 to 1.
Effective concern level: roughly 50/50 :)
But I'd still say "please".
Austin Hastings
--- Damian Conway <dam...@conway.org> 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 foo(?$bar is default(1) is copy ) {...}
>
> and hence (mirabile dictu):
>
> sub foo(?$bar = 1 is copy ) {...}
>
>
> 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
>
> my sub foo( ?$bar = 1 is constant ) {...} # OKAY
> my $bar = 1 is constant; # KABOOM!
>
> and thereby lays a cognitive trap for programmers.
>
1- Good catch, and all, but that's the kind of thing (like @ in
strings) that gets a warning emitted from the compiler -- not the kind
of thing that makes it prohibitive to support the feature.
> I don't know...maybe I'm worrying too much.
> But then, that's part of my job. ;-)
2- Yeah! ... umm, are we *paying* you for this?
=Austin
Larry Wall
: I agree. As long as it's not C<is 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 C<is slurpificatious>.
Larry
Damian Conway
>>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
>>
>> my sub foo( ?$bar = 1 is constant ) {...} # OKAY
>> my $bar = 1 is constant; # KABOOM!
>>
>>and thereby lays a cognitive trap for programmers.
>
>
> 1- Good catch, and all, but that's the kind of thing (like @ in
> strings) that gets a warning emitted from the compiler -- not the kind
> of thing that makes it prohibitive to support the feature.
Quite possibly. Except that, the more of these kinds of cognitive dissonances
a language has, the harder it is to learn and use. I see part of my job as
being to keep an eye on how many such special cases we're adding (and
removing!) from Perl 6. With the goal that the overall cognitive load of the
language doesn't go up.
>>I don't know...maybe I'm worrying too much.
>>But then, that's part of my job. ;-)
>
> 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. ;-)
Damian
Damian Conway
> : I agree. As long as it's not C<is 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 C<is slurpificatious>.
Riiiiiiiiiiight! Thank-you, General Haig.
Of course, C<is variadic> (my own preference for the name of this trait) would
probably have much the same effect. ;-)
Damian
Michael Lazzaro
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 bloated
:-)
MikeL
Larry Wall
: On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote:
: >Larry wrote:
: >
: >>: I agree. As long as it's not C<is 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 C<is slurpificatious>.
: >
: >Riiiiiiiiiiight! Thank-you, General Haig.
: >
: >Of course, C<is variadic> (my own preference for the name of this
: >trait) would probably have much the same effect. ;-)
:
: Can we get a final answer, for the (documented) record?
No. I have to wait till Damian isn't looking.
Larry
Austin Hastings
>
> >>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
> >>
> >> my sub foo( ?$bar = 1 is constant ) {...} # OKAY
> >> my $bar = 1 is constant; # KABOOM!
> >>
> >>and thereby lays a cognitive trap for programmers.
> >
> >
> > 1- Good catch, and all, but that's the kind of thing (like @ in
> > strings) that gets a warning emitted from the compiler -- not the
> kind
> > of thing that makes it prohibitive to support the feature.
>
> Quite possibly. Except that, the more of these kinds of cognitive
> dissonances
> a language has, the harder it is to learn and use. I see part of my
> job as
> being to keep an eye on how many such special cases we're adding (and
>
> removing!) from Perl 6. With the goal that the overall cognitive load
> of the language doesn't go up.
But this isn't really a cognitive dissonance, so much as perl6 being
willing to forgive ordering in cases where the meaning is obvious.
I HOPE this doesn't work:
my sub foo( ?$bar = 1 is constant ) {...} # OKAY, but redundant.
my sub foo( ?$bar is rw = 1 is constant) {...} # const if defaulted?
Unless the second case works, and I hope it doesn't, there's only one
meaning to "is <trait>" in a signature. Since there's only one meaning,
just warn the developer if the order doesn't agree with declaration
order.
> >>I don't know...maybe I'm worrying too much.
> >>But then, that's part of my job. ;-)
> >
> > 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. ;-)
You're a point of light, Damian. (*)
=Austin
*: Borrowed from the "other" George Bush.
Damian Conway
> : 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
> 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
point where their context tracking system overloads and they have to go off
and become Lisp programmers. I'm just trying to make sure we don't
incrementally "boil the frog" to that point.
> I HOPE this doesn't work:
>
> my sub foo( ?$bar = 1 is constant ) {...} # OKAY, but redundant.
>
> my sub foo( ?$bar is rw = 1 is constant) {...} # const if defaulted?
No, its an error. Under either proposed syntax.
Damian
Austin Hastings
my macro sucks() is parsed(/<null>/) { "is slurpificatious" }
=Austin
Mark J. Reed
> >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. ;-)
way for those of us out in the field to contribute financial support
to the development of Perl6?
--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754
Austin Hastings
--- "Mark J. Reed" <mark...@turner.com> 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 supporting you folks anymore, what's the best
> way for those of us out in the field to contribute financial support
> to the development of Perl6?
Oh, how cool. I can use Pavlovian conditioning on Damian.
Damian: The answer is ....
Austin: Cool, I like that answer...
PayPal: Ding! Damian has more money..
After a few exegeses, he'll be a drooling slave to my whim ...
=Austin
Piers Cawley
Damian Conway
>>>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 contribute financial support
> to the development of Perl6?
Thanks Mark. Your desire to support our work in that way means a great deal.
I can't speak for Larry, but in my case the best way to help me help Perl
nowadays is to help me find people who would like to pay me to train them (or,
better still, to train their organizations). Since June last year, that's how
I've been getting by. But the training market is very weak just now, so if you
know anyone who might be interested in learning from me, I'd deeply appreciate
hearing about it.
Even if you don't know anyone with an unallocated training budget, it will
help if you just bear in mind that running a training business is a full time
occupation in itself, and every day I do manage to find work translates to
about a week away from Perl 6, what with marketing, and contracts, and
preparation, and travel, and delivery, and accounting, and etc. Sure, I was
vastly more productive when Perl was my full-time job. As was Larry. But
that's no longer possible. Just understanding that and accepting it patiently
is a genuine way to support us.
I'm sure you can imagine the weight of expectation that must sit upon Larry's
broad shoulders each time another Apocalypse is due. Or upon my head, when
each Apocalypse has to subsequently be explained. ;-) It has meant a great
deal that people like yourselves -- who are so clearly very eager for these
documents -- have waited so patiently as changing financial circumstances have
continually slowed the pace at which we can produce them.
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 certainly urge you to respond to that survey when it's
announced (and, yes, I'll inform the mailing list when that happens).
Meanwhile, Larry wasn't kidding when he wrote:
"The next major [apocalypse]...may take a while since (like a lot of people in
Silicon Valley) I'm in negative cash flow at the moment, and need to figure
out how to feed my family. But we'll get it done eventually."
He's been in "negative cash flow" for some time now. As has Dan. As have
several other members of the design team. That said, we certainly don't
*expect* the community to fund the work we do. It would be great if they
could, but as Larry points out many of them are hurting too. Meanwhile, we'll
keep working on the design as best we can, come what may.
None of us is asking for a hand-out. What we're asking for is that the
community understand that we're all doing the best we can, within the
limitations of our individual and collective resources.
Damian
Piers Cawley
> 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 certainly urge you to
> respond to that survey when it's announced (and, yes, I'll inform the
> mailing list when that happens).
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. I'd certainly like them to
continue to fund the development of Perl 6 if only because I wouldn't
have to change that stanza of the summary.
--
Piers
Simon Cozens
> 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 what can be done.
--
Life would be so much easier if we could just look at the source code.
-- Dave Olson
Michael Lazzaro
On Wednesday, March 12, 2003, at 04:07 PM, Piers Cawley wrote:
> Michael Lazzaro <mlaz...@cognitivity.com> 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 bloated
>
> @list is greedy
>
> Anyone?
C<is greedy> or C<is variadic> are both good with me too.
As cute as C<is slurpy> is, I'm not sure it's as obvious. And us
American types will get it confused with the 7-11 spelling C<is
slurpee>, probably. :-)
POMTC, 0.0005%. Don't care what it is, as long as it is.
MikeL
Piers Cawley
> pdca...@bofh.org.uk (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 what can be done.
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.
--
Piers
Smylers
> Damian Conway:
>
> # Brent Dax wrote:
> #
> # > method x ($me: $req, ?$opt, +$namedop, *%named, *@list) { ... }
> # >
> # > Yikes. And I thought we were trying to get *away* from
> # > line noise?
> # > :^)
However that's an example explicitly demonstrating all the variations.
In practice I'd've thought that many people will have a coding style
that nearly-always uses positional parameters and that many other people
will always use named parameters. And a C<?> to make an argument
optional isn't that hard to remember.
> # > Seriously, can't we use something rather prettier, like this?
> # >
> # > method x($me: $req, $opt is optional, $namedop is
> # > named, *%named, *@list) { ... }
> #
> # It's quite possible that the following equivalences might hold:
> #
> # ?$x same as $x is optional
> # +%y same as %y is named
> #
> # So that you could choose.
>
> Sweet.
I don't like the alternatives being available. Having more than one way
to approach things (named or positional parameters; typed or untyped
variables) is good; having more than one syntax for doing exactly the
same thing can be confusing.
Yes, there are other places in Perl with alternative syntaxes.
C<qq[...]> for C<"..."> is very useful. But it's at least similar
(punctuation before and after some text) and there's an excellent reason
why the 'standard' syntax is defective in some circumstances, and most
people use which ever syntax is most appropriate for the text in
question.
And there are places where an alternative syntax has been declined -- or
at least declined as a standard part of the language, leaving people
free to define equivalences if they want -- such as comments with
something other than C<#>.
My problem with the above alternatives is that they make the language
bigger: there's more to learn. Even if as an individual you decide just
to use on of the forms[*0] you still have to know the other version,
because you're going to encounter other people's code using it.
Things like this make Perl awkward to teach. For things like C<qq>
there's an obvious benefit, and it's worth it. But there doesn't seem
to be a benefit here, merely different people having different
preferences (which isn't surprising). Permitting both syntaxes (so that
people with a strong preference can use the one they personally prefer
and grimace at code written by those of the opposite persuasion) is an
uneasy compromise.
I'm concerned that this is an example of the '"Mozilla" preferences
problem': many discussions on features in 'Mozilla' led to the addition
of another preference so that different people can have the feature work
different ways. This shuts up both sides (of those who had strong views
either way), while bloating the program with yet another confusing
preference setting and baffling casual users as to why it contains so
many options rather than working right in the first place.
The second problem with the alternatives is that somebody who uses the
symbolic version and gets used to using it may scan a parameter
declaration that uses the wordy form. But not being used to the wordy
form, the crucial traits aren't spotted among the other words in there,
so he/she misinterprets the declaration.
It's not just a case of knowing about the alternative syntax, but the
fact that every time you read a declaration you have to check for both
versions -- "well, that's either a required positional parameter, or
it's something else which'll be described in a few words' time once I've
got past the type of this variable and a few other traits".
I'm not particularly bothered which syntax we choose (40% in favour of
the symbolic over the wordy) but much more concerned (85%) about there
only being _one_ syntax. (In other words, I'd rather not have the
syntax that I prefer than have multiple alternative syntaxes).
[*0] And it strikes me as quite likely that most people will fix on
one of them -- why would anybody flip between them? -- which provides
another source of pointless style arguments.
Smylers
Brad Hughes
[...]
> 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
Piers Cawley
Dunno. But I'm merely expressing a preference. TPF can do with it what
they will.
--
Piers
Dan Sugalski
Earmarked contributions are apparently somewhat dodgy from an IRS
perspective--they don't want folks setting up a 503(c)(3) to do
payroll stuff as a way to avoid taxes. (Rather than have an employee
you have a grantee of a charity, thus the money you use to pay that
person becomes a tax deduction, or something like that)
The TPF's grant fund stuff's OK, though. It's just a matter of
getting a grantee for this year... (Working on that)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Austin Hastings
--- Dan Sugalski <d...@sidhe.org> wrote:
> At 3:07 PM +0000 3/14/03, Piers Cawley wrote:
> >Brad Hughes <brad+n...@tgsmc.com> 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?
> >
> >Dunno. But I'm merely expressing a preference. TPF can do with it
> what
> >they will.
>
> Earmarked contributions are apparently somewhat dodgy from an IRS
> perspective--they don't want folks setting up a 503(c)(3) to do
> payroll stuff as a way to avoid taxes. (Rather than have an employee
> you have a grantee of a charity, thus the money you use to pay that
> person becomes a tax deduction, or something like that)
>
> The TPF's grant fund stuff's OK, though. It's just a matter of
> getting a grantee for this year... (Working on that)
This doesn't seem right. The United Way runs "directed drives" all the
time, in which they raise money for a particular cause. (And tap me on
the shoulder...)
There's no reason the TPF couldn't run a "Fund P6" drive.
=Austin
Dan Sugalski
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.
That means that TPF's "perl development grant" fund is fine to donate
to, and if there's only enough cash for one grantee, and Larry's the
best candidate, that's keen. Setting up a "Fund Larry Wall" fund is
where things get much less easy.
Nicholas Clark
> 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):
>
> sub foo(?$bar = 1 is copy ) {...}
>
>
> 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
>
> my sub foo( ?$bar = 1 is constant ) {...} # OKAY
> my $bar = 1 is constant; # KABOOM!
>
> and thereby lays a cognitive trap for programmers.
Does it work if the = shorthand is only allowed at the rightmost end of
the specification.
ie
my sub foo( ?$bar = 1 is constant ) {...}
is also defined to be a "KABOOM!" ?
Hence you're allowed to write "is default(42)" as "= 42" only if it's the
last trait. (Is that the right word)
But this feels bad because it's a special case. And an ordering related
special case, which seems to feel more bad to me.
Nicholas Clark
James Mastros
> 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.
>
> That means that TPF's "perl development grant" fund is fine to donate
> to, and if there's only enough cash for one grantee, and Larry's the
> best candidate, that's keen. Setting up a "Fund Larry Wall" fund is
> where things get much less easy.
"worried about it" to "not worried about it" if there was both a "perl
development fund", and a "perl6 development fund". Then people who
wanted to see things like DBI and mod_perl get funded could give to the
first, and people who wanted to see Larry, you (Dan), Damian, and the
gang get funded (or, unfornatly, some subset thereof, depending on how
much money comes in) could give to the second... and everybody gets
their way.
-=- James Mastros
Mlazzaro
> 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 constant = 1 ) {...} # OKAY
> > my $bar is constant = 1; # OKAY
> >
> > my sub foo( ?$bar = 1 is constant ) {...} # OKAY
> > my $bar = 1 is constant; # KABOOM!
> >
> > and thereby lays a cognitive trap for programmers.
<snip>
> Hence you're allowed to write "is default(42)" as "= 42" only if it's the
> last trait. (Is that the right word)
>
> But this feels bad because it's a special case. And an ordering related
> special case, which seems to feel more bad to me.
Yeah, it feels awkward in that way. But I have to agree that being able to
say both C<?$bar is constant = 1> and C<?$bar = 1 is constant> would
probably teach people Very Wrong Things, as per Damian's example.
And it's actually just the same syntax as we've already been talking about
for normal var declarations:
my int $bar is constant = 1;
my int $bar is constant is default(1);
... so it's not _really_ a special case at all... it's just using the same
syntax for declaring parameters as it's using for declaring normal
variables. Or rather, the special case is so omnipresent that it's no
longer special. :-P
MikeL
David Storrs
> On 03/14/2003 3:22 PM, Dan Sugalski wrote:
> > That means that TPF's "perl development grant" fund is fine to donate
> > to, and if there's only enough cash for one grantee, and Larry's the
> > best candidate, that's keen. Setting up a "Fund Larry Wall" fund is
> > where things get much less easy.
> [it's not a problem if] there was both a "perl
> development fund", and a "perl6 development fund". Then people who
> wanted to see things like DBI and mod_perl get funded could give to the
> first, and people who wanted to see Larry, you (Dan), Damian, and the
> gang get funded (or, unfornatly, some subset thereof, depending on how
Such a fund would be the ideal but, until it is set up, there is a
very easy way to fund the design team:
Folks, give us your address (or a PO box, or something), where we can
send checks. The checks won't be tax deductible, but are we really
doing this for the tax deduction?
--Dks
Miko O'Sullivan
> Folks, give us your address (or a PO box, or something), where we can
> send checks. The checks won't be tax deductible, but are we really
> doing this for the tax deduction?
... or a PayPal account. I've got $1.36 in my account ready to send to
the development team. Sorry, the Electronic Frontier Foundation got the
other $5 that was in that account this morning.
-Miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Randal L. Schwartz
David> Such a fund would be the ideal but, until it is set up, there is a
David> very easy way to fund the design team:
David> Folks, give us your address (or a PO box, or something), where we can
David> send checks. The checks won't be tax deductible, but are we really
David> doing this for the tax deduction?
I really don't see a need to donate to other than YAS. If you earmark
your donation, I'm sure YAS will ensure that the money goes to your
requested destination as much as is practically (and legally) possible.
Stonehenge has been a major contributor to YAS. I don't see why we
should start changing plans in midstream.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Paul
--- Miko O'Sullivan <mi...@idocs.com> wrote:
> On Thu, 20 Mar 2003, David Storrs wrote:
> > Folks, give us your address (or a PO box, or something), where we
> > can send checks. The checks won't be tax deductible, but are we
> > really doing this for the tax deduction?
>
> ... or a PayPal account. I've got $1.36 in my account ready to send
> to the development team. Sorry, the Electronic Frontier Foundation
> got the other $5 that was in that account this morning.
This I can do. Gimme a paypal target. :)
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Damian Conway
> Folks, give us your address (or a PO box, or something), where we can
> send checks. The checks won't be tax deductible, but are we really
> doing this for the tax deduction?
Sorry for the delay in replying. It isn't lack of appreciation; it's lack of
tuits (I was a little busy getting Synopsis 6 written this week).
The design team really *do* appreciate the support that this offer and others
like it represent. It means a great deal to us that you believe in the work we
are doing strongly enough to throw money. :-)
We certainly *could* set up some alternate donation mechanism for the Perl 6
team, but we'd really rather work through TPF. That's what it's there for --
to remove the administrative load of handling donations, etc.
The problem is that it doesn't seem to be doing its job just at the moment,
either in terms of finding funding, or channeling it back to the appropriate
people, or even listening to the community as to who the appropriate people are.
But before we look at by-passing TPF, I'd like to take one more shot at
bestirring them to action. If that fails to produce a useful result, then we
will definitely look at finding another mechanism to funnel your generosity to
those who can best make use of it to benefit Perl.
Damian
Damian Conway
http://www.perlfoundation.org/index.cgi?page=survey
And if you have a specific proposal for a "small, targeted" project that you'd
like funded, there's also a proposal form at:
http://www.perlfoundation.org/index.cgi?page=cfprojects
I urge everyone who is interested in Perl (and especially in Perl 6) to offer
TPF feedback on what their funding priorities should be.
Damian
Paul
Thanks, Damian.
I've been meaning to contribute, and this was the prompt I needed.
Paul
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com