From zefram@fysh.org

bag
===SORRY!===
Argument to "bag" seems to be malformed
------> bag^<EOL>
Other potential difficulties​:
  Function "bag" may not be called without arguments (please use () or whitespace to denote arguments, or &bag to refer to the function as a noun, or use .bag if you meant $_)
  ------> bag^<EOL>
$_ = 3; .bag
No such method 'bag' for invocant of type 'Int'
  in block <unit> at <unknown file> line 1

The error message given in response to "bag" with no argument list advises
one to use ".bag" to perform this operation on $_. In fact there is no
widely-available .bag method, so this part of the error message is bogus.
The same problem arises with some subs that generate a different type
of message for the same situation, such as "mkdir". This part of the
message is correct for some of the other subs that generate these types
of errors, such as "WHAT" and "say". If it's desired to keep this part
of the message for those subs, then the message will have to vary in
whether it includes this part, according to whether the sub is actually
available as a method.

-zefram

From @lizmat

Fixed with rakudo/rakudo@b11dc88a3e , no tests needed.

On 27 Feb 2017, at 10​:30, Zefram (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Zefram
# Please include the string​: [perl #​130877]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130877 >

bag
===SORRY!===
Argument to "bag" seems to be malformed
------> bag^<EOL>
Other potential difficulties​:
Function "bag" may not be called without arguments (please use () or whitespace to denote arguments, or &bag to refer to the function as a noun, or use .bag if you meant $_)
------> bag^<EOL>
$_ = 3; .bag
No such method 'bag' for invocant of type 'Int'
in block <unit> at <unknown file> line 1

The error message given in response to "bag" with no argument list advises
one to use ".bag" to perform this operation on $_. In fact there is no
widely-available .bag method, so this part of the error message is bogus.
The same problem arises with some subs that generate a different type
of message for the same situation, such as "mkdir". This part of the
message is correct for some of the other subs that generate these types
of errors, such as "WHAT" and "say". If it's desired to keep this part
of the message for those subs, then the message will have to vary in
whether it includes this part, according to whether the sub is actually
available as a method.

-zefram

The RT System itself - Status changed from 'new' to 'open'

From zefram@fysh.org

Elizabeth Mattijsen via RT wrote​:

Fixed with rakudo/rakudo@b11dc88a3e , no tests needed.

That only changed one of the two types of message to which I referred.
mkdir still has the unchanged message.

I don't think the change made there fixes the problem. The altered
message still implies that *the sub being called* can be called as a
method. The alteration is merely a clarification of the meaning that
the message had before. It's a reasonable change to make for those
subs that *are* widely available as methods (WHAT, say), but that part
of the message is still wrong for those that are not (bag, mkdir).

-zefram

From @lizmat

On 27 Feb 2017, at 11​:29, Zefram <zefram@​fysh.org> wrote​:

Elizabeth Mattijsen via RT wrote​:

Fixed with rakudo/rakudo@b11dc88a3e , no tests needed.

That only changed one of the two types of message to which I referred.
mkdir still has the unchanged message.

Good point, fixed with rakudo/rakudo@6cb9be294d .

I don't think the change made there fixes the problem. The altered
message still implies that *the sub being called* can be called as a
method.

My point is that without knowing the object on which one attempts to call a method, one cannot know whether or not the method call will fail.

  class A {
  method mkdir() { “foo” }
  }
  mkdir with A.new;

Seems to be perfectly valid error message in this case.

The alteration is merely a clarification of the meaning that
the message had before. It's a reasonable change to make for those
subs that *are* widely available as methods (WHAT, say), but that part
of the message is still wrong for those that are not (bag, mkdir).

Again, without knowing the runtime environment, we cannot see whether the method calls will work or not.

From zefram@fysh.org

Elizabeth Mattijsen via RT wrote​:

My point is that without knowing the object on which one attempts to
call a method, one cannot know whether or not the method call will fail.

That's true, but the conclusion one would reach from that is that one
can't suggest calling the sub in method form even when it *is* available
as a method on Mu. If you're going to run with that logic then that part
of the error message needs to be removed for all the subs that get it,
including ones like "say" as well as "bag". Or if you really want to
refer to method calling, reword it something like ".$name if you meant
to call a method of that name on \$_". What is being called is whatever
method exists of that name, not necessarily the sub with which the error
message is concerned. My suggested wording is good for all the subs
that get these messages, whether or not available as methods on Mu.

But it's pretty normal style to rely on the methods on Mu being available
essentially unchanged in all subclasses. There are other error messages
that recommend calling such methods. (Try interpolating a type object
into a string, for example.) So I think it's reasonable for these error
messages to suggest calling those methods that do actually exist in Mu.
If you're getting antsy about the overridability of Mu methods, there's
an awful lot of code and documentation that should change to stop relying
on those methods, not just a couple of messages.

-zefram