companion_cube changed the topic of #ocaml to: Discussion about the OCaml programming language | http://www.ocaml.org | OCaml 5.2.0 released: https://ocaml.org/releases/5.2.0 | Try OCaml in your browser: https://try.ocamlpro.com | Public channel logs at https://libera.irclog.whitequark.org/ocaml/
Frostillicus has joined #ocaml
Frostillicus has quit [Quit: Frostillicus]
halloy4450 has joined #ocaml
halloy4450 has quit [Ping timeout: 245 seconds]
halloy4450 has joined #ocaml
halloy4450 has quit [Remote host closed the connection]
<dh`> directives are not necessary, and they're only used in the wild because people don't understand what they're doing and/or the misguided idea that it matters that the fewer states and directives version is slightly faster/smaller
halloy4450 has joined #ocaml
<dh`> in the absence of further data I think 35-40 of ocaml's 42 uses of %prec are because someone thinks it's more efficient that way
<dh`> a few of them are probably because of things that are irritating to write out by hand
Haudegen has joined #ocaml
<dh`> and, you're welcome to 'doubt my claims of having used LR parser generators'
<dh`> but, you're completely wrong, not only have I been using them for decades, I've written one
<dh`> which isn't the one I posted a link to earlier, fwiw, someone else did most of the guts of that one
zor has joined #ocaml
<dh`> and if I've forgotten what yacc calls the damn things, consider maybe that it's because I never use them
Haudegen has quit [Quit: Bin weg.]
<dh`> (what calls them "lassoc" and "rassoc", anyway? something must or those keywords wouldn't be in my head)
_jbrown_ has quit [Ping timeout: 260 seconds]
mange has joined #ocaml
wingsorc has joined #ocaml
<discocaml> <diligentclerk> learned the phrase "fully functorized style" reading a PL book years ago and didn't know what it meant because I didn't know OCaml. Years later I understood what it was talking about: writing all your code so that it's all completely generic over all its data structures and dependencies. That seems like the closest analogue to "enterprise OCaml"
<dh`> and, btw, if we want those 42 uses of %prec to be gone, it can be so, unless they're hiding an ambiguity that would create a breaking change
<discocaml> <contificate> I am suspect of this claim
<discocaml> <contificate> you would need to radically restructure the grammar
<discocaml> <contificate> it doesn't matter if you think there's a mechanical process by which to do that, it may result in a huge blowup in states
<discocaml> <contificate> and be even less maintainable
<discocaml> <contificate> you seem to think the directives are for decoration purposes or something
<discocaml> <contificate> they're used to address conflicts in the parser - how do you propose we get rid of all of the directives used in `parser.mly`, it would require radical restructuring
<dh`> it's not mechanical, it's about understanding what someone was trying to do and then modifying the grammar so it says that
<dh`> and it doesn't cause a huge blowup in states, it's a few more incrementally
<discocaml> <contificate> I would love to see this
<discocaml> <contificate> clearly you know something that the creator of Menhir doesn't
<discocaml> <contificate> who also happens to be the primary maintainer of OCaml's parser.mly
<dh`> quite possibly, I have after all been working in this subfield for a long time
<dh`> without looking to see what the 42 uses are about, it's difficult to make specific claims
<discocaml> <contificate> so, on one hand, we agree that the directives are crude but you think they're not necessary and that there's no practical problems associated with trying to avoid their usage?
<dh`> but I assume you've seen e.g. a C grammar with all the operator precedence written out correctly?
<discocaml> <contificate> that's an academic exericse and it's also got a shift/reduce conflict
<discocaml> <contificate> factoring arithmetic expressions to parse ANSI C with a dangling else that happens to be resolved by the LR parser generator is not quite how people write parsers
<discocaml> <contificate> that's an academic exercise and it's also got a shift/reduce conflict
<dh`> if/else isn't in the expression grammar
<dh`> but yes, that can be fixed too
<discocaml> <contificate> I never said it is
<discocaml> <contificate> I know what grammar you're referring to
<discocaml> <contificate> it's decades old
<discocaml> <contificate> it happens to have no nullable states as well
<discocaml> <contificate> which I know because I wrote the efficient lalr item set construction algorithm for it, and discovered my efforts were wasted
<dh`> I have no idea what _you're_ referring to
<discocaml> <contificate> this makes no use of directives
<dh`> but on the specific point of the if-else ambiguity, you might find this informative: http://www.parsifalsoft.com/ifelse.html
halloy4450 has quit [Ping timeout: 276 seconds]
<discocaml> <contificate> it happens to be the case that it's resolved implicitly in the above grammar
<discocaml> <contificate> that page is not informative at all and I feel condescended
<dh`> it is incorrect in that grammar, relying on yacc's default resolutions is no better than writing directives
<dh`> and that page tells you how to do the transform you're talking about, so claiming it's not informative is a little odd
gwizon has quit [Quit: leaving]
<discocaml> <contificate> in my experience, there's quite a few parsers fed to LR generator tools that rely on implicit resolution
<dh`> yes
<discocaml> <contificate> the first versions of OCaml do
<dh`> you see things like "expect 55 shift/reduce conflicts"
<dh`> and that's even worse baloney
<dh`> in theory you can audit all 55 of those to make sure they're doing what you want, but given that yacc can't be arsed to tell you what the conflicts are and few parser generators are better about it
<discocaml> <contificate> bison can tell you
<dh`> chances are if you have 55 shift/reduce conflicts something like 2/3 of them will be bugs
<discocaml> <contificate> but people don't because it's a lot of work
<dh`> it's not a lot of work compared to writing and debugging the handwritten version
<dh`> most handwritten parsers will go into infinite loops in corner cases, assuming they don't just dump core
<discocaml> <contificate> I'd propose that rewriting OCaml's parser.mly to not use directives would result in an unmaintainable mess
<dh`> I might agree because of the property of let-bindings I mentioned above
<dh`> but that's like one or two uses of directives, not 42
<discocaml> <contificate> what
<discocaml> <contificate> it's 42 uses of %prec to override the rule priority and basically every token is ascribed %left, %right, or %nonassoc
<dh`> I am clearly going to have to look at this thing in detail
<dh`> which I don't have time for before this weekend at the earliest
<discocaml> <contificate> either way, this discussion started out as using menhir vs handwritten vs ..
<discocaml> <contificate> and lemme tell you
<discocaml> <contificate> nobody is doing what you are suggesting
<discocaml> <contificate> "never use directives" - this is tantamount to saying "waste your own time, make the grammar unmaintainable, and have a horrible time while you do it"
<discocaml> <contificate> not using them is effectively misusing the tool above a certain threshold of grammar size
<dh`> you are just wrong, I'm sorry
<discocaml> <contificate> no, you are wrong
<discocaml> <contificate> clearly inexperienced with production LR grammars
<discocaml> <contificate> you haven't even looked at OCaml's
<dh`> why would I have looked at ocaml's? there are thousands of these things in the wild and I'm not particularly an ocaml contributor
<discocaml> <contificate> I'm citing it as an example of a large, fairly complicated, grammar
<discocaml> <youngkhalid> Does anyone know if there’s similar thing as C Posix threads, semaphores and mutexes in OCaml?
<discocaml> <youngkhalid> Does anyone know if there’s a similar or same thing as C Posix threads, semaphores and mutexes in OCaml?
<dh`> and this is getting uncomfortably close to you're saying I'm lying, which is clearly inappropriate
<discocaml> <contificate> nobody familiar with practical LR parsing could possibly agree with what you are saying
<dh`> that is clearly not true, if only because I do
<dh`> but, since you're apparently willing to accuse me of lying about my experience
<discocaml> <contificate> these all exist in OCaml already
<dh`> we will now drop this
<discocaml> <youngkhalid> Any link woukd be helpful plz : )
<discocaml> <youngkhalid> Any link would be helpful plz : )
<discocaml> <youngkhalid> I saw some parallelism thing the other day but didn’t dig deeper
<discocaml> <contificate> `Thread`s are a thing in both OCaml 4 and OCaml 5, as are `Mutex`s
<discocaml> <contificate> and there's a `Semaphore` module as well, with a binary and counting variant (iirc)
<discocaml> <tornato> Chill tf out
<discocaml> <contificate> `Thread` is a pthread which competes for the runtime lock (domain lock in v5)
<discocaml> <youngkhalid> Ok found [this](https://ocaml.org/manual/5.3/libthreads.html)
<discocaml> <contificate> and `Mutex` is a pthread_mutex_t underneath on *nix
<discocaml> <youngkhalid> Thx for the info 👍
<discocaml> <yawaramin> in OCaml 5, you might want to check out https://ocaml-multicore.github.io/eio/eio/Eio/index.html
ygrek has quit [Remote host closed the connection]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 252 seconds]