Parsers generators allow you to write code that cr...
# thinking-together
j
Parsers generators allow you to write code that creates trees (usually), from a string of characters. So a way of creating a sort of abstractly 2D thing from a 1D representation. Is there an equivalent tool for generating representations from symbols arranged in 2D? A node-and-arrow parser generator, for example? Something in the graph database world?
I think a good small example would be a tool that allowed you to define linear graphemes, which is ironically both above ("we don't process 2D images") and below ("we already have characters") the scope of parser generators. Imagine describing "two parallel straight lines of the same length connected at an obtuse angle by a constant radius curved line" for the uppercase U. Are there tools for that?
A large example would be something that detects and parses UML diagrams on a whiteboard. Which seems very promising.
m
Not sure it's what you are looking for but the cypher query language is kind of "ascii art graph pattern matching"
Copy code
MATCH (nicole:Actor {name: 'Nicole Kidman'})-[:ACTED_IN]->(movie:Movie)
WHERE movie.year < $yearParameter
RETURN movie
g
- FYI - there are 2 kinds of parser generators 1. parser generators based on language definitions (YACC, LR(k), etc.) 2. parser generators based on DSLs for specifying parsers (PEG, Ohm-JS, etc.) - DaS (Diagrams as Syntax) If you are interested in experiments, I would be glad to share - I argue that graphics is not the problem, but ascribing meaning (semantics) to the diagrams is the problem, start small and build up, e.g. - what does a “box” compile to? - what do boxes-with-ports-and-arrows compile to? - what do concentric boxes compile to? - “we already have characters” - we use characters for IDEs (aka programming languages) only because mid-1900s hardware made it easier to grok grids of non-overlapping, small bitmaps
j
I'm not clear what the difference is between a "language definition" and an expression in a "DSL for specifying parsers". But what I'd love to see is an example of 1 or 2 where the elements being parsed are graphical... lines, points, colours, shapes. Graphics is not a problem, agreed. And you can always roll-your-own in terms of parsing from some unusual user input. It's just a data tarnsformation. I'm just curious if the idea of parsing from graphical input has ever been abstracted in the way that is has for text.
a
like OCR but for symbols that aren’t necessarily characters 😉
I’ve drawn thousands of whiteboards over the years… transcribing them into diagram drawing software is usually an opportunity to revisit, clarify and edit. 😅
g
collecting dust on my shelf - https://link.springer.com/book/10.1007/978-1-4612-1676-6 - (tc;dr) - all you really need is SVG + contains () + intersects () + connectedTo () - see sections “Expressive Power” and “Ambiguity Detection” in https://en.wikipedia.org/wiki/Parsing_expression_grammar - PEG defines a parser in a top-down manner (TDPL), e.g. “if this matches, try to match this next” - LR(k) and LL(k) define languages in a bottom-up manner, e.g. “if this looks like a number, then bubble it upwards as a number” (regardless of the context) ; this is what is taught as “language theory”, and is commonly understood to form the basis of parser generators - TDPL is order-dependent, Lx(k) is not order-dependent (but more restricted)
👀 1