This ticket tracks including line/column/character position information with parsed edn::Value trees. It addresses #149 (comment); it is a pre-requisite, I think, for #168.
Concretely, I think we want a pair type like:
struct edn::ValueAndSpan {
value: edn::Value,
span: edn::Span,
}
which encapsulates a Span of some description coming out of the PEG EDN parser. Sadly, this means we'll need to rewrite or duplicate the edn::Value type to have edn::ValueAndSpan children. I could imagine something like:
edn::Value<V>, where V parameterizes the children (so V = edn::Value is what we have now)
or something like
edn::Value<S>, where S parameterizes the span (so S = () is what we have now).
We'll want to expose this new type, and probably convert to the existing type as well (just dropping all the spans).
This is pretty awkward -- better suggestions appreciated. This could be a good first bug if the patch doesn't try to change existing code too much (i.e., just adds new types and conversions into existing types).
This ticket tracks including line/column/character position information with parsed
edn::Valuetrees. It addresses #149 (comment); it is a pre-requisite, I think, for #168.Concretely, I think we want a pair type like:
which encapsulates a
Spanof some description coming out of the PEG EDN parser. Sadly, this means we'll need to rewrite or duplicate theedn::Valuetype to haveedn::ValueAndSpanchildren. I could imagine something like:edn::Value<V>, whereVparameterizes the children (soV = edn::Valueis what we have now)or something like
edn::Value<S>, whereSparameterizes the span (soS = ()is what we have now).We'll want to expose this new type, and probably convert to the existing type as well (just dropping all the spans).
This is pretty awkward -- better suggestions appreciated. This could be a good first bug if the patch doesn't try to change existing code too much (i.e., just adds new types and conversions into existing types).