parsley.errors
Type members
Classlikes
This is the class used to build Parsley's default error messages.
While it compiles with the ErrorBuilder
typeclass, it should not
be considered a stable contract: the formatting can be changed at any
time and without notice. The API, however, will remain stable.
This is the class used to build Parsley's default error messages.
While it compiles with the ErrorBuilder
typeclass, it should not
be considered a stable contract: the formatting can be changed at any
time and without notice. The API, however, will remain stable.
- Since
3.0.0
This typeclass specifies how an error generated by a parser should be
formatted. An instance of this trait is required when calling parse
(or similar). By default, Parsley defines its own instance for
ErrorBuilder[String]
found in the ErrorBuilder companion object.
This typeclass specifies how an error generated by a parser should be
formatted. An instance of this trait is required when calling parse
(or similar). By default, Parsley defines its own instance for
ErrorBuilder[String]
found in the ErrorBuilder companion object.
To implement this trait, you will need to define a number of methods
as well as decide on the representation types for a variety of different
components. The relation between the various methods is closely linked
to the types that they both produce and consume. If you only want to change
the basics of formatting without having to define the entire instance, you
can inherit from DefaultErrorBuilder
, but this will lock in your
implementation types (type aliases cannot be overriden in Scala).
- Type Params
- Err
The final result type of the error message
- Since
3.0.0
- Companion
- object
This module contains combinators that can be used to directly influence error messages of parsers.
This module contains combinators that can be used to directly influence error messages of parsers.
- Since
3.0.0
Revisions help to ensure backwards-compatibility when the ErrorBuilder
API changes.
By mixing in a Revision
to your instances, you are advertising that you want to remain
compatible with that version of the API. If the API changes with ''minor'' version
increases, then the revision mixed in will implement a compatiblity layer to ensure
that your code should still compile. If you want to opt into a more recent revision,
you just change the mixin. A ''major'' version bump will clear the revisions back to
Revision0
again.
Revisions help to ensure backwards-compatibility when the ErrorBuilder
API changes.
By mixing in a Revision
to your instances, you are advertising that you want to remain
compatible with that version of the API. If the API changes with ''minor'' version
increases, then the revision mixed in will implement a compatiblity layer to ensure
that your code should still compile. If you want to opt into a more recent revision,
you just change the mixin. A ''major'' version bump will clear the revisions back to
Revision0
again.
- Since
3.0.0