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
These are current signatures of parser and printer
defparser[S, E, A](grammar: Grammar[S, S, E, A]): (S, Input) => (S, E \/ (Input, A))
defprinter[S, E, A](grammar: Grammar[S, S, E, A]): (S, (Input, A)) => (S, E \/Input)
They assume chipping off the input (and appending to current output) at every consumption step defined by a user, for example
valspacing:G[Unit] = consumePure(
cs => (cs.dropWhile(c => c ==' '|| c =='\n'|| c =='\r'), ()),
{ case (cs, _) =>' ':: cs }
)
Because it's defined by user it may be arbitrary and inefficient. Because it's mandatory, it is also a source of inefficiency due to allocations that must happen.
The idea is to prototype a solution that allows inner optimizations of accessing the next consumed piece of input, for example using random access, without needing to have user-defined functions and requiring allocations.
This means instead of user-defined functions we have to allow to describe how consumption is supposed to happen. The complexity arises from the fact that Input is currently user-defined type and "description" would require to have implementation of consumption in the library itself, so we may need to constraint the Input to only certain types, i.e. specialize on certain types of Input.
The text was updated successfully, but these errors were encountered:
These are current signatures of parser and printer
They assume chipping off the input (and appending to current output) at every consumption step defined by a user, for example
Because it's defined by user it may be arbitrary and inefficient. Because it's mandatory, it is also a source of inefficiency due to allocations that must happen.
The idea is to prototype a solution that allows inner optimizations of accessing the next consumed piece of input, for example using random access, without needing to have user-defined functions and requiring allocations.
This means instead of user-defined functions we have to allow to describe how consumption is supposed to happen. The complexity arises from the fact that
Input
is currently user-defined type and "description" would require to have implementation of consumption in the library itself, so we may need to constraint theInput
to only certain types, i.e. specialize on certain types ofInput
.The text was updated successfully, but these errors were encountered: