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 four you listed, we win a Raku pair KISS award. :)
By "right", I don't mean what you prefer to use while you are
learning Raku. Because that may well be due to familiarity.
Raku, like Perl, embodies the wisdom of Timtowtdi, and he
of course loves Perl and thinks Perl's one way to do things.
So he has crafted Raku with Perl folk in mind, to ensure it's
not ridiculously hard to get from Perl to Raku.
That said, Raku features a bicarbonate cleanup, and ime it
works best if you go with that flow, i.e. recognize the right
idioms and learn to use them as soon as possible.
> > sometimes nice is:
> >
> > my %h5 = :1week, :2days, :3hours;
>
> Now there I disagree completely.
What would you write?
my %h6 = :17hours, :13days; # "17 hours and 13 days"
my %h6 = hours => 17, days => 13; # "hours 17 and days 13"
I can read and remember the first line at speed as I sub-vocalize
it -- intuitively sound out the code "under my breath" as it were.
The second slows my reading down and worsens my short term
memory of it.
Perhaps a key thing here is whether English is a code reader's
mother tongue; you write English fluently so presumably it is,
but it is different if you were not exposed to a lot of English
under the age of 6 months old, and perhaps that is so for you?
Note that I specifically used keys that were not `ha`, `ho`, `hum`
because the `:1foo` syntax should only be used with keys where
things "sound" nice, which typically means it's where one would
naturally use an integer followed by a unit of measurement (or
an ordinal).
> That's my least favorite pair input syntax
I'm going to guess that that's because you don't know things like:
say my %h5 = pi.:<~>, 42.:<->; # {3.141592653589793 => -42}
Or do you prefer that?!?
> and I'd rather pretend it doesn't exist
Fortunately it's to do with literals syntax, which means tooling
such as CommaIDE can just rewrite (or just display it) in your
preferred syntax without changing its meaning. (If Comma isn't
already supporting that trick, perhaps you could request it.)
That way folk like me who naturally "sound" out code and find
that the `:1day` form makes it easier to read and maintain in
short term memory can have what we want, and you can
pretend our code doesn't exist. :)
> -- it's of limited use
Yes, but when it *is* of use it seems nice to me.
I get that this isn't for hash input, but I much prefer:
say S:3rd /o/O/ with "The quick brown fox jumped over the lazy dog";
# The quick brown fox jumped Over the lazy dog
over:
say (S /o/O/, rd => 3) with "The quick brown fox jumped over the lazy dog";
And once you learn it for ordinals it falls out naturally for
other integer measurement / unit scenarios.
> and it's really not worth torturing newbies with it.
I agree it's not worth torturing anyone!
It's more like a thing to encounter along the way -- to see
`s:3rd /.../.../` or `:7hours, :13days` and wonder what it is.
(But I must say I hadn't thought of it as torturing a newbie when
used in what I consider its appropriate form. So thanks for that
heads up on just how much you hate it even when used in that
form that seems nice to me. While I recall plenty of folk rightly
complaining about its inappropriate use, I don't recall bumping
into someone as 100% anti as you!)
> > ...use `<...>` subscripts.
>
> Well, the way I look at it is that the pointy braces are just
> another style of quoting, albiet without quote marks--
> much like Perl's qw(...).
Maybe looking at it that way is a problem.
Have you tried thinking of them as just another style of
subscripting, albeit without quote marks, much like Perl's `{...}`?
Larry realized he could usefully give Raku both unquoted
and quoted subscript operators to minimize keystrokes and
visual noise and other problems with Perl's approach. I love it.
> Notably they also simplify doing slices, e.g.
>
>say %h1< ha ho >; # (1 2)
Yes. That's really nice, don't you think?
> > If you keep thinking you need to quote keys it's for some other reason.
>
> Again: creating a hash element has different syntax requirements
> than accessing a hash element. You need to worry about quoting
> in one case, but not the other
*You* need to worry because that worry is in your head.
I never worry because I have a different mental model.
To create a hash element, I don't quote the key(s).
To access a hash element, I don't quote the key(s).
(Unless I need to because it has to be an arbitrary literal
string, not an identifier. But that's a clearcut rare exception,
and creating a string by using string quoting is the most
natural thing in the world to me.)
Also, to pass a named argument, I don't quote
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 => 2, hum => 3;
> >my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3;
>
> Idiomatically, %h3 is the clear favorite among those four.
True, and I was just saying that the other day.
> Learn to use the right idioms as soon as possible.
Okay. Where's the list of preferred idioms?
(That's a joke. My sense of humor is weird.)
> Btw, another option that's sometimes nice is:
>
> my %h5 = :1week, :2days, :3hours;
Now there I disagree completely. That's my least favorite pair
input syntax, and I'd rather pretend it doesn't exist-- it's of
limited use, and it's really not worth torturing newbies with it.
> >say join(' ',
> > %h1{'ho'}, %h2{'ho'}, %h3{'ho'}, %h4{'ho'}
> > );
> ># Output: 2 2 2 2
> ... Learn to use the best idiom.
>
> Maybe even `say join ' ', do . for %h1, %h2, %h3, %h4;`
That's an interesting one.
> > Of course, when you're accessing the hash value,
> > the key *does* need to be quoted (unlike in perl),
>
> Not at all. As you note yourself, just use `<...>` subscripts.
Well, the way I look at it is that the pointy braces are just
another style of quoting, albiet without quote marks--
much like Perl's qw(...).
Notably they also simplify doing slices, e.g.
say %h1< ha ho >; # (1 2)
> If you keep thinking you need to quote keys it's for some other reason.
Again: creating a hash element has different syntax requirements
than accessing a hash element. You need to worry about quoting
in one case, but not the other-- on one end the behavior is like
Perl, on the other end, the behavior differs.
Call me obtuse if you like, but that much is enough to have me
typing gratuitous quotes on occasion.
> > I often quote keys without thinking about it
>
> That may get you into trouble if you pass pairs in an argument
> list that you intend will be received as named arguments. They
> will be received as positional arguments instead.
That does indeed seem to be what's going on, and it does indeed
seem to be another example where Raku feels inconsistent.
There are some things in Raku that *look* the same, because they're
intended to suggest each other, but they're not actually the same,
which means there are small differences that can trip you up.
> > genius( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
> > ## Error: Too many positionals passed; expected 0 arguments but got 3
> Great example.
> Fortunately, the error message makes it clear you've passed
> 3 positional arguments when it expected none, immediately
> pinpointing where the problem lies:
No, you're really not getting my perspective on this because you
personally already know what's going on. Try thinking about how
the error message reads if you *don't* already know what's going on.
It's telling you something about Positionals when you *thought*
you were giving it Pairs, or something like them.
Then it says it "expected 0 arguments" but that's crazy, you've
told it to expect an indefinite number.
It complains about receiving 3 arguments which doesn't seem like
it should be a problem: you're using a slurpy.
There's very little here to clue someone in that using quoted
names stops them from being treated as names-- and there are
other contexts where such quoting is no problem.
The difference between the situations where the quotes are no big deal
and this one requires a fair amount of knowledge about Raku's behavior.
> > So: when passing pairs to a sub, quoting the key causes things to barf
>
> No, quoting keys when passing pairs to a sub does *not* cause it to barf:
Once again, I don't think you're getting the perspective of a
non-expert here.
> sub church(*%fried, *@frab) { say %fried, @frab }
> church( 'ha' => 1, ho => 2, 'hum' => 3 );
> ## Output: {ho => 2}[ha => 1 hum => 3]
An interesting example. It wouldn't have occured to me that you
can intermix non-ordered and ordered parameters.
> Larry deliberately distinguished pairs passed as arguments based
> on whether their keys were or weren't quoted. If they're unquoted,
> they're named arguments. If they're quoted, they're positional.
So I gather at this point, though I have to confess I'm still
hazy on why it has to work this way.
> He did a similar thing for putting pairs in parens:
>
> sub church(*@frab) { say @frab }
> church( 'ha' => 1, (ho => 2, hum => 3) );
> ## Output: [ha => 1 ho => 2 hum => 3]
And that's another one that seem pretty peculiar.
> I'm not convinced the error message is seriously LTA. I'm
> inclined to view it as pretty good.
As I commented already, I disagree there, but...
> I also think it might be seriously hard to improve.
That I wouldn't claim to know, one way or another. I might think
of improvements for pa
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 entrenches use of the mistaken action. Conversely, bringing it to consciousness strengthens the signal and the opportunity to "nip it in the bud" so to speak, sharply improving one's performance in the task at hand. That all said, I stand by the rest of what I wrote in that 2018 post, including the sense that folks' ERNs can be positively guided by careful PL design, especially if individuals' attitudes to WATs is a sense they are gifts (which is easiest to sustain if there really are indeed corresponding valuable gifts). And I also stand by what I wrote in my previous email to which this is a reply; I really do consider this named argument "wart" to be a great example of a gift that can be used to positively tune folks' ERNs. And this is why, in my first email, I tried to emphasize that from @Larry's perspective, the "warts" discussed in the original email were part of good design. Talking of which, I forgot to mention a detail of that good design that contrasts with something Joe said: > when you're accessing the hash value, the key *does* need > to be quoted (unlike in perl), As I noted before, one does not need to quote keys, because Raku has the very nice design detail of using `<...>` subscripts along with many other related uses of `<...>`. What I didn't note was how this avoided a "wart" in Perl that if one writes `foo` as a key of a hash subscript it is autoquoted even if one meant it not to be. I recall this being part of @Larry's rationale for the Raku design being as it is. -- raiph
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 things sufficiently succinct and clear for them, and for what I'm thinking is the "greater good". > > I'm inclined to view it as pretty good. I also think it > > might be seriously hard to improve. > could this one append of those (my favorite kind) leading questions > "Did you mean to pass ...?" Maybe. But when I thought about that option my intuition was that it would likely end up making the error message weird and noisy for the common case (99.9% of the time?) where the mismatch in args had nothing to do with quoting. And that would imo be a significant negative. Furthermore, the constraints of word count in an error message would inevitably lead to a lost chance to encourage acceptance of the underlying gift, as explained in my Note below. That's why I suggested the as-yet untapped potential of connecting errors to doc pages which can elaborate at length to explain a given message in greater depth, and discuss any gifts that are associated with a given WAT, and maybe link to GH issues discussing it all, etc. Note > As we're looking a known "trap" Imo the first two sentences in the preamble for that page are spot on imo, but the last paragraph is not. To see why I think that, consider what I think is forgotten: * Raku "traps" are mostly beautiful gifts. * It is beautiful that Larry created these beautiful gifts. * It is wise to encourage acceptance of these beautiful gifts. The final paragraph reads as if the writer is not aware of this: > During the making of Raku great pains were taken to get > rid of warts in the syntax. This is one sided thinking, lacking the balance and insight that comes from suitable nuance. cf https://www.reddit.com/r/perl6/comments/8s2vl8/perl_6_colonpairoscopy/e12tf1r/ > When you whack one wart, though, sometimes another pops up. This is an inherently negative take on Larry's neutral waterbed theory. https://en.wikipedia.org/wiki/Waterbed_theory The "whack-a-wart" notion doubles down on the sense that there's been a design failure, and the implication that whack-a-wart is a symptom of this imagined design failure. > So a lot of time was spent finding the minimum number of warts I see this as reflecting good design, and taking care to reach for better. > or trying to put them where they would rarely be seen. Yes and no. In many (most?) cases the opposite is true -- it's often more important to deliberately let them be where they are glaringly obvious and easily encountered as a designed-in teachable moment. You can't make evolved things nice in general without them being warty in particular places. You also have to accept that some gifts will initially be experienced by those who encounter them as warts. And sometimes it's appropriate to choose when to help tune folks' ERN. https://en.wikipedia.org/wiki/Error-related_negativity cf https://www.nntp.perl.org/group/perl.perl6.users/2018/09/msg5418.html > Because of this, Raku's warts are in different places than you may > expect them to be when coming from another language. This is true. :) Who would think that quoting keys would control whether arguments were named or positional? .oO (It's really useful if the compiler can check at *compile-time* if named arguments don't have typo'd keys. And it's really useful that one can write arbitrary strings as keys that do not adhere to the language's rules for named argument names. But if a dev doesn't know Raku, they won't be thinking about those two things. But then again, if they are using Raku, it's arguably a good thing for them to understand about named args sooner rather than later. Also, what to do about interpreting pairs, when used as arguments, as either named arguments or positional arguments? I wonder if a nice DWIM based on whether the key is quoted or not, with a reasonable corresponding WAT, is the way to go?) Aiui, the foregoing thought bubble outlines @Larry's thought process. -- raiph
Re: slurpy hash signatures
Very impressive and complete explanation, thanks!
> I'm inclined to view it as pretty good. I also think it might be seriously
> hard to improve.
As we're looking a known "trap" could this one append of those (my favorite
kind) leading questions "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 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, hum => 3;
>my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3;
Idiomatically, %h3 is the clear favorite among those four.
The others are anti-idiomatic.
Raku is forgiving in this case, trying to ease Perl devs into
using Raku, but do not unduly take advantage of Raku's
kindness. Learn to use the right idioms as soon as possible.
Otherwise you'll get outcomes like the perspective you have
on what happens when you pass pairs as arguments.
Btw, another option that's sometimes nice is:
my %h5 = :1week, :2days, :3hours;
(Same as `my %h5 = week => 1, days => 2, hours => 3;`.)
(But generally avoid this idiom when it does not read well,
and note how subs using it will often need to double up
singular and plural versions of named arguments, in this
case week/weeks etc.)
>say join(' ',
> %h1{'ho'}, %h2{'ho'}, %h3{'ho'}, %h4{'ho'}
> );
># Output: 2 2 2 2
Idiomatically, use `<...>` subscripts instead. Again, Raku is
forgiving, but don't take advantage of its kindness. Learn to
use the best idiom.
Maybe even `say join ' ', do . for %h1, %h2, %h3, %h4;`
> Of course, when you're accessing the hash value,
> the key *does* need to be quoted (unlike in perl),
Not at all. As you note yourself, just use `<...>` subscripts.
> And because of this, I keep thinking I need to quote keys
It's not because the key needs to be quoted when you're
accessing keys. Because they don't. You note the solution
yourself.
If you keep thinking you need to quote keys it's for some
other reason.
> I often quote keys without thinking about it
That may get you into trouble if you pass pairs in an argument
list that you intend will be received as named arguments. They
will be received as positional arguments instead.
> genius( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
> ## Error: Too many positionals passed; expected 0 arguments but got 3
Great example.
Fortunately, the error message makes it clear you've passed
3 positional arguments when it expected none, immediately
pinpointing where the problem lies:
* If you thought you were passing 3 named arguments, you
now know you passed 3 positional ones instead.
* If you thought you were passing 3 positional arguments, you
now know the sub doesn't expect them.
> So: when passing pairs to a sub, quoting the key causes things to barf
No, quoting keys when passing pairs to a sub does *not* cause it to barf:
sub church(*%fried, *@frab) { say %fried, @frab }
church( 'ha' => 1, ho => 2, 'hum' => 3 );
## Output: {ho => 2}[ha => 1 hum => 3]
Works beautifully.
Larry deliberately distinguished pairs passed as arguments based
on whether their keys were or weren't quoted. If they're unquoted,
they're named arguments. If they're quoted, they're positional.
He did a similar thing for putting pairs in parens:
sub church(*@frab) { say @frab }
church( 'ha' => 1, (ho => 2, hum => 3) );
## Output: [ha => 1 ho => 2 hum => 3]
> and the messaging is seriously LTA.
Well, it's surprising to you, because you aren't familiar with
named vs positional arguments. If you were, the message
would instantly clue you into the fact your pairs have been
received as positional arguments instead of as named ones.
I'm not convinced the error message is seriously LTA. I'm
inclined to view it as pretty good. I also think it might be
seriously hard to improve. Perhaps a champion (you?)
might step up to the plate to explore how the message
might be improved, but I think it might be really hard to
improve that message alone in a meaningful way.
I can think of one way that would work and have a much
better payoff. It would still require a champion, but there's
a much greater chance of finding and motivating them.
The short version of it is the idea that error m
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, hum => 3;
>my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3;
Idiomatically, %h3 is the clear favorite among those four.
The others are anti-idiomatic.
Raku is forgiving in this case, trying to ease Perl devs into
using Raku, but do not unduly take advantage of Raku's
kindness. Learn to use the right idioms as soon as possible.
Otherwise you'll get outcomes like the perspective you have
on what happens when you pass pairs as arguments.
Btw, another option that's sometimes nice is:
my %h5 = :1week, :2days, :3hours;
(Same as `my %h5 = week => 1, days => 2, hours => 3;`.)
(But generally avoid this idiom when it does not read well,
and note how subs using it will often need to double up
singular and plural versions of named arguments, in this
case week/weeks etc.)
>say join(' ',
> %h1{'ho'}, %h2{'ho'}, %h3{'ho'}, %h4{'ho'}
> );
># Output: 2 2 2 2
Idiomatically, use `<...>` subscripts instead. Again, Raku is
forgiving, but don't take advantage of its kindness. Learn to
use the best idiom.
Maybe even `say join ' ', do . for %h1, %h2, %h3, %h4;`
> Of course, when you're accessing the hash value,
> the key *does* need to be quoted (unlike in perl),
Not at all. As you note yourself, just use `<...>` subscripts.
> And because of this, I keep thinking I need to quote keys
It's not because the key needs to be quoted when you're
accessing keys. Because they don't. You note the solution
yourself.
If you keep thinking you need to quote keys it's for some
other reason.
> I often quote keys without thinking about it
That may get you into trouble if you pass pairs in an argument
list that you intend will be received as named arguments. They
will be received as positional arguments instead.
> genius( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
> ## Error: Too many positionals passed; expected 0 arguments but got 3
Great example.
Fortunately, the error message makes it clear you've passed
3 positional arguments when it expected none, immediately
pinpointing where the problem lies:
* If you thought you were passing 3 named arguments, you
now know you passed 3 positional ones instead.
* If you thought you were passing 3 positional arguments, you
now know the sub doesn't expect them.
> So: when passing pairs to a sub, quoting the key causes things to barf
No, quoting keys when passing pairs to a sub does *not* cause it to barf:
sub church(*%fried, *@frab) { say %fried, @frab }
church( 'ha' => 1, ho => 2, 'hum' => 3 );
## Output: {ho => 2}[ha => 1 hum => 3]
Works beautifully.
Larry deliberately distinguished pairs passed as arguments based
on whether their keys were or weren't quoted. If they're unquoted,
they're named arguments. If they're quoted, they're positional.
He did a similar thing for putting pairs in parens:
sub church(*@frab) { say @frab }
church( 'ha' => 1, (ho => 2, hum => 3) );
## Output: [ha => 1 ho => 2 hum => 3]
> and the messaging is seriously LTA.
Well, it's surprising to you, because you aren't familiar with
named vs positional arguments. If you were, the message
would instantly clue you into the fact your pairs have been
received as positional arguments instead of as named ones.
I'm not convinced the error message is seriously LTA. I'm
inclined to view it as pretty good. I also think it might be
seriously hard to improve. Perhaps a champion (you?)
might step up to the plate to explore how the message
might be improved, but I think it might be really hard to
improve that message alone in a meaningful way.
I can think of one way that would work and have a much
better payoff. It would still require a champion, but there's
a much greater chance of finding and motivating them.
The short version of it is the idea that error messages can
link to doc pages. So if this error message occurs, there's
a link to a doc page matching the error. That page can then
discuss things at length, covering all the various reasons
why the too many positionals or too many nameds messages
might appear, and all the ways to fix things.
> (The pair operator is being demoted to a fat comma?)
The pair syntax is allowing you to express whether you
want to pass a pair as a positional or a named argument.
Both are useful, so it's useful to be able to express both.
Which do you want?
--
raiph
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 raku wants to see something that looks like a name there, and quoting it messes that up. I think the messaging there is particularly LTA... I think the fact that it's a known trap indicates a need for better hints when someone trips over this one. On 4/18/21, yary wrote: > 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 => 2, hum => 3; >> my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3; >> >> > Those are all lists of pairs, here's another way to write it > my %h5 = :ha<1>, :ho<2>, :hum<3>; > > And even a list-of-things works as a hash initializer > > my %h6 = 'ha', 1, 'ho', 2, 'hum', 3; # no pairs > say %h6; #2 > > as for the main point, interesting! I have the same question about > slurpy-named parameters now... >
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 => 2, hum => 3; > my %h4 = 'ha' => 1, 'ho' => 2, 'hum' => 3; > > Those are all lists of pairs, here's another way to write it my %h5 = :ha<1>, :ho<2>, :hum<3>; And even a list-of-things works as a hash initializer my %h6 = 'ha', 1, 'ho', 2, 'hum', 3; # no pairs say %h6; #2 as for the main point, interesting! I have the same question about slurpy-named parameters now...
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.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?
>>
>
> Yes and no. If you want to use the normal syntax like this:
>
> sub f(:$named-name) { ... }
>
> your indeed limited to identifiers. But with slurpy hashes you can use any
> key, really:
>
> sub f(*%h) {
> say %h{ '++' };
> }
> f(|{ '++' => 'non-identifier names work'})
>
> However this is rather clumsy, and should be reserved for interoperation
> with other languages which have different ideas of what an identifier is.
>
>
> You certainly seem to be able to declare a variable $1.
>>>
>>
> If Rakudo allows that, it's a bug. STD.pm6, Larry's Perl 6 grammar, says
> "Can't declare a numeric variable" about it.
>
>
> I believe that Perl 6 identifiers can be any string at all, but that
>> then they have to appear quoted in the general case;
>> the above
>> restriction just refers to the common case of unquoted identifiers. This
>> said, I'm not sure yet what the syntax is for quoting identifiers. --
>>
>
> This distinction is new to me. For "identifier" means what you call
> "unquoted identifier", and my reading of the synopsis so far hasn't
> contradicted that unerstanding in any way.
>
> But that's really a question of how you call stuff - your explanation is
> correct, as I demonstrated above.
>
> Cheers,
> Moritz
>
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?
Yes and no. If you want to use the normal syntax like this:
sub f(:$named-name) { ... }
your indeed limited to identifiers. But with slurpy hashes you can use
any key, really:
sub f(*%h) {
say %h{ '++' };
}
f(|{ '++' => 'non-identifier names work'})
However this is rather clumsy, and should be reserved for interoperation
with other languages which have different ideas of what an identifier is.
You certainly seem to be able to declare a variable $1.
If Rakudo allows that, it's a bug. STD.pm6, Larry's Perl 6 grammar, says
"Can't declare a numeric variable" about it.
I believe that Perl 6 identifiers can be any string at all, but that
then they have to appear quoted in the general case;
the above
restriction just refers to the common case of unquoted identifiers. This
said, I'm not sure yet what the syntax is for quoting identifiers. --
This distinction is new to me. For "identifier" means what you call
"unquoted identifier", and my reading of the synopsis so far hasn't
contradicted that unerstanding in any way.
But that's really a question of how you call stuff - your explanation is
correct, as I demonstrated above.
Cheers,
Moritz
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 believe that Perl 6 identifiers can be any string at all, but that then they have to appear quoted in the general case; the above restriction just refers to the common case of unquoted identifiers. This said, I'm not sure yet what the syntax is for quoting identifiers. -- Darren Duncan
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;
> >> >
> >> > ? ? ? ?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 program body at line 7:slurphash.p6
> >> >
> >> > According to the UsingPerl6 draft document, "*%hash slurps all the
> >> > remaining unbound named arguments into a hash."
> >>
> >> The key here is "named" arguments; You've invoked the speakhash sub
> >> with positional args.
> >>
> >> Try this:
> >>
> >> ?sub speakhash (*%hash) {
> >> ? ? ?say %hash.perl;
> >> ?}
> >>
> >> ?speakhash(a => 1, b => 2, c => 3, d => 4, e => 5, f => 6);
> >
> > Hm. It just so happens that I tried speakhash(1 => 2, 3 => 4, 5 => 6)
> > and that didn't work. It seems that, although one can create a hash with
> > those pairs, you *can't* pass them as arguments. I'm not clear why.
> >
> > dha
> >
> > --
>
> I believe named arguments have to be valid parameter names.
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.
dha
--
David H. Adler - - http://www.panix.com/~dha/
I'm Doug Stanhope and that's why I drink.
- Doug Stanhope
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{}";
>> > ? ? ? ?}
>> >
>> > ? ? ? ?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 program body at line 7:slurphash.p6
>> >
>> > According to the UsingPerl6 draft document, "*%hash slurps all the
>> > remaining unbound named arguments into a hash."
>>
>> The key here is "named" arguments; You've invoked the speakhash sub
>> with positional args.
>>
>> Try this:
>>
>> sub speakhash (*%hash) {
>> say %hash.perl;
>> }
>>
>> speakhash(a => 1, b => 2, c => 3, d => 4, e => 5, f => 6);
>
> Hm. It just so happens that I tried speakhash(1 => 2, 3 => 4, 5 => 6)
> and that didn't work. It seems that, although one can create a hash with
> those pairs, you *can't* pass them as arguments. I'm not clear why.
>
> dha
>
> --
> David H. Adler - - http://www.panix.com/~dha/
> i just ate a slice of key lime pie while drinking limeade
> scurvy can't touch me now - obnoxicant
>
I believe named arguments have to be valid parameter names.
--
Will "Coke" Coleda
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 get the error:
> >
> > ? ? ? ?Too many positional parameters passed; got 6 but expected 0
> > ? ? ? ? ?in 'speakhash' at line 3:slurphash.p6
> > ? ? ? ? ? ?in main program body at line 7:slurphash.p6
> >
> > According to the UsingPerl6 draft document, "*%hash slurps all the
> > remaining unbound named arguments into a hash."
>
> The key here is "named" arguments; You've invoked the speakhash sub
> with positional args.
>
> Try this:
>
> sub speakhash (*%hash) {
> say %hash.perl;
> }
>
> speakhash(a => 1, b => 2, c => 3, d => 4, e => 5, f => 6);
Hm. It just so happens that I tried speakhash(1 => 2, 3 => 4, 5 => 6)
and that didn't work. It seems that, although one can create a hash with
those pairs, you *can't* pass them as arguments. I'm not clear why.
dha
--
David H. Adler - - http://www.panix.com/~dha/
i just ate a slice of key lime pie while drinking limeade
scurvy can't touch me now - obnoxicant
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
> in 'speakhash' at line 3:slurphash.p6
> in main program body at line 7:slurphash.p6
>
> According to the UsingPerl6 draft document, "*%hash slurps all the
> remaining unbound named arguments into a hash."
The key here is "named" arguments; You've invoked the speakhash sub
with positional args.
Try this:
sub speakhash (*%hash) {
say %hash.perl;
}
speakhash(a => 1, b => 2, c => 3, d => 4, e => 5, f => 6);
> So, it looks to me as though the arguments given to the speakhash()
> subroutine should be slurped into %hash. Regardless, it strikes me as
> odd that Rakudo* seems to think that the subroutine should expect *0*
> arguments.
The error message is potentially confusing, yes.
> So... clearly there's a problem here, but I'm not sure if it's with
> Rakudo* or with my thinking. :-)
>
> Any thoughts on this matter would be appreciated.
>
> many thanks,
>
> dha
>
> --
> David H. Adler - - http://www.panix.com/~dha/
> Why *isn't* there a Widget::Gonzo module?
>
--
Will "Coke" Coleda
