Gianni,
That is helpful. I don't think it conclusive. Since I am stating
the initial term is unknown, I think there is no legal statement
possible.
A sigilless variable could also start a statement.
I suppose textual parsing the terms of a statement is attempted before
checking the meaningfulness of identifiers. Here I think rakudo is
looking for the signature before trying to resolve the call, then bails
before checking the first term's validity which could offer more
info about a failure.
Like you, I don't know what an 'infix stopper' is. All of 'infix
stopper', 'control word', and 'modifier loop' are phrases that don't
exist on docs.raku.org.
I think I interpreted "before the expression" poorly.
Thanks,
rir
On Wed, Feb 24, 2021 at 06:18:11PM +0000, Gianni Ceccarelli wrote:
> On 2021-02-24 rir <rir...@comcast.net> wrote:
> > It is just an odd puzzle for me that "UnknownBareId KnownClassId"
> > is accepted has the start of a valid statement. How would such
> > a statement be completed?
>
> Let's go through a few examples::
>
> raku -e 'foo 1'
> ===SORRY!=== Error while compiling -e
> Undeclared routine:
> foo used at line 1
>
> simple and clear error: syntax is correct, ``foo`` must be the name of
> a sub, but it's never defined.
>
> Closer to what you got::
>
> raku -e 'foo 1 2'
> ===SORRY!=== Error while compiling -e
> Two terms in a row
> at -e:1
> ------> foo 1⏏ 2
> expecting any of:
> infix
> infix stopper
> postfix
> statement end
> statement modifier
> statement modifier loop
>
> notice the list of expected things. Did we mean ``foo 1 + 2``, ``foo
> 1, 2``, ``foo 1 if 2``?
>
> Now for what you saw::
>
> raku -e 'foo 1 { 2; }'
> ===SORRY!=== Error while compiling -e
> Unexpected block in infix position (missing statement control word before
> the expression?)
> at -e:1
> ------> foo 1⏏ { 2; }
> expecting any of:
> infix
> infix stopper
> postfix
>
> Again, did we mean ``foo 1 ~~ { 2; }``, ``foo 1, { 2; }``, ``foo 1 if
> { 2; }``?
>
> In all these cases, ``foo`` is presumed to be the name of a sub,
> because (I think) it's at the start of the statement, and it's not a
> known keyword. Then the parser tries to make sense of the following
> tokens, and gets confused.
>
> So, to answer "How would such a statement be completed?":
>
> * with an infix (a comma, any infix operator that can take (in your
> case) a type and a block, …)
> * I'm not sure what an "infix stopper" is
> * a postfix (like ``if``, ``for``, ``with``…)
>
> --
Dakkar - <Mobilis in mobile>
> GPG public key fingerprint = A071 E618 DD2C 5901 9574
> 6FE2 40EA 9883 7519 3F88
> key id = 0x75193F88
>
