Skip to content

peg: optional* word for deciding between f and failed match#3172

Open
olus2000 wants to merge 1 commit intofactor:masterfrom
olus2000:peg-explicit-option-variant
Open

peg: optional* word for deciding between f and failed match#3172
olus2000 wants to merge 1 commit intofactor:masterfrom
olus2000:peg-explicit-option-variant

Conversation

@olus2000
Copy link
Copy Markdown
Contributor

Currently there is no way to differentiate between the AST f and a failed match in the AST produced by optional. I present an alternative that allows to distinguish these two cases. Naming scheme follows at*. Several behaviors were considered:

  1. Puting value t or f f in the parent AST.
  2. Producing the AST { value } or f (implemented by the PR).
  3. Producing { value t } or { f f } so it can be destructured and treated similarly as at*.
  4. Producing { value } or { } so it can be branched on with if-empty family.
  5. Producing value wrapped in a special tuple or f.
  6. Producing value or a special failure value.

Option 1 is impossible to implement in current PEG vocab implementation since it requires returning an AST of two elements.

Option 2 has been chosen because it retains the property of optional that a truthful value is returned on successful match allowing branching using usual conditional combinators, while also allowing a distinction for when the enclosed value has been ignored (an empty array is returned in such case).

Option 3 is the closest in behavior to at* but requires manual checking for ignore which can't be dropped from the output since a variable amount of elements here would cause problems.

Option 4 has the benefit of returning the same type of value every time, but requires manual checking for ignore.

Option 5 is very similar to option 2, but requires implementing a new type which only purpose will be to be destructured ASAP, and requires manual handling of ignore.

Option 6 doesn't always return a truthy value on success and never returns a falsy value on failure, which breaks similarity with optional. Otherwise it's a good solution.

@melted
Copy link
Copy Markdown
Contributor

melted commented Feb 1, 2026

There is another solution, that optional takes a default value to return in case it doesn't match. Then the user could select something suitable for their case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants