On Wed, Apr 21, 2021 at 2:17 AM Joseph Brenner <doom...@gmail.com> wrote:
> Ralph Mellor<ralphdjmel...@gmail.com> 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 the key. No exceptions.
> > > 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.
I recommend you consider recognizing that that feeling is personal
to you (and perhaps anyone else who has the same mental models
as you have described).
And, more importantly, your feelings can change.
And, importantly, is most likely to change if you shift your mental model.
My experience of these features is of wondrous consistency.
(Albeit of the strangely consistent variety, something that's been
celebrated in Raku circles for many years:
http://strangelyconsistent.org/blog/happy-10th-anniversary-perl-6)
> 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.
To me the key (!) difference is literally that a quoted key is a string,
and an unquoted one is an identifier.
This is a small difference in some ways but a big one in others.
As I noted before, unquoted keys get checked by the compiler as
being valid identifiers, which ensures that, as a named argument,
it can match a named parameter. This all but eliminates typos of
named args.
But quoted keys are arbitrary strings. The same is true if you use
a variable:
my $foo = 'bar';
sub bar (:$bar) { say $bar }
bar $foo => 42 # Too many positionals passed; expected 0 arguments but got 1
> > > genius( 'ha' => 1, 'ho' => 2, 'hum' => 3 );
> > > ## Error: Too many positionals passed; expected 0 arguments but got 3
>
> > 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
Fair enough.
> because you personally already know what's going on.
No, that's not it.
> Try thinking about how the error message reads if you
> *don't* already know what's going on.
I had already thought about the perspective of someone who
does not already know what's going on. While I am of course
not omniscient, I assure you my shortfall in recognizing where
you see a problem isn't due to lack of me trying.
> It's telling you something about Positionals when you *thought*
> you were giving it Pairs, or something like them.
Ah.
Why have you written Positional?
My guess would be that you think it has something to do with
the Positional type, a role related to integer-indexed lists. Or
that you're trying to suggest that a newbie might think that.
But almost all newbies encounter the concept of positional
arguments well before they encounter the concept of the
Positional role. And even if they don't, I'm not convinced
most would ignore the use of a lower case p when almost
all types start with a capital letter.
And even if there are rare cases where a newbie had gotten
the Positional role into their head, while being unaware of the
concept of positional arguments, and then, while unaware of
the concept of positional arguments, *was* aware of the only
other kind, *named* arguments, and tries to pass a list of
quoted key pair arguments to a routine they've defined with
a *named* slurpy, I *still* don't see how the error message is
the problem. I agree that such a newbie might be super
*confused* by the message, because they are doing something
*super* confusing. It's as if it's near random!
Reading your original message it seems like you were cargo
culting Liz's code, and doing so to try an experiment. If so, I
suspect that's the crux of the biscuit.
That all said, your mention of Positional is very telling and the
fact you were thinking about that is plausibly what I was missing.
> 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.
You were using a *named* slurpy. Not a slurpy with a name, but
a slurpy parameter that slurps *named* arguments.
----
That said, perhaps this might help and would not make things worse:
Too many *positional* arguments passed; expected 0 but got 3
instead of, as now:
Too many positionals passed; expected 0 arguments but got 3
> There's very little here to clue someone in that using quoted
> names stops them from being treated as names--
But hang on. The context here is a newbie that doesn't know
what a positional argument is. Which surely means they don't
know what a named argument is.
And quoting something makes it a string, not a name. I get
that there are a handful of string oriented PLs, and Perl is one,
where there isn't a sharp distinction, but Raku is a modern
compiled PL and the difference is a big one.
> and there are other contexts where such quoting is no problem.
Right. But learn the right idioms and use them as soon as possible.
> 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.
If you say so. In which case, I recommend you don't quote keys.
> > > 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.
You misunderstand.
You had stated a rule:
> when passing pairs to a sub, quoting the key causes things to barf
If you had said "when passing these pairs to this sub", then I
wouldn't have said what I said. But you had just gone from a specific
to a generalization, and had done so entirely invalidly. It struck me
that you and/or other readers might think that generalization was
valid. So I thought it best to just be clear that you were wrong,
and to show a counter example that might give you and other
potentially misled readers suitable pause for thought.
> > 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.
("named" and "positional" is the terminology used in Raku doc.)
> > 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.
Hopefully the foregoing has helped.
To recap, the key of a named argument must be an *identifier*,
one that the compiler will check is indeed a valid identifier, not
a *string*.
> > 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.
If you have some pairs that would otherwise be interpreted
as named arguments, it's nice to be able to just write a
single pair of parens around the ones you want to instead
pass as positionals.
> > 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.
My concerns aren't performance related.
> > 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.
Right. Perhaps the above suggestion would be an improvement,
but I would dearly love to see adoption of error message IDs
and associating each with its own doc page (especially if users
could get logins to edit it).
> (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.)
Right. CommaIDE now displays the WHY info which is also
another important step in that direction.
--
raiph
