wavebeem / bread-n-butter Goto Github PK

It's very easy to create parsers which generates recursively nested values. When writing a lexer, we'd expect the output to be a flat (1D) array of tokens (or bnb.ParseNodes). So I find myself constantly mapping the parse result with a flatten function:

type Node = bnb.ParseNode<string, string>;
type NodeOrArrayOfNode = Node | NodeOrArrayOfNode[];

function flatten(nodes: NodeOrArrayOfNode) {
  const result: Node[] = [];
  function addNode(node: NodeOrArrayOfNode) {
    if (Array.isArray(node)) {
      for (const innerNode of node) {
        addNode(innerNode);
      }
    } else {
      result.push(node);
    }
  }

  addNode(nodes);
  return result;
}

// usage:
const parser = bnb
  .text('a')
  .node('a')
  .and(bnb.text('b').node('b'))
  .or(bnb.text('c').node('c'))  // => [bnb.ParseNode<"a", "a">, bnb.ParseNode<"b", "b">] | bnb.ParseNode<"c", "c">
  .map(flatten);  // => bnb.ParseNode<string, string>[]

It would be great if this mechanism is provided as a method of bnb.Parser.

This also helps make sense of the inferred type information, otherwise it would quickly collapse into a pile of gibberish (for instance, in the example above, for such a simple parser, the type yielded before the map call is already not quite readable).

As you requested, I open a new issue for the functions which where missing for my project. The most important ones were then, skip and notFollowedBy, anyway I saw that the former where already on the TODO list. I think that lookahead is the negative function of notFollowedBy, so it probably is a good idea to add it too, even if I would name it followedBy.

If you want, I have a little bit of available time and can make PRs to add these functions.

Hi there; hoping none of this comes across with an entitled tone, I'm just looking for some signal about the status of this project. I'm building a side-project and looking around for promising typescript combinator libraries and I stumbled across this while looking at jneen/parsimmon#230. Is this library still being worked on?

When implementing a lexer, we always want to keep all the tokens, even for the trivial ones (i.e. whitespaces and separators), in order to create a high-fidelity AST which can be mapped back to the original source. This renders some of the functions less useful, e.g. bnb.sepBy which discards the separators, and bnb.wrap which discards the wrappers. Especially bnb.sepBy because it's cumbersome to imitate its behavior with other constructs.

One thought is to add an optional nondiscarding parameter to these functions, when specified as true, will keep these was-to-be-discarded tokens in the return value.

The ESM export should just be a wrapper around the CJS one, because Node ESM support is awful.

https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1

Hi, @wavebeem !
I've read your implementation and most of design is looking good to me. IMHO, checking parsing state with string is not bad, but class-level type checking looks more sufficient and clean for me. I mean ParseOK<T> or ParseFail can be defined as classes, not as simple data structure, and it would be better for developer because easily understandable.

The following method:

merge<A, B>(a: ActionResult<A>, b: ActionResult<B>): ActionResult<B>

at

Reason:

1. It doesn't depend on this.
2. It might be interpreted as merging of contexts, which it doesn't seem to be.
3. From a semantic point of view, it has nothing to do with a context directly.

• \n should probably be considered as part of the current line. Only the next character should advance the line number.

jneen/parsimmon#331

There are several code snippets that use lengthy .chain chains instead of a simple bnb.all. Now that bnb.all exists, let's use it!