Re: Same-named arguments
2006/8/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Mostly, it's that func('&x' => 1) requires a bit too much typing, and also
makes it hard for func() to change its signature later on to accept things
other than Code.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
Indeed. Were it not for Perl5, I think forcing people to always write
:named($param) instead of named=>$param is a cleaner solution.
The rationale behind autoquoting-as-named is that, the autoquoted
identifiers are the same set of names you can use on the signature line:
func("Some string with embedded space" => $value);
would be taken as Pair, not named, because one cannot declare a
parameter name that contains space in &func's signature line.
On the other hand, I'd have no problem with parens-disambiguation going
away, such that fx=>1 means just f(x=>1), and use f('x'=>1) when
you mean a Pair.
Cheers,
Audrey
Re: feedback on the draft documentation spec
http://svn.openfoundry.org/pugs/docs/Perl6/Spec/Documentation.pod ...is *way* out of date. It predates the meeting Ingy, Larry, Audrey, and I had in Tokyo, in which most of the kinks were ironed out. I have a new draft of S26 with the design team at the moment, and am close to having a first cut at a parser for that mark-up notation. The new Pod looks very much like the old POD, only cleaned up and simplified. Kinda like Perl 6 itself. Stay tuned. If I hear nothing more from the design team, and if I can get the parser stable in the next week or so, I'll post a new S26 here RSN. Damian
Re: Same-named arguments
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.
On 8/25/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
> I asked this same question on perl6-users, but no one really seemed to
have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of
different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.
That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.
Luke
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: Same-named arguments
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.
On 8/25/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
> I asked this same question on perl6-users, but no one really seemed to
have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of
different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.
That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.
Luke
--
Mark J. Reed <[EMAIL PROTECTED]>
