Make possible to inkove a parser from another module

[dashbitco]

Make possible to inkove a parser from another module

[josevalim]

Yes, we need to improve the API around this. Today defparsec and defparsecp actually serve different purposes, we probably need a more explicit API for exporting and importing parsecs.

Although it is very important to note that traversing between modules requires creating binary references.

[josevalim]

@meox btw, if you want to break parsing apart, the suggestion is to actually compose on the combinators, since changing between modules will slow down parsing.

[meox]

Hi @josevalim,
I use the composition but in my case is not enough, because I'd like to have a way to define a "macro" to generate a very similar parser.

Immagine that you have to parse two different kinds of data structure:

• list: [a, b, c, d]
• tuple: {:x, 1, "Jose", 10}

if you try to write a parser you will end up to have more or less the same code.
So I saw two way:

• we can try to define the macro in the same module of the parser, but the problem here is that we need to force the compiler to compile the things in our order
• we can define the macro in a different parser but we have to permit the usage of defparsec from a different module.

[josevalim]

@meox if you break it at this level of granularity, then parsing will end-up being slow. Both of the issues you have mentioned are addressable with what parsec provides today.

Imagine you have a MyHelper module. The thing that is shared in both list and tuple to into collection_contents combinator.

defmodule MyHelper do
  import NimbleParsec

  def collection_contents do
    string() |> ... |> ...
  end
end

Now with the combinators defined, you can include them in the final module:

defparsecp :collection_contents, MyHelper.collectiion_contents()

list = string("[") |> parsec(:collection_contents) |> string("]")
tuple = string("{") |> parsec(:collection_contents) |> string("}")

What am I missing?

[meox]

Probably you are right.
My analysis started here:
#27

[josevalim]

@meox maybe it is better to compose combinators with regular functions then, rather than doing so with macros. Since you are encapsulating everything in macros, you are struggling with composing it, but if you rely on the combinators you should be fine.

[meox]

ok thanks, I'll try to put in practice your suggestion