This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-14
Channels
- # ai (4)
- # babashka (4)
- # beginners (46)
- # biff (5)
- # calva (12)
- # clojure (6)
- # clojure-austin (13)
- # clojure-dev (27)
- # clojure-europe (62)
- # clojure-nl (1)
- # clojure-norway (17)
- # clojure-spec (2)
- # clojure-uk (12)
- # clojurescript (10)
- # cursive (3)
- # datahike (26)
- # datalevin (9)
- # datomic (7)
- # gratitude (4)
- # honeysql (9)
- # hyperfiddle (12)
- # instaparse (2)
- # lsp (65)
- # membrane (7)
- # missionary (2)
- # off-topic (8)
- # polylith (33)
- # portal (7)
- # quil (1)
- # re-frame (4)
- # reagent (18)
- # releases (3)
- # ring (3)
- # spacemacs (2)
- # specter (4)
I'm trying to add some extensibility to a parser. The basic example I have is matching tokens in a sequence differently based on some optional 'front matter' that can occur at the beginning of a stream.
The general idea would be to use only text that has already been matched to define the special tokens. So the first example has no special tokens at all. The second example would treat *
as a special token, but not -
. The third would treat both *
and -
as special tokens. Right now this doesn't work because the ordered choice treats anything that could be a special token as actually a special token. Would it be possible to constrain the grammar to make this work? Or is this, in effect, trying to add too much context sensitivity to the parser, and therefore pushes Instaparse beyond what can be achieved even with a recursive parser?
I think the term that I was struggling to find was backreferences, which are supported in https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/regex/Pattern.html:
> \n
Whatever the nth capturing group matched
> \k<name>
Whatever the named-capturing group "name" matched