Re: slurpy hash signatures

On Wed, Apr 21, 2021 at 2:17 AM Joseph Brenner wrote: > Ralph Mellor wrote: > > [ list of idioms ] > > > Learn to use the right idioms as soon as possible. > > Okay. Where's the list of preferred idioms? The list you presented. If you had or have chosen %h3 as the "right" idiom from among the

Re: slurpy hash signatures

Ralph Mellor wrote: > Joseph Brenner wrote: > > > Before I get started here, a small point about defining hashes. > > There are various ways that work: > > > >my %h1 = ( 'ha' => 1, 'ho' => 2, 'hum' => 3 ); > >my %h2 = ( ha => 1, ho => 2, hum => 3 ); > >my %h3 = ha => 1, ho =>

Re: slurpy hash signatures

Btw, I had misunderstood ERN when, in 2018, I wrote the email message I linked in the Note section of my previous email. ERN is an intuitive sense that some movement you are initiating is in some way a mistake. For example, quoting keys of a pair. It's often unconscious, and, aiui, ignoring it ent

Re: slurpy hash signatures

On Mon, Apr 19, 2021 at 4:03 PM Andy Bach wrote: > > Very impressive and complete explanation, thanks! Thanks for that feedback, it's very helpful. I enjoy trying to help, but it's hard to ensure I've conveyed a tone of respect for whoever I'm replying to, at the same time as trying to keep thing

Re: slurpy hash signatures

ions "Did you mean to pass ...?" From: Ralph Mellor Sent: Sunday, April 18, 2021 11:59 PM To: Joseph Brenner Cc: perl6-users Subject: Re: slurpy hash signatures CAUTION - EXTERNAL: On Sun, Apr 18, 2021 at 8:00 PM Joseph Brenner wrote: > > Before I get started here, a smal

Re: slurpy hash signatures

On Sun, Apr 18, 2021 at 8:00 PM Joseph Brenner wrote: > > Before I get started here, a small point about defining hashes. > There are various ways that work: > >my %h1 = ( 'ha' => 1, 'ho' => 2, 'hum' => 3 ); >my %h2 = ( ha => 1, ho => 2, hum => 3 ); >my %h3 = ha => 1, ho => 2, h

Re: slurpy hash signatures

Bruce Gray points out that this is one of the known traps: https://docs.raku.org/language/traps#Named_parameters I gather there's some sort of special-casing going on where you might think that named arguments are exactly the same a list of pairs, but that's not precisely what's going on, and r

Re: slurpy hash signatures

On Sun, Apr 18, 2021 at 3:00 PM Joseph Brenner wrote: > Before I get started here, a small point about defining hashes. > There are various ways that work: > > my %h1 = ( 'ha' => 1, 'ho' => 2, 'hum' => 3 ); > my %h2 = ( ha => 1, ho => 2, hum => 3 ); > my %h3 = ha => 1, ho =>

slurpy hash signatures

re's this: multi method new(*%attrinit) { And here in an article by Elizabeth Mattijsen I see: https://opensource.com/article/18/9/signatures-perl-6 If you want to catch any (other) named arguments, you can use a so-called "slurpy hash." Just like the slurpy array,

[perl #128795] [BUG] Smartmatch with two signatures, one of which has slurpy hash errors out

# New Ticket Created by Zoffix Znet # Please include the string: [perl #128795] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=128795 > m: :(*%)~~ :(); rakudo-moar 46838d: OUTPUT«Method 'type' not found for invocant of clas

Re: slurpy hash

One thing also worth noting is that $1 is an alias to $/[1]. perl6 > my $1 = 2; say $1; 2 > my $1 = 2; say $/[1]; 2 Also, $ is an alias to $/. This would make them rather difficult to use in parameters, IMO. -- John Harrison On Wed, Aug 18, 2010 at 3:12 AM, Moritz Lenz wrote: > > > Am 18.0

Re: slurpy hash

Am 18.08.2010 01:33, schrieb Darren Duncan: David H. Adler wrote: Hm. So how are valid parameter names defined? Identifiers in perl6 seem to be composed of letters, digits and underscores (and hyphens and apostrophes between letters). That's correct. Are parameter names defined differently

Re: slurpy hash

David H. Adler wrote: Hm. So how are valid parameter names defined? Identifiers in perl6 seem to be composed of letters, digits and underscores (and hyphens and apostrophes between letters). Are parameter names defined differently? You certainly seem to be able to declare a variable $1. I belie

Re: slurpy hash

On Mon, Aug 16, 2010 at 03:49:52PM -0400, Will Coleda wrote: > On Mon, Aug 16, 2010 at 3:36 PM, David H. Adler wrote: > > On Mon, Aug 16, 2010 at 03:14:28PM -0400, Will Coleda wrote: > >> On Mon, Aug 16, 2010 at 3:03 PM, David H. Adler wrote: > >> > Given the code: > >> > > >> > ? ? ? ?use v6; >

Re: slurpy hash

On Mon, Aug 16, 2010 at 3:36 PM, David H. Adler wrote: > On Mon, Aug 16, 2010 at 03:14:28PM -0400, Will Coleda wrote: >> On Mon, Aug 16, 2010 at 3:03 PM, David H. Adler wrote: >> > Given the code: >> > >> > ? ? ? ?use v6; >> > >> > ? ? ? ?sub speakhash (*%hash) { >> > ? ? ? ? ? ?say "%hash{}"; >>

Re: slurpy hash

On Mon, Aug 16, 2010 at 03:14:28PM -0400, Will Coleda wrote: > On Mon, Aug 16, 2010 at 3:03 PM, David H. Adler wrote: > > Given the code: > > > > ? ? ? ?use v6; > > > > ? ? ? ?sub speakhash (*%hash) { > > ? ? ? ? ? ?say "%hash{}"; > > ? ? ? ?} > > > > ? ? ? ?speakhash(1, 2, 3, 4, 5, 6); > > > > I

Re: slurpy hash

On Mon, Aug 16, 2010 at 3:03 PM, David H. Adler wrote: > Given the code: > >        use v6; > >        sub speakhash (*%hash) { >            say "%hash{}"; >        } > >        speakhash(1, 2, 3, 4, 5, 6); > > I get the error: > >        Too many positional parameters passed; got 6 but expected 0

slurpy hash

Given the code: use v6; sub speakhash (*%hash) { say "%hash{}"; } speakhash(1, 2, 3, 4, 5, 6); I get the error: Too many positional parameters passed; got 6 but expected 0 in 'speakhash' at line 3:slurphash.p6 in main pr

Re: Calling positionals by name in presence of a slurpy hash

On Tue, Aug 23, 2005 at 10:11:37AM -0700, Larry Wall wrote: > setting up the proxy hash. It's possible that COW hashes can be made > to work efficiently. We'll need to copy hashes if we want to modify > them to pass to subfunctions, just as when you change your environment > it doesn't affect yo

Re: Calling positionals by name in presence of a slurpy hash

h. It's possible that COW hashes can be made to work efficiently. We'll need to copy hashes if we want to modify them to pass to subfunctions, just as when you change your environment it doesn't affect your parent process's environment variables. Actually, I envision the named argumen

Re: Calling positionals by name in presence of a slurpy hash

On 8/23/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote: > Hi, > > (asking because a test testing for the converse was just checked in to > the Pugs repository [1]) > > sub foo ($n, *%rest) {...} > > foo 13; > # $n receives 13, of course, %rest is () > > foo 13, foo => "bar"; >

Calling positionals by name in presence of a slurpy hash

Hi, (asking because a test testing for the converse was just checked in to the Pugs repository [1]) sub foo ($n, *%rest) {...} foo 13; # $n receives 13, of course, %rest is () foo 13, foo => "bar"; # $n receives 13 again, %rest is (foo => "bar") foo n => 13; # $n re

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

Dov Wasserman wrote: My concern is that given an argument supplied as a pair (foo => "bar"), it is not clear which type of parameter is meant to be supplied. If there is no such named parameter, we know that the argument was intended for the slurpy hash. However, what if the method d

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

"Aldo Calpini" <[EMAIL PROTECTED] > wrote in message ... > > if you decide to reimplement logError to be just: > sub logError {# implicit ([EMAIL PROTECTED]) > # ... > } > using a Pair, you still have someting (a Pair object) that you ca

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Wed, 2004-05-05 at 22:36, Dov Wasserman wrote: > sub logError($msg, Int +$prio = 4, *%errorInfo) { [...] > logError("Database error", module => "DB.pm", line => 263, prio => "HIGH"); > > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement shoul

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > To distinguish these two cases, what if we used the := binding operator to > bind an argument to a named parameter: > > logError($err_msg, prio := 3); but how would this look like to a subroutine that is not defined to accept a named parameter c

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

accept an alterative. Other legitimate objections to the example notwithstanding, the main point is this: there should be a very clear language-enforced distinction between: (A) a method invocation passing a parameter by name (B) a method invocation passing a Pair object to a positional

Re: Named parameters vs. slurpy hash syntax: brittle call syntax!

On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote: > After the New And Improved logError() routine is rolled out, it seems to me > that this log statement should generate a compile-time error, since the > named Int parameter "prio" is given a non-integer argument "HIGH". At best, > this should be a

Named parameters vs. slurpy hash syntax: brittle call syntax!

[Reposting this from earlier this week, since it didn't seem to make it to the news server. -dmw] A question about the calling syntax of named parameters versus arguments supplied to a slurpy hash. If I understand A6 and A12 correctly, all Pair arguments to a function (sub, method, etc.