Ralph Mellor<ralphdjmel...@gmail.com> wrote:
> Joseph Brenner <doom...@gmail.com> 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 .<ho> 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 particular cases, but I wouldn't know, for
example, if it's worth the performance hit of looking for those
cases.
> 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.
That's an excellent idea. Some sort of "explain" option that
expands on error messages would also be useful.
(Just as an aside: one of the things on my list of things to do
is to look into writing the descriptions the WHY method needs to work.)
