Implement 'is parsed'

[masak]

Behind a feature flag.

The minimum viable feature would be enough to close this issue.

[masak]

Blocking on #174.

[vendethiel]

should is parsed actually take an argument as to which category it is?

example:

sub foo() is parsed(/a+/):term {

}

sub bar() is parsed(/ <EXPR> if <EXPR>/):statement {
}

(yes, I know, 007 doesn't have adverbs. Doesn't really matter)

[masak]

The category information, for better or worse, goes on the name of the identifier:

macro infix:<?>(lhs, rhs) is parsed(/"?" <.ws> ["wooga" <.ws>]* "?"/) {
    return quasi { {{{lhs}}} + {{{rhs}}} };
}
say(1 ? wooga wooga wooga wooga ? 7);        # 8

macro statement:<next>() is parsed(/"next" <.ws> <identifier>?/) { ... }

Currently leaning towards not allowing is parsed on subs, simply because subs are very runtime-y, can be passed around the program, etc. This feels incompatible with statically knowable compile-time textual information. In a way, the strength of subs as first-class citizens also damns them as something that can't be is parsed realiably.

[vendethiel]

When you pass a sub as an argument (etc), the name changes. Which is really what makes this be.

I think it makes sense that is parsed really binds to that name. Just like my &a = infix:<~>; gives you a function without any special syntax on top. (and this goes back to sub a(infix:<+>) {3 + 4}, i.e. sub a(x is parsed...) {}, mmh...)

[masak]

No longer blocking on #174, seeing as we have regexes now. :tada:

[masak]

When you pass a sub as an argument (etc), the name changes. Which is really what makes this be.

I think it makes sense that is parsed really binds to that name. Just like my &a = infix:<~>; gives you a function without any special syntax on top. (and this goes back to sub a(infix:<+>) {3 + 4}, i.e. sub a(x is parsed...) {}, mmh...)

Yes, what you're saying is true. And I'm not fundamentally opposed to making is parsed work for subs. It's more like, I don't see it as being on a critical path. More of an it-would-be-nice kind of thing.

One story that's missing currently for is parsed subs is, what parameters do they get from the is parsed regex? With macros, we're expecting/hoping that Q nodes will find their way into the parameters. Do subs get Q nodes too? Or do they get the "corresponding runtime values"? If the latter, how do we deal with the fact that expressions and identifiers have a value, but most other constructs (statements, traits, properties, argumentlists) don't?

[masak]

Now that we have regexes, I would like us to make is parsed work for something really really simple. Something like

macro statement:whoa() is parsed(/"whoa!"/) {
    return quasi @ Q::Statement {
        say("whoa!");
    }
}

whoa!;        # prints "whoa!\n"

I haven't tried this myself, nor thought about what it would take. But clearly something needs to be installed somewhere. Probably a decent starting point is the operators, which are an open set and which can be installed.

I'll accept PRs on this. If it's still open in a week or so, I'll try it myself. :smile:

[vendethiel]

Not promising anything again, but it also sounds interesting. Should statement: add something to the statement category?

Should there be a statement:uds (user defined statement) that'd look at the is parsed list for the current scope?

[masak]

Not promising anything again, but it also sounds interesting. Should statement: add something to the statement category?

Yes, but note that that in itself has no observable effect except to change what the parser parses. There's no introspection into the statement category, for example. And until further notice, you can only subrule-call <statement>, not <statement:moo>.

Should there be a statement:uds (user defined statement) that'd look at the is parsed list for the current scope?

That could work, yes. (Though, again, I haven't thought deeply about it.) The thing to make sure is that things behave sanely with the old, hard-coded statement types.