<discocaml>
<._null._> Just to be sure, Pratt parsing is completely subsumed by menhir, it can just be much more annoying to write in menhir, right ? The only definite advantage I know of Pratt parsing is for variable precedence operators
<discocaml>
<contificate> I don't think it is subsumed by Menhir
<discocaml>
<contificate> Haskell is famously parsed by a LALR(1) parser generator but, as you mention, it has user-defined precedence and requires a tree fixup pass (akin to Pratt's algorithm) in the compiler
<discocaml>
<contificate> so there's variable and also dynamic, in that you could parameterise the parser with different precedences and basically emulate a GLR parser in some contexts
<discocaml>
<contificate> so there's variable and also dynamic, in that you could parameterise the parser with different precedences and basically emulate what a GLR parser may succeed to parse in some fork of the parser in some contexts
<discocaml>
<contificate> ignoring any formal arguments about how powerful LR(1) parsing is, there's no doubt it's tedious, difficult to maintain, difficult to debug, difficult to find people skilled enough to contribute effectively, etc.
<discocaml>
<contificate> and that's not even citing the weak arguments you usually get which concern error recovery and error messages, which Menhir can deal with decently
<discocaml>
<._null._> Disregarding parsing power, I want a tool which prevents me from resolving conflicts unknwoingly
<discocaml>
<contificate> I like Pratt parsing, it's like you're defining a step-wise semantics for the parser, in the fairly obvious way: each left denotation is asking what you do when encountering a token, given some "left" you've already parsed etc.
<discocaml>
<contificate> I think coverage is all you need
<discocaml>
<._null._> Is that testing ? I prefer formal proofs
Frostillicus_1 has joined #ocaml
myrkraverk_ has quit [Read error: Connection reset by peer]
<discocaml>
<contificate> unfortunate, I find tests cheaper and more plentiful and more viable
<discocaml>
<contificate> would you consider translation validaton as sufficient
<discocaml>
<contificate> that's how compcert works in certain parts, right? its register allocation algorithm itself isn't proved correct, its output is verified to be correct w.r.t the constraints it determines
<discocaml>
<contificate> would you consider translation validation as sufficient
<discocaml>
<._null._> I don't care if the generator is proven correct, only about its output if that's your question
<discocaml>
<._null._> But the generator should be able to take a grammar and some disambiguation hints as inputs and output a sound parser
<discocaml>
<._null._> or fail if the disambiguation hints aren't sufficient
<discocaml>
<contificate> yes, but how many yaks do you want to shave to determine those hints
<discocaml>
<contificate> I appreciate the ideal, but my main gripe is purely with "just use menhir" polling results, with no nuance about what you're using it for, the inherent learning curve of LR parsing, etc.
<discocaml>
<contificate> if you are happy to spend a lot of time and energy and master the fine arts of LR grammar design and disambiguation, great - I feel I got quite close and then just got tired of it
<discocaml>
<._null._> What is "LR grammar design" ? What LR is it ? I would believe it's all about the disambiguation
<discocaml>
<._null._> Then the disambiguation has to be improved, I won't deny it
<discocaml>
<contificate> well, you have to massage grammars to make them compatible with these tools
<discocaml>
<contificate> if you look at basically any grammar online, it's not suitable for generation by any parser generator
<discocaml>
<contificate> like https://people.mpi-sws.org/~rossberg/sml.html this purely for human consumption, as it expresses the important rules, SML grammars for mlyacc have to be structured in various ways to work
<discocaml>
<contificate> the "grammar design" is factoring a naive grammar in your head to use these generators efficiently
<discocaml>
<contificate> which takes a good amount of time and energy to acquire the skillset
<discocaml>
<._null._> I might be completely lost, but if you gave this grammar as is to menhir, it would only complain about shift/reduce and reduce/reduce conflicts right ? And if you somehow explain how to resolve all of these conflicts, you'd get your desired parser ?
<discocaml>
<contificate> yes, but it's not just finding a set of directives that would just work
<discocaml>
<contificate> you'd need to factor it
<discocaml>
<contificate> so you'd transform the grammar in a way that requires a lot of care
<discocaml>
<._null._> Why do you need to change the grammar?
<discocaml>
<contificate> because `expr -> expr expr` is a nonsense
<discocaml>
<._null._> Only if you don't explain the conflicts it creates
<discocaml>
<contificate> you'd get hundreds of errors
<discocaml>
<._null._> resolve*
<discocaml>
<._null._> Already by making it so that this rule is always reduced, you'd solve many conflicts
<discocaml>
<contificate> fixing a grammar is much harder than building it up incrementally and documenting the problems you've skirted over, as people do
<discocaml>
<contificate> like fixing this grammar would be akin to basically boiling it down and building it from scratch
<discocaml>
<._null._> What I want is the tool that tells me how it's broken
<discocaml>
<contificate> with AI, the future may be bright, we could throw deep learning at our vibecoded garbage
<discocaml>
<contificate> tell our customers in the automotive industry that we're sure of its correctness because it routinely passes the "factorial function" test on the nightly test suite
Frostillicus_1 has quit [Ping timeout: 248 seconds]
<discocaml>
<tornato> Just vibe code Why3
<discocaml>
<contificate> sorry, I only do things that increase shareholder value
<discocaml>
<cod1r> hmmmm
<discocaml>
<cod1r> HRMMMM
bartholin has quit [Remote host closed the connection]
algm has quit [Remote host closed the connection]
myrkraverk has joined #ocaml
Frostillicus_1 has joined #ocaml
ygrek has quit [Remote host closed the connection]
Humean has joined #ocaml
wingsorc has quit [Remote host closed the connection]
Frostillicus_1 has quit [Ping timeout: 245 seconds]
Frostillicus_1 has joined #ocaml
Frostillicus_1 has quit [Ping timeout: 252 seconds]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 245 seconds]
spynxic has quit [Read error: Connection reset by peer]
spynxic has joined #ocaml
spynx has joined #ocaml
spynx has quit [Client Quit]
spynx has joined #ocaml
spynxic has quit [Ping timeout: 245 seconds]
spynx has quit [Remote host closed the connection]
spynxic has joined #ocaml
_whitelogger has joined #ocaml
_whitelogger has joined #ocaml
Frostillicus_1 has joined #ocaml
Humean has quit [Ping timeout: 248 seconds]
semarie has quit [Quit: quit]
_whitelogger has joined #ocaml
semarie has joined #ocaml
Frostillicus_1 has quit [Remote host closed the connection]
bartholin has joined #ocaml
Boarders_____ has quit [Quit: Connection closed for inactivity]
wbooze has quit [Quit: Leaving]
wbooze has joined #ocaml
chiselfuse has quit [Remote host closed the connection]
chiselfuse has joined #ocaml
infinity0 has quit [Ping timeout: 276 seconds]
infinity0 has joined #ocaml
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 252 seconds]
chiselfuse has quit [Ping timeout: 264 seconds]
chiselfuse has joined #ocaml
chrisz has quit [Ping timeout: 252 seconds]
chrisz has joined #ocaml
ygrek has joined #ocaml
kit_ty_kate has quit [Quit: WeeChat 4.4.2]
Humean has joined #ocaml
spynxic has quit [Read error: Connection reset by peer]
spynxic has joined #ocaml
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 276 seconds]
pi3ce has quit [Read error: Connection reset by peer]
pi3ce has joined #ocaml
troydm has quit [Ping timeout: 276 seconds]
pi3ce has quit [Ping timeout: 244 seconds]
pi3ce has joined #ocaml
gwizon has joined #ocaml
gwizon has quit [Quit: leaving]
gwizon has joined #ocaml
pi3ce has quit [Ping timeout: 244 seconds]
pi3ce has joined #ocaml
Frostillicus has joined #ocaml
gwizon has quit [Quit: leaving]
gwizon has joined #ocaml
Frostillicus has quit [Ping timeout: 248 seconds]
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 248 seconds]
kit_ty_kate has joined #ocaml
<dh`>
contificate: I object. Mainstream compilers that use hand-written parsers are parsing languages whose grammars are published standards with known characteristics. Writing a parser for a language you're inventing is a completely different proposition
<dh`>
further, I can't agree with your claims
myrkraverk_ has joined #ocaml
<dh`>
hand-written parsers are substantially more tedious to write, much harder to maintain successfully, have whole classes of bugs that generated parsers don't, and can generally only be updated by experts
myrkraverk has quit [Ping timeout: 260 seconds]
<dh`>
also, while it's true that the vast majority of published grammars need to be fixed before they can be used
<dh`>
that's because they're flat-out wrong, not because they're correct but not LR(1)
<dh`>
most are completely ambiguous
Frostillicus has joined #ocaml
<dh`>
expr ::= expr expr being an example of that, at least for typical other contents of expr
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 248 seconds]
kit_ty_kate_ has joined #ocaml
<dh`>
(for very simple contents of expr, it's not ambiguous but it's still wrong because we expect application to be left-associative)
Frostillicus has quit [Read error: Connection reset by peer]
Frostillicus has joined #ocaml
<discocaml>
<youngkhalid> ocaml solving real world tedious problems again
Frostillicus has quit [Read error: Connection reset by peer]
Frostillicus has joined #ocaml
<discocaml>
<contificate> hand-written parsers are pretty simple
<discocaml>
<contificate> their structure is often obvious and they defer to Pratt parsing for the trickier bits
<discocaml>
<contificate> the major opinion in compiler circles is to avoid LR parsing for many reasons
<discocaml>
<contificate> I still have use cases for LR parsing, but it's not my default for parsing programming languages
<discocaml>
<contificate> the grammar I linked is "flat-out wrong" but useful enough for its audience, which is SML programmers
<discocaml>
<contificate> you find people design grammars that way as well
<discocaml>
<contificate> they overfit the grammar and then try to nail it down with precedence declarations
<discocaml>
<contificate> > can generally only be updated by experts
<discocaml>
<contificate> is obviously total nonsense
<discocaml>
<tornato> Experts lol
<discocaml>
<contificate> a well structured recursive descent parser is quite straightforward to adapt
<companion_cube>
yeah I agree, it doesn't square with empirical evidence from the rest of the world
<discocaml>
<contificate> retrofitting random slop into an LR parser is can go wrong instantly
<discocaml>
<contificate> retrofitting random slop into an LR parser can go wrong instantly
<discocaml>
<contificate> there's writing a program (writing a parser as in recursive descent or pratt parsing) then there's influencing an algorithm that constructs automata with crude prec + assoc directives
Serpent7776 has joined #ocaml
<discocaml>
<contificate> anyway, it's not a very interesting topic and I regret fuelling its discussion here - parse however you'd like, but I have to teach parsing all the time and have settled on Pratt parsing as a more useful life skill
<discocaml>
<diligentclerk> Is there terminology to distinguish languages with very flexible scoping rules from languages that have simple and consistent scoping rules?
<discocaml>
<diligentclerk> Like, OCaml and Haskell (and maybe Scheme Lisp? I'm not familiar) have very clearly defined rules about scoping that permit static analysis, whereas R permits variables to be dynamically unbound from their environment
<companion_cube>
there's "well scoped" (OCaml), "badly scoped" (most of the rest), and "crazy pill" (python)
<discocaml>
<diligentclerk> I accidentally said "R is not a functional language" the other day but this is clearly wrong, everybody agrees R is not a functional language. What I meant is that R has scoping rules that are very different from the simple scoping rules of like, the lambda calculus.
<discocaml>
<diligentclerk> *everybody agrees R *is* a functional language
<discocaml>
<diligentclerk> I read the paper "R Melts Brains" and was amused and somewhat horrified.
<discocaml>
<youngkhalid> R is for a very specific use case in reality
<discocaml>
<diligentclerk> A closely related question: I think I have been mentally conflating "statically typed" with "able to be statically analyzed" when assessing languages, but I guess there are probably well-designed dynamically typed languages where a lot of the program structure is still statically determinable. Are there any dynamically typed languages which still have enough statically analyzable structure that one gets good tooling? For example, "go to
<discocaml>
<froyo> I think R is just straight up dynamically scoped?
<discocaml>
<diligentclerk> The NIH invested $48 billion dollars in biomedical research last year, so it's not exactly a narrow use case.
<discocaml>
<youngkhalid> That's just what I was saying, used in the biomedical field, so that's what I refer to when talking about "use case" (maybe not the right wording but you get it)
<discocaml>
<youngkhalid> I mean is a language that's not used very used for "general purpose" stuff for example say... Python or c++ (doesn't make it a worse language)
<discocaml>
<diligentclerk> It seems like most sources call it "lexically scoped", same as Python (because variable scopes are bound to the function or module they're in) but it's probably better to read the R Melts Brains paper to get an idea of the scoping rules, rather than trying to give a simple binary categorization, because they are very crazy and pretty dynamic
<discocaml>
<youngkhalid> Matter fact in terms of opportunities, if you're good at it you may even earn good $ for this type of stuff
<discocaml>
<youngkhalid> As the market isn't very saturated as for other technologies/languages
<discocaml>
<diligentclerk> R has lazy evaluation of function arguments which is really wild in a language which freely permits imperative assignment anywhere. Imperative + lazy argument evaluation seems like a dangerous combination.
<discocaml>
<tornato> anyone here familiar with why3 and getting the GUI to work
<discocaml>
<diligentclerk> I'm looking for work, so pass it along if you see anything. I have 2 years experience in writing Python and R for bioinformatics.
<discocaml>
<froyo> diligentClerk: I'll take your word for it since my interaction with R was very *very* brief
<discocaml>
<youngkhalid> debugging that may, indeed, be a hell
<discocaml>
<youngkhalid> for sure ! are you located in EU / US ...?
<discocaml>
<diligentclerk> I live on the East Coast in the United States.
<discocaml>
<froyo> but the reason I made that assumption is because I vaguely recall that variable lookup is done dynamically and the only construct that creates a new scope is function defs
<discocaml>
<youngkhalid> Ok well I'm from Europe, but If I see anything (remote or us) I'll let you know
<discocaml>
<diligentclerk> Variable lookup is done dynamically, you're right.
<discocaml>
<diligentclerk> The language is reflective and allows functions to inspect the call stack and access the environment of variable bindings and modify them. So something like `add <- function(x,y) x + y` is not so simple to compile, as the implementation of `+` could in theory access the call stack and unbind the variables `x,y` in the parent environment
<discocaml>
<froyo> but yeah I'll just go with ccube's description: "badly scoped"/"crazy pill" lol
<discocaml>
<diligentclerk> "... it is impossible to statically resolve the binding structure of R programs"
<discocaml>
<diligentclerk> so in that sense "dynamically scoped" seems fair.
<discocaml>
<diligentclerk> but that's also not really how people seem to use that terminology. I don't know.
<discocaml>
<diligentclerk> One of the craziest things in the paper is that when you combine
<discocaml>
<diligentclerk> - arguments are lazy
<discocaml>
<diligentclerk> - the language is reflective and so functions can access the environment they're executing in
<discocaml>
<diligentclerk> you get that in a function call `f(e)` for `e` an expression, since `e` is lazily evaluated, it is executing inside `f` and so can access and modify `f`'s environment and bound variables
<discocaml>
<froyo> "hmm I really like spooky action and would love to make it a first class feature of the language I'm designing"
<discocaml>
<diligentclerk> last sentence of the abstract: "we feel that this new language provides advantages... in scoping" LOL
<discocaml>
<youngkhalid> Not being a hater, but designers were **NOT software engineers** but **statisticians** which may explain all of your design questions
<discocaml>
<youngkhalid> Reminds me of an almost production-unusable language... 😅
<discocaml>
<youngkhalid> You guessed it ! HASKELL !
<discocaml>
<diligentclerk> I thought haskell was designed by academics interested in statically typed functional programming languages.
<discocaml>
<youngkhalid> still more focused on theorical stuff over engineering usability and pragmatism
kit_ty_kate_ has quit [Remote host closed the connection]
kit_ty_kate_ has joined #ocaml
<discocaml>
<froyo> ehh I've seen my fair share of production haskell
Frostillicus has quit [Remote host closed the connection]
Frostillicus has joined #ocaml
<discocaml>
<youngkhalid> it is actually possible to do some stuff, even for networking stuff as I said the other day, but it's a hell
<discocaml>
<froyo> idk about hell
<discocaml>
<froyo> I'd definitely rate it above production java, production c#, production js...
<discocaml>
<froyo> with type rep and template haskell you can do a lot of the fun INDUSTRY™️ workflows
<discocaml>
<youngkhalid> I mean if we talk about readability on large codebases and seeing where you may have side effects I'm sure Haskell can win, but the thing is to get it to work and maintaining it over time without being a pain in the ass
<discocaml>
<froyo> oh yeah the ecosystem moves too fast for sure
<discocaml>
<youngkhalid> The thing that sucks about that language is not the functional part , it's the purity part of it
<discocaml>
<youngkhalid> Like people just want to get sh!t done you know 😂
<discocaml>
<froyo> ime purity was never a hurdle
myrkraverk_ has joined #ocaml
<discocaml>
<youngkhalid> which type of programs did you use to write / work with ?
<discocaml>
<youngkhalid> which type of programs did you use to write / work on ?
<discocaml>
<froyo> i was employed to be a blockchain scammer
<discocaml>
<froyo> jk jk worked on blockchain infra
<discocaml>
<froyo> purity helps if anything, no* hidden effects :)
<discocaml>
<froyo> \* actually there are but they feel dirty so they often need to be reeeally justified
<discocaml>
<froyo> and for effect management, most have adopted effectful/freer style
myrkraverk has quit [Ping timeout: 248 seconds]
<discocaml>
<froyo> it really is much less of a problem than not focusing too much on backwards compat or having subpar debugging experience
<discocaml>
<froyo> a lot of the churn was in making sure builds work, like migrating haskell-nix backed monorepo setups to flakes etc
<discocaml>
<youngkhalid> Do you really need to integrate IO stuff on a daily basis ? That's the real question to see if it will be a sh!tty experience I think
<discocaml>
<youngkhalid> ahahah it's a double-edged sword
<discocaml>
<froyo> > integrate IO stuff on a daily basis
<discocaml>
<froyo> wdym?
<discocaml>
<froyo> I didn't write code that made the cpu hot and produce nothing if that's what you're asking :)
Frostillicus has quit [Ping timeout: 244 seconds]
<discocaml>
<youngkhalid> side effectful stuff
<discocaml>
<froyo> yeah so since blockchain infra is all about reading/writing to databases/network/logs/files/... i did plenty of that
<discocaml>
<youngkhalid> My condolences xD
<discocaml>
<youngkhalid> And you say it wasn't a pain in the as s ?
<discocaml>
<youngkhalid> damn buddy
<discocaml>
<froyo> the language lacks no capability of doing any of this. it just tracks what it did in the type system. that's all there is to purity. and since you're naturally inclined to not use more "capabilities" than you need, you naturally gravitate to create some layering/separation which is good design anyway even in impure languages like here
<discocaml>
<youngkhalid> I see I see
<discocaml>
<youngkhalid> It has its advantages as well when used correctly I think (and when things **work** of course)
<discocaml>
<youngkhalid> I really enjoyed reading haskell code though
<discocaml>
<youngkhalid> it was what made me like functional programming
<discocaml>
<youngkhalid> the expresiveness
<discocaml>
<youngkhalid> But you just feel like you can't use it for anything you want as you'd do in OCaml for this specific reason. I'm all for immutability, readable and easy to debug code, not full of side effects..etc, but I think it's not properly engineered
<discocaml>
<youngkhalid> But I just feel like you can't use it for anything you want as you'd do in OCaml for this specific reason. I'm all for immutability, readable and easy to debug code, not full of side effects..etc, but I think it's not properly engineered
<discocaml>
<youngkhalid> Very good for taking a learning tho
<discocaml>
<youngkhalid> Very good for learning tho
<discocaml>
<youngkhalid> Very good for learning tho
<discocaml>
<youngkhalid> But I just feel like you can't use it for anything you want as you'd do in OCaml for this specific reason. I'm all for immutability as a good practice, readable and easy to debug code, not full of side effects..etc, but I think it's not properly engineered
<discocaml>
<froyo> > And you say it wasn't a pain
<discocaml>
<froyo> honestly I'd describe it as fun. I didn't feel any* drudgery. I felt that from hobbyist code in other languages. we're blessed with good languages in our little corner of the pl space I'd say. OCaml, SML, Haskell... that said, I'd like to never touch that industry again if possible. the demoralization did not come from the tech I was using for sure.
<discocaml>
<froyo> \* my most memorable exception was when debugging one of those "hidden effects with a pinky promise" pieces of code. unsafe io primitives are REALLY unsafe when the compiler assumes everything is pure. compounded with weird nix shenanigans that made me go on a bit of a wild versioning goose chase. happens to the best of us.
<discocaml>
<youngkhalid> By industry, you mean the financial industry I guess ?
<discocaml>
<froyo> > I really enjoyed reading haskell code though
<discocaml>
<froyo> imo OCaml is a lot more readable. for me reading haskell code was only nice when i had a local hoogle running and a lsp server. otherwise lots of implicit stuff going on and a tendency to lean heavily into operators/combinators. some code is just impenetrable until you learn the paradigm (ahem- lenses).
<discocaml>
<froyo> luckily code review policy at $dayjob really emphasised readability & discouraged this stuff
<discocaml>
<froyo> more specifically blockchain but yea
<discocaml>
<youngkhalid> Ahaah, I mean before discovering OCaml (reading Haskell as the only functional language I knew at the time, coming from imperative languages)
<discocaml>
<froyo> soon enough with implicits ocaml code reviews will use a lot more electricity! :D
<discocaml>
<youngkhalid> I think it has to be stressful and unhealthy. The job world as we all know is $ oriented, but in the financial world that's multiplied by x10000
<discocaml>
<youngkhalid> I think it has to be stressful and unhealthy. The enterprise world as we all know is $ oriented, but in the financial world that's multiplied by x10000
<discocaml>
<froyo> well that's all I'll say about that. I'll keep my personal gripes & ideals out of this
<discocaml>
<youngkhalid> xD
<discocaml>
<youngkhalid> at least you had the opportunity to work with a language like that in production, which is rare, I think that can definitely count as personal career growth
<discocaml>
<froyo> yep I appreciate that part of the experience
<discocaml>
<froyo> one thing i noticed was that enterprise haskellers are a lot like enterprise java devs in their tendency to create tall abstraction towers :)
<discocaml>
<froyo> can't wait to try my hand in enterprise ocaml
<discocaml>
<tornato> how does one prove the termination of fixpoint iteration?
<discocaml>
<tornato> im tempted to rewrite my datalog interpreter in why3
<dh`>
contificate: it's clear we're going to have to agree to disagree; let's just say I've written buckets of LR(1) grammars and buckets of recursive descent parsers in assorted languages, as well as had to repair things written in both styles by the semicompetent, and I know which I'd rather deal with
<dh`>
the reasons to write a recursive descent parser in production these days are: generating error messages, dealing with upstream grammars that aren't LR(1), not entering undefined states or leaking memory on error
<dh`>
maybe also in some cases maintainability of the _code_
<discocaml>
<yawaramin> anyone know any tricks to get good parse error messages from Angstrom?
<dh`>
the reasons to prefer an LR(1) parser: assurance, safety, maintainability of the _grammar_
<dh`>
plus the crosschecking on the consistency of the syntax
<dh`>
as I started this mess with, in no event should anyone be trying to use %prec or %lassoc and whatnot directives to repair a wrong grammar
<companion_cube>
> Daedalus is built around functional-style parser combinators,
<companion_cube>
ah
<companion_cube>
(will look, anyway)
<dh`>
it's only sort of, it's a language and not a combinatory library
<dh`>
s/combinatory/combinator/
<dh`>
the language is structured like using a combinator library
<dh`>
the big problem with combinator libraries is the elaborate and delicate backtracing that you end up having to do when dealing with grammars that have highly nondeterministic prefixes
<dh`>
er, backtracking
<dh`>
that is less of a thing with binary formats
<companion_cube>
Agreed
<companion_cube>
They're normally designed to be parsed in one go
<dh`>
and even when not, what you're looking at is usually clear and doesn't require a lot of analysis/inference/examination
<dh`>
instead you have data-dependent stuff that ordinary parser generators can't cope with
kit_ty_kate_ has left #ocaml [#ocaml]
<discocaml>
<cod1r> hi
Frostillicus has quit [Remote host closed the connection]
Frostillicus has joined #ocaml
<companion_cube>
Yes that was my point
Frostillicus has quit [Ping timeout: 245 seconds]
Frostillicus has joined #ocaml
kit_ty_kate_ has joined #ocaml
kit_ty_kate has left #ocaml [WeeChat 4.4.2]
kit_ty_kate_ is now known as kit_ty_kate
<discocaml>
<yawaramin> so does anyone have a working example of good parse error messages with Angstrom?
myrkraverk has joined #ocaml
<discocaml>
<yawaramin> ah, `<?>` (label) looks interesting, i'll try it
myrkraverk_ has quit [Ping timeout: 272 seconds]
Serpent7776 has quit [Ping timeout: 252 seconds]
<dh`>
>> can generally only be updated by experts
<dh`>
> is obviously total nonsense
<discocaml>
<yawaramin> ok this is fairly reasonable: `Error "expected a person > expected a word: count_while1"`
<dh`>
if you get to argue about LR-generated parsers written and maintained by people who ahve no idea what they're doing, I can argue about handwritten parsers written and maintained by people who have no idea what they're doing
<discocaml>
<yawaramin> although wish there was a way to report the substring which failed
<dh`>
and those definitely cannot be maintained by anyone other than experts _in that parser_
euphores has quit [Quit: Leaving.]
euphores has joined #ocaml
<discocaml>
<yawaramin> ok this is looking fairly reasonable: `Error "expected a person eg [1 Bob] > expected one or more spaces eg 1[ ]Bob: not enough input"`
<discocaml>
<yawaramin> even though we can't report the actual failing input, we can give examples of what's missing through the labels
<discocaml>
<yawaramin> for `parse_string ~consume:Consume.All person "1"`
Frostillicus has quit [Ping timeout: 276 seconds]
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
bartholin has quit [Remote host closed the connection]
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
YuGiOhJCJ has joined #ocaml
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
algm has joined #ocaml
kit_ty_kate has quit [Remote host closed the connection]
kit_ty_kate has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
algm has quit [Quit: algm]
Frostillicus has joined #ocaml
<discocaml>
<contificate> > as I started this mess with, in no event should anyone be trying to use %prec or %lassoc and whatnot directives to repair a wrong grammar
<discocaml>
<contificate> tihs is just delusional, I'm afraid, dh
<discocaml>
<contificate> this is just delusional, I'm afraid, dh
<discocaml>
<contificate> but I'll agree to disagree, but I doubt your claims of having used LR parser generators if you think this and refer to %left as %lassoc etc.
<discocaml>
<contificate> do you think OCaml's 42 uses of %prec are just because its grammar maintainers don't know what they're doing?
<discocaml>
<contificate> these tools require these escape hatches to be practical
<companion_cube>
idk how to use these still :/. Too much magic. I've always done the priorities by hand.
Frostillicus has quit [Ping timeout: 245 seconds]
<discocaml>
<yawaramin> speaking of, Sherlocode finds at least 3,000 uses of `Obj.magic`. lol
kit_ty_kate has left #ocaml [#ocaml]
<discocaml>
<contificate> there's not much that can be said if someone believes directives shouldn't be used
<discocaml>
<contificate> they're a practical necessity - and almost every grammar fed to an LR parser generator in the wild will use them
<discocaml>
<contificate> dh, you have ideals that don't align with reality
<discocaml>
<contificate> like it's worse to take your advice about using LR parser generators than any other option mentioned here