Get validated parse tree with no need for unwrap on Option

[siddharth-narayan]

Apologies if this is a simple question
Is there any way to get a validated parse tree? Assuming no errors, once I call parser.rule(), there should be no need for further unwraps. As I understand, this isn't a problem in java because the objects can be assumed to be non null?

I find it very tedious to constantly unwrap or ? when there's no need for it.

[alexsnaps]

Apologies if this is a simple question

Simple questions are the best!

Is there any way to get a validated parse tree? Assuming no errors, once I call parser.rule(), there should be no need for further unwraps. As I understand, this isn't a problem in java because the objects can be assumed to be non null?

I find it very tedious to constantly unwrap or ? when there's no need for it.

Sadly tho, I miss the issue here tho... Can you link to some actual code highlighting what you mean? You say Option, but do you mean Result (given the "assuming no errors")? Also, you need to consider this could be a function of your grammar... but maybe not, as I'm not sure I get what you mean. Some reproducible test case, with a clear explanation of the behavior your wish for would be really useful.

[siddharth-narayan]

Let's say I have this rule

addCorrespondingStatement
    : (CORRESPONDING | CORR) identifier TO addTo
    ;

fn convert_add_corresponding(c: AddCorrespondingStatementContext) {
	// These are Options
    c.identifier()
    c.addTo() }
}

As far as I understand, this is because ANTLR recovers from errors. However, in the case where I'd like to parse only content with no errors, it's really inconvenient. Is there some sort of AddCorrespondingStatmentContextValidated?

[alexsnaps]

Right, so you'd like the struct definition of AddCorrespondingStatementContext to declare fields right away over Option of said field types, is that right?
Now, I don't know that we can do that. These Context are mutated and "build up" as the parsing happens. And you can't have a field "un init'ed" in Rust. Another way that we could go about that is to have all these have a Default implementation and mutate these representation as we "go down the graph". But that would be possibly be a fairly expensive thing to do performance-wise.

Finally, and while it should indeed not happen, we can't guarantee there isn't a bug somewhere and an "invalid" state "leaked" out of the parser. Having a None where you don't expect one makes it real obvious, over "simply getting the Default representation of that struct in place".

I hope the reasoning makes sense. If you have thoughts how we can, given the constraints expressed here, have a friendlier API for end-users (i.e. you), I'd love to hear it :)

[siddharth-narayan]

Yes, that does make sense. I don't know much about how ANTLR does its parsing internally, so I don't know if I can suggest anything specifically useful.

Another way that we could go about that is to have all these have a Default implementation and mutate these representation as we "go down the graph". But that would be possibly be a fairly expensive thing to do performance-wise.

When a nonterminal is produced, is it not guaranteed to be correct? I guess it depends how the parser is generated, but I had assumed that this would be possible to create each Context struct from a nonterminal without an underlying Option.

If this is at all possible to do I would like to contribute, as I have already used this project twice and would appreciate this feature.

[alexsnaps]

If this is at all possible to do I would like to contribute, as I have already used this project twice and would appreciate this feature.

I just had another look, and I really have a hard time seeing how, without a huge refactoring, we could get rid of those Option fields. I'll be real honest, I don't even know for sure it's even feasible. It might be feasible for "some" of them. Maybe doing "late" construction. But that requires "tiny scope" muts, which that scope can be actually quite big.

Now that being said, I maybe somewhat tainted by the way things are currently and might be lacking imagination. I'd encourage you to explore the space somewhat. Maybe you see something... I'd also encourage you to share, if only with a draft PR, whatever you think might be way forward there early.

[siddharth-narayan]

After looking over Rust.stg and an example generated code, I think it's just that child_of_type is used everywhere instead of holding a reference to the child directly, dynamically producing an option based on child type. I think you're right it might require a (large?) refactor.

What do you think of the following:
Every ContextRuleGetterDecl gives
fn <r.escapedName>(&self) -> Result<Rc<<r.ctxName>Validated<'input>>, Rc<<r.ctxName>InValid>>

where the invalid version can be what currently exists, where child_of_type can be used. The validated version will only be what the grammar defines, no options (unless in grammar)

Do you think something like this is possible?

[siddharth-narayan]

I'd also encourage you to share, if only with a draft PR, whatever you think might be way forward there early.

Do you mean there's some urgency? I've started working on the runtime/codegen to first try and unjava-ify it. Would you like me to make a draft pr? It's highly unfinished of course

[alexsnaps]

No. No urgency whatsoever. But I'd rather avoid you investing too much time going down a rabbit hole. That's it. I'm usually in the camp of sharing early ¯_(ツ)_/¯