On Mon Sep 12 07:33:33 2016, darek.cidlin...@atlas.cz wrote:
> 2) should the newline before the ... operator be forbidden,
> the error message could be clearer than a single asterisk.
Thanks for the report, but I think I'm going to close this without any changes.
What happens is your } without unspace after it closes the previous statement
and you start a new one, but in this new context, the `...` is a Stub.
Furthermore, you can give that Stub arguments to call `fail` with. So the
compiler thinks you're giving it the Whatever as an argument to `fail` and
that's what the error message prints out.
So improving the message would involve exempting the Whatever from allowed
arguments to ... Stub. But... that wouldn't solve the issue entirely. For
example, I like to use `∞` instead of Whatever Star as an end point to …. Also,
10 < *, { whatever }, and "foo" can also be used as an end point, so we can't
exclude all of the possible endpoints from the Stub arguments to give a better
error message.
With knowledge that } as last thing on the line closes blocks, it was pretty
easy for me to spot what the problem was, so I think despite the error message
looking funky in this particular case, its content is a side-effect of
interaction of two features and improving the message means restricting those
features, while the target audience who would be helped by the better message
may be rather slim.
zoffix@leliana:~$ perl6 -e '... *'
*
in any at
/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm
line 1
in block <unit> at -e line 1
zoffix@leliana:~$ perl6 -e '... "This is a message!"'
This is a message!
in any at
/home/zoffix/.rakudobrew/moar-nom/install/share/perl6/runtime/CORE.setting.moarvm
line 1
in block <unit> at -e line 1
zoffix@leliana:~$
