❔ Alternatives to Antlr for C#
Antlr needs a runtime library, and the parsing is veeery slow.
Any good alternative?
Any good alternative?
Clanguage parser
TA parser generator
T@T = (Q, Σ, Γ, q₀, *, δ) you have any suggestions?
LInstead I'd suggest pasting into google, takes less time than asking in a question thread
LI'd honestly make a suggestion based on the exact use-case
LIs it really slow? On what grammar? Do you have additional non-functional requirements? (good error-recovery, incrementality, ...)
LIf you just need speed, then I'd look around in the world of LR parsers, they are generally linear-time, if you can find a sensible upped bound for the lookahead (sensible sadly meaning 0 or 1 in the vast majority of cases)
LIf you are dealing with a truly nasty grammar you can't hammer into something an LR generator can eat, then you might also want to look at the handwriting option
Aconsider writing a simple recursive descent parser manually. that's how all programming language compilers parse code nowadays
RIt is a file format parser, I have the ANTLR grammar I've made already
RMaybe generating a railroad diagram from it would help me reimplementing it from scratch
RI generally create the parsers from scratch, but this one is "strange", so I was trying to auto-generate it
RFbx.g4937B
LThe question was likely for people that actually know a thing about parsing and the standard ecosystem around it. Maybe the question simply wasn't for you
R3D FBX files ^^^
RThe structure is kinda simple, but with some strange rules
RLemme see if I can generate a railroad diagram from that
LThat'd help a lot in reading it, thanks
RTbh, I have to test this grammar again, one sec
RI'm not in the mood to rewrite it from scratch, I've spent months in this project alone, so if I have to redo the parser, it must be the last time...lol
LThe grammar doesn't look complex, just a bit weirdly structured
RIt is, the file format is strange
LBut if it's for gigantic 3D mesh/skeletal/animation/whatever data, then I can imagine speed being concerning, LL(*) is fast but not "file-format-parser fast"
RI just need a diagram, I guess, so I can rewrite it from scratch doing it the right way
LI'll look through more in depth to see if this is something remotely parsable with LR(0), If it is, then you are in luck, that's linear time
RTks
LDon't take me out of context and read on
RThis is just a chunk of an actual file:
LYep, this should be dead simple to parse with basically anything
LThere's no ambiguity, at least not at first glance. Most of your concern would be the lexer then tbh
RThere are many ambigualities
RTrust me...lol
LWhere? I don't see any honestly
LWhat I see here is a format where most of your concern would be fast lexing to eat the file as fast as you can
R this is a node with metadata
this is a node with a single sub-node
this is a node with multiple properties
This is an array:
this is a node with a single sub-node
this is a node with multiple properties
This is an array:
RThe there acts as a from the properties, basically
RBut you see there is the
*There is a catch, and I can't remember where, exactly, which breaks all the parser, if not parsed correctly
RThere is a long time I've written the parser tbh
LProperties70: this is a node with a single sub-nodeWhat's the difference between these 2? I don't immediately see any notational diff
P: this is a node with multiple properties
R and
aa*That shouldn't be a problem
LOooh wait, is the space significant there?
RNot sure, haven't tested without it
LI can see dataValue can derive a space, so and would be different?
RBut there is something with the newline char, that I can't recall exactly