Why materialize Output after event::process instead of exposing a iterator over events

[sssxks]

i am reading ra source to get some inspiration, and i am trying to understand Output.

/// Output of the parser -- a DFS traversal of a concrete syntax tree.
///
/// Use the [`Output::iter`] method to iterate over traversal steps and consume
/// a syntax tree.
#[derive(Default)]
pub struct Output {
    /// 32-bit encoding of events. If LSB is zero, then that's an index into the
    /// error vector. Otherwise, it's one of the thee other variants, with data encoded as
    ///
    /// ```text
    /// |16 bit kind|8 bit n_input_tokens|4 bit tag|4 bit leftover|
    /// ``````
    event: Vec<u32>,
    error: Vec<String>,
}

the rustdoc seems to imply it is space-optimized, probably for cache or storage purpose? however, it seems not the case when i dig deeper.

this is use site of Output:

        let mut p = parser::Parser::new(input);
        entry_point(&mut p);
        let events = p.finish();
        let res = event::process(events);
        res

// ... after return, it is used to build GreenNode
    let parser_output: Output = entry.parse(&parser_input);
    let (node, errors, _eof) = build_tree(lexed, parser_output);

output is produced via event::process, whose signature is fn process(mut events: Vec<Event>) -> Output, and consumed by build_tree(lexed: parser::LexedStr<'_>,parser_output: parser::Output,).

process mainly follows forward_parent pointer to resolve in a sequence, hense Output is a forward_parent free Event sequence. however, i am thinking whether we could avoid materializing Output altogether - we could provide a iterator with forward_parent resolution over the original Vec.

another clean up is to change Vec to save error and forward_parent pointers in side tables, which will make the parser directly produce Output-like compressed representation with 4 bytes for each event.

is there any specific reason for current design? also, as this change seems doable to me, i'd also like to ask will it probably make performance a little bit better? i haven't done profiling on current baseline though

[ChayimFriedman2]

Processing events without collecting is hard to do since events order can go back.