Is it possible to define recursive/inter-dependent parse combinators in NimbleParsec?

Yes, you can have recursive combinators. But they need to be defined as defparsec in order to create their own context. They will need to be defined in their own module since they become functions. Something like (not complete):

defmodule Combinators do
  import NimbleParsec
  
  defparsec :asmexpr, 
    keyword_asm
    |> optional(keyword_volatile)
    |> concat(lparen)
    |> parsec(:expr)
    |> optional(asmoutput)
    |> concat(rparen)
    
  defparsec :primaryexpr,
    choice([
      parsec(:asmexpr),
      ifexpr,
      keyword_break |> optional(breaklabel) |> optional(parsec(:expr)),
      keyword_comptime |> parsec(:expr),
      keyword_nosuspend |> parsec(:expr),
      keyword_continue |> optional(breaklabel),
      keyword_resume |> parsec(Lexpr),
      keyword_return |> optional(parsec(:expr)),
      optional(blocklabel) |> concat(loopexpr),
      block,
      curlysuffixexpr
    ]) 

  # Other combinators
end

They will need to be defined in their own module since they become functions.

I am trying to keep the structure and naming convention of Zig’s official peg so I’m using this kind of workaround for function and variable with same name. No sure if this would work.

expr = parsec(:expr_parsec)
.... others
boolorexpr = boolandexpr |> optional(keyword_or |> concat(boolandexpr))
expr = boolorexpr
.... others
defcombinatorp(:expr_parsec, expr, export_metadata: true)

• after around 30s I got errors

==> kinda
Compiling 1 file (.ex)
Compiling lib/parser.ex (it's taking more than 10s)

== Compilation error in file lib/parser.ex ==
** (FunctionClauseError) no function clause matching in NimbleParsec.Compiler.label/1    
    
    The following arguments were given to NimbleParsec.Compiler.label/1:
    
        # 1
        10
    
    Attempted function clauses (showing 10 out of 12):
    
        defp label({:string, binary})
        defp label({:label, _combinator, label})
        defp label({:bin_segment, inclusive, exclusive, modifier})
        defp label(:eos)
        defp label({:lookahead, combinators, _})
        defp label({:repeat, combinators, _, _})
        defp label({:eventually, combinators})
        defp label({:times, combinators, _})
        defp label({:choice, choices, _})
        defp label({:traverse, combinators, _, _})
        ...
        (2 clauses not shown)
    
    (nimble_parsec 1.2.3) lib/nimble_parsec/compiler.ex:960: NimbleParsec.Compiler.label/1
    (elixir 1.14.2) lib/enum.ex:1755: anonymous fn/2 in Enum.map_join/3
    (elixir 1.14.2) lib/enum.ex:4292: Enum.map_intersperse_list/3
    (elixir 1.14.2) lib/enum.ex:1755: Enum.map_join/3
    (elixir 1.14.2) lib/enum.ex:1755: anonymous fn/2 in Enum.map_join/3
    (elixir 1.14.2) lib/enum.ex:4292: Enum.map_intersperse_list/3
    (elixir 1.14.2) lib/enum.ex:4292: Enum.map_intersperse_list/3
    (elixir 1.14.2) lib/enum.ex:1755: Enum.map_join/3
could not compile dependency :kinda, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile kinda", update it with "mix deps.update kinda" or clean it with "mix deps.clean kinda"

• For anyone who might be interested, here is the implementation: Zig parser in elixir based on https://github.com/ziglang/zig-spec/blob/master/grammar/grammar.y · GitHub

more updates:

• defining combinators with variables will lead to giant expressions, so I am trying to use defcombinatorp to define all combinators
• got this error: Fail to create combinator of consecutive repeats · Issue #113 · dashbitco/nimble_parsec · GitHub

update:

• after changing all combinators from variable to defcombinatorp, it compiles fast
• the parsing doesn’t terminate now, there should be some other bugs
• new version: Zig parser in elixir based on https://github.com/ziglang/zig-spec/blob/master/grammar/grammar.y · GitHub

update:

• as expected, there are many bugs
• one approach I found to debug combinators with NimbleParsec is to export all the sub combinators with defparsec to make it possible to run smaller tests to see if it works

also, adding tag to the combinator also help. Often the matching works but it is not matched by expected combinators

This may be of interest to you, though I’m not certain on its status: GitHub - E-xyza/zig_parser: Zig Parser for Elixir · GitHub

It is created with GitHub - ityonemo/pegasus: peg -> nimbleparsec · GitHub

An unrelated thought, but curious of the advantages and disadvantages of the PEG route vs a traditional lexer + parser

It works (well enough for my zigler 0.10.x development branch) and is currently designed to parse zig 0.10.x

It works!
Do you have any plan for source code generation from a Zig AST in Elixir?

I don’t. Actually in the long run I want to deprecate using the zig parser because there will ideally be compiler hooks in zig that will let us see this information without having to do it again