Re: Where to put test for tr///?
2006/8/26, Mark J. Reed <[EMAIL PROTECTED]>: I noticed that tr/// doesn't currently exist in pugs. I want to add a test, but I'm not sure where it goes. My first instinct is to create a new tr.t in operators/, but I could also see adding it to builtins, or even to the trans test in string. So I thought I'd solicit opinions before diving in. String's trans.t seems like a good place to put it... Audrey
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
Removing dotnet.ops from core
Hi, The opcode file src/ops/dotnet.ops has a very limited subset of .net conversion opcodes. languages/dotnet/ops/dotnet.ops provides amongst other opcodes a much more complete set of conversions. Are there any objections to just remove src/ops/dotnet.ops? leo
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]>
