This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-04
Channels
- # announcements (7)
- # aws (5)
- # babashka (72)
- # beginners (43)
- # calva (12)
- # cider (9)
- # clara (3)
- # clj-kondo (12)
- # cljdoc (32)
- # cljs-dev (10)
- # cljsrn (1)
- # clojure (78)
- # clojure-dev (50)
- # clojure-europe (17)
- # clojure-gamedev (8)
- # clojure-nl (1)
- # clojure-spec (30)
- # clojure-uk (3)
- # clojurescript (52)
- # core-async (1)
- # cursive (5)
- # datomic (8)
- # emacs (58)
- # events (2)
- # fulcro (5)
- # graalvm (7)
- # holy-lambda (37)
- # honeysql (9)
- # jobs (5)
- # leiningen (3)
- # lsp (7)
- # lumo (2)
- # malli (3)
- # meander (13)
- # membrane-term (64)
- # missionary (19)
- # music (3)
- # nextjournal (8)
- # off-topic (29)
- # pathom (16)
- # polylith (14)
- # portal (16)
- # re-frame (2)
- # reagent (5)
- # sci (14)
- # shadow-cljs (20)
- # spacemacs (6)
- # sql (1)
- # tools-deps (58)
- # vim (14)
There are three types of input data: [a] sequence of chars (standard parsing) [b] sequence of tokens (basically parsing, but after the lexing stage) [c] TREE of tokens (what we have) I can see how [a] == [b]; but I don't see how one define a generalization that covers both [b] and [c]. I'm not saying one does not exist, just that I'm not seeing it. Can you clarify on this ?
a tree is a recursion of sequences, so just take the parsing over a sequence and apply it recursively
CFG is a language that defines patterns over sequences of tokens. What defines patterns over trees ?
As far as I can see Cfg[Token] and Cfg[Cfg[Token]] both define patterns over sequences; can you point me at a research paper / book ? I need a more detailed exposition.
but like, if you write out a grammar, say in bnf, everything is a terminal or a rule, and the terminals are the tokens
if instead of putting in, like, literal 'if' in the grammar as the token, you say, the terminal is actually a member of this set of sequences and describe the set as a cfg
I think the core issue here is Vec<Vec<T>> does not represent the full space of Tree<T>; so this idea of Cfg[Cfg[Token]] seems to not recognize Trees.
Can you give an example value that satisfies Tree<T>
but not Vec<Vec<T>>
?
So you walk the list in the node parsing it, where each token type is itself tree to be matched against some other parser
Can you give an example value that satisfies Tree<T>
but not Vec<Vec<T>>
?
@hiredman: Here I think is the problem Cfg[T] pattern language over Vec<T> Cfg[Cfg[T]] is a pattern language over Vec<Vec<T>>
and one way to "parse" such a thing is to recursively parse everywhere the datatype does
so you can imagine a parsing that walks through List<String> building up a parse tree, and a fundamental operation of such a parser is doing an equality comparison of the strings in the list with the strings that are the terminals of the grammar
now say, what if you grammar is defined in some dsl/library that has some built in "functions" like "is-if-string?" that runs true when given the string "if"
so you go to your grammar and replace the if terminal with a "call" to is-if-string?, so instead of the parser doing an equality check it calls the predicate on the token
now change from string tokens to arbitrary data structures, and use a predicate like three-element-vector-all-0?