<companion_cube>
I find this bizarre, I've never seen that argument. What's the issue with angstrom?
agentcasey has joined #ocaml
<discocaml>
<yawaramin> the biggest issue is error reporting, like if you want to report the line and column number and a good error message on parse errors you have to jump through a lot of hoops. but, depending on what kind of compiler you're making, you might be able to get away with slightly worse error messages
<dh`>
there are two basic problems with parser combinators; one is that they don't check for ambiguities, the other is that you almost always end up with a lot of fragile and unmaintainable backtracking logic
<dh`>
the latter is the more serious problem
<dh`>
the former just puts them in a bad position relative to parser generators or handwritten recursive descent
<companion_cube>
Oh should have read the context more. For parsing text, I'm ambivalent on whether they're a good idea in general
<companion_cube>
But they're pretty ok to parse protocols and binary formats
<dh`>
ah that is true
<dh`>
different requirements and considerations there
<companion_cube>
(and imho, aside from literal programming languages, one should strive to do as little text parsing as possible)
<dh`>
I don't agree with that either, parsing is cheap and being afraid of writing parsers leads to things like user-facing xml or yaml
<dh`>
and horribly misbegotten stuff like the executable yaml that github uses for github actions
<companion_cube>
I think it depends, sometimes xml might be better than a bespoke markup thing for example
<companion_cube>
But yeah, ok, parsers can be good but they shouldn't be the first thing to reach for
<companion_cube>
(for github actions they should have used lua or js from the start)
<discocaml>
<yawaramin> it's all bash scripts in the end
agentcasey has quit [Ping timeout: 260 seconds]
<companion_cube>
It really shouldn't be tough
<companion_cube>
Though*
<companion_cube>
I mean it could at least be typescript that calls commands
<companion_cube>
Better than yaml at conditional execution and such
<discocaml>
<yawaramin> if TypeScript, why not OCaml? 🤔
<discocaml>
<sim642> You could write your entire CI in typescript and put all of it into a custom GitHub Action. Probably won't work out too well in the end though
<discocaml>
<sim642> It boils down to the similar debate about build systems. If they are full blown scripts, then you get all the flexibility but static analysis is difficult. If you have a custom file format, then you're more restricted but can easily analyse them
<discocaml>
<sim642> In the full generality of scripting, even figuring out all of the dependencies could easily require running the whole thing because the dependencies may be based on some dynamic factors
<dh`>
in a hand-written recursive descent parser, you'll usually do explicit lookahead at one point to figure out which case you're in, rather than backtracking
<dh`>
granted there isn't necessarily a lot of difference, especially for people who don't know what they're doing (in either style)
<dh`>
but IME, having a clear decision point is a lot more maintainable
<dh`>
also, you and I should not engage on this topic
<discocaml>
<yawaramin> doesn't the IRC bridge carry our usernames over correctly from Discord? i feel like people often think they are talking to 'discocaml'
<dh`>
wasn't it you I got into a huge fight with over parsing? if not, I apologize
<discocaml>
<yawaramin> nope
<dh`>
it is easy to mix people up
<dh`>
in that case
<dh`>
yes, you can, but parser combinators libraries usually aren't intended to handle deep lookahead
<discocaml>
<yawaramin> we fought about squashing commits 😉
<dh`>
heh
<dh`>
that's relatively unimportant!
<dh`>
i have written any number of C parsers by hand (you'd think I'd learn and write a definitive one, but that hasn't happened yet)
<dh`>
and the C grammar has some things that require nontrivial backtracking if you do it that way
<discocaml>
<yawaramin> would be interesting to see a hand-written recursive descent parser in OCaml for JSON to compare with the Angstrom one above
<dh`>
wouldn't be hard to make it more readable, I thought that was haskell when I first looked at it
* dh`
hides
<dh`>
anyway that's the sort of thing I might do for amusement on sunday afternoon, except that I vaguely recall json is overtly simple but has a whole bunch of demons in the corners
<dh`>
and/or the spec is incomprehensible (but there I might be thinking of yaml or one of the others)
<dh`>
anyway on the subject of confusing people, it's not that anyone thinks they're talking to "discocaml" after the first five minutes, but there is definitely an effect where it impedes the brain's pattern-matching
<dh`>
furthermore you can't /whois across the bridge and there are various things that don't come across that make it harder to differentiate
<companion_cube>
Yawaramin it carries if you read correctly
<dh`>
and other things that discord has like avatars don't show
<companion_cube>
If you want something similar look at the cbor parsers, they're handwritten (both in `cbor` and in containers)
<companion_cube>
But it's easier to parse than json
Frostillicus has quit [Ping timeout: 248 seconds]
Frostillicus has joined #ocaml
<discocaml>
<yawaramin> > I thought that was haskell when I first looked at it
<discocaml>
<yawaramin> dh: it's written in an old style, imho using let-operators gives us much cleaner-looking parsers, eg I thought that was haskell when I first looked at it