You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, Handle<X> only knows the range X matched at, which always presents the same view of X's substructure (i.e. the same ambiguities are always observed when visiting its descendants).
However, @eternaleye suggested adding lenses to Handle, with each lense (or "filter") consisting of a path through the SPPF (which could encode finite substructure compactly, or even be strongly typed), to the source of an ambiguity, paired with the choice made for that ambiguity.
(could it be possible to use only a ParseNode, i.e. node type and range, instead of a path, and therefore only need lenses: Map<ParseNode, Choice /*aka usize*/>?)
Disambiguation can thus be deferred, by propagating lenses to parents (which might be able to make a decision based on all the information they have available).
An extreme of this is doing disambiguation not by mutating the SPPF, but by computing the lenses that, combined, disambiguate from the root of the SPPF, deeply. A pure/immutable implementation of GLL might take this approach, and it could have positive implications for
Note: Handle is Copy right now, and reconciling that with lenses needs to be figured out still.
(one possibility could be adding another type parameter to Handle) EDIT: @eternaleye is suggesting using a reference to the map instead, which would keep Handle always Copy, and the disambiguator machinery could own the lenses, while only giving out references (more specifically, Option<&Map<ParseNode, Choice>>) in Handles, to the user-defined validation/preference logic.
The text was updated successfully, but these errors were encountered:
Right now,
Handle<X>
only knows the rangeX
matched at, which always presents the same view ofX
's substructure (i.e. the same ambiguities are always observed when visiting its descendants).However, @eternaleye suggested adding lenses to
Handle
, with each lense (or "filter") consisting of a path through the SPPF (which could encode finite substructure compactly, or even be strongly typed), to the source of an ambiguity, paired with the choice made for that ambiguity.(could it be possible to use only a
ParseNode
, i.e. node type and range, instead of a path, and therefore only needlenses: Map<ParseNode, Choice /*aka usize*/>
?)Disambiguation can thus be deferred, by propagating lenses to parents (which might be able to make a decision based on all the information they have available).
An extreme of this is doing disambiguation not by mutating the SPPF, but by computing the lenses that, combined, disambiguate from the root of the SPPF, deeply. A pure/immutable implementation of GLL might take this approach, and it could have positive implications for
Note:
Handle
isCopy
right now, and reconciling that with lenses needs to be figured out still.(one possibility could be adding another type parameter to
Handle
)EDIT: @eternaleye is suggesting using a reference to the map instead, which would keep
Handle
alwaysCopy
, and the disambiguator machinery could own the lenses, while only giving out references (more specifically,Option<&Map<ParseNode, Choice>>
) inHandle
s, to the user-defined validation/preference logic.The text was updated successfully, but these errors were encountered: