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
<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>
<peuk> I'd tend to agree. Apparently in Frama-C, for the C (+ghost) part we have 4 prec (2 only for the ghost else), 3 nonassoc (all for ghost else), 1 left and 1 right. And the actual thing that makes the grammar complex is basically that we need to support GCC attributes that pollutes everything everywhere in the syntax and the AST.
chrisz has quit [Ping timeout: 252 seconds]
chrisz has joined #ocaml
chrisz has quit [Ping timeout: 265 seconds]
halloy4450 has quit [Ping timeout: 244 seconds]
chrisz has joined #ocaml
chrisz has quit [Ping timeout: 252 seconds]
chrisz has joined #ocaml
Haudegen has joined #ocaml
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
troydm has joined #ocaml
chrisz has quit [Ping timeout: 252 seconds]
chrisz has joined #ocaml
chrisz has quit [Ping timeout: 248 seconds]
chrisz has joined #ocaml
Anarchos has joined #ocaml
wingsorc has quit [Ping timeout: 244 seconds]
chrisz has quit [Ping timeout: 276 seconds]
chrisz has joined #ocaml
euphores has quit [Ping timeout: 244 seconds]
euphores has joined #ocaml
mange has quit [Quit: Zzz...]
Haudegen has quit [Quit: Bin weg.]
Serpent7776 has quit [Quit: leaving]
<discocaml>
<contificate> My final comment on this boring topic is that one need only glance over https://grep.app/search?q=%25left if they really believe avoiding directives will set them up for maintaining grammars in the real world. Even if I agreed with "never use any directives", it wouldn't help you out with using Menhir (or any other LR parser generator) in the real world. It'd be great to never use directives but, alas, we are not immortal and can only shav
Anarchos has quit [Quit: Vision[]: i've been blurred!]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 244 seconds]
euphores has quit [Quit: Leaving.]
euphores has joined #ocaml
Haudegen has joined #ocaml
gwizon has joined #ocaml
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
halloy4450 has joined #ocaml
tremon has joined #ocaml
halloy4450 has quit [Ping timeout: 265 seconds]
ygrek has joined #ocaml
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 265 seconds]
Haudegen has quit [Quit: Bin weg.]
Humean has joined #ocaml
Anarchos has joined #ocaml
Humean has quit [Quit: Leaving]
<discocaml>
<yawaramin> Dear Diary, Papa and Papa are fighting about parsers and things are very awkward.
halloy4450 has joined #ocaml
<discocaml>
<contificate> Much ado about the least interesting part of compiler-related projects 😏
Anarchos has quit [Ping timeout: 276 seconds]
halloy4450 has quit [Quit: halloy4450]
Anarchos has joined #ocaml
Anarchos has quit [Ping timeout: 272 seconds]
ygrek has quit [Remote host closed the connection]
chiselfuse has quit [Remote host closed the connection]
Haudegen has joined #ocaml
<discocaml>
<dubious245> Whats the most interesting part?
<discocaml>
<contificate> Subjective, I guess parsing is the most interesting part for some people or, at least, could be arbitrarily involved/interesting. I dismiss parsing in jest, I actually really enjoy parsing literature and algorithms: but there's no question it's tedious no matter how you cut it.
<discocaml>
<contificate> I really like anything involving mid-level transformation or matching automata
euphores has quit [Quit: Leaving.]
euphores has joined #ocaml
<discocaml>
<yawaramin> we need y'all geniuses to improve parser combinator performance and error reporting lol
wbooze_ has joined #ocaml
wbooze has quit [Ping timeout: 248 seconds]
Anarchos has joined #ocaml
Frostillicus has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
ru0mad has joined #ocaml
ru0mad has left #ocaml [#ocaml]
chiselfuse has joined #ocaml
Frostillicus has quit [Ping timeout: 244 seconds]
wbooze_ has quit [Read error: Connection reset by peer]
Frostillicus has joined #ocaml
wbooze has joined #ocaml
Tuplanolla has joined #ocaml
<dh`>
I'd say the most interesting part of a DSL project is sorting out the language semantics you want
<dh`>
for compiling a language that's already been defined, probably the most interesting part is sorting out the internal representations you're going to use and the transforms you're going to do on them
<dh`>
these statements reflect known structural biases on my part :-)
<dh`>
it's not that parsing isn't interesting, it's more that it's very well understood and not very difficult
<dh`>
and there's a tendency among first-timers to think it's of more importance than it is
<dh`>
because, I think, it's the front-facing part of the problem
<dh`>
and also I think because it looks difficult to people who've never done it before
Frostillicus has quit [Ping timeout: 252 seconds]
<dh`>
anyway, for a dsl project my recommendation would be to first sort out the abstract syntax and semantics you want; then figure out a concrete syntax that maps nicely to the abstract syntax
<dh`>
and only then actually write a parser, whether with menhir or by hand or whatever else
<dh`>
and I would strongly recommend using an LR parser generator as a tool for figuring out unambiguous concrete syntax, because it's the best available alternative
<dh`>
trying to figure it out by yourself on paper is not easier
<dh`>
and for the time being proof assistants are absolutely not up to the task
Frostillicus has joined #ocaml
<discocaml>
<contificate> > and there's a tendency among first-timers to think it's of more importance than it is
<discocaml>
<contificate> this speaks to a deeper problem in the pedagogy of compilers, I'd say
<discocaml>
<contificate> people end up gatekeeping themselves because of a form of bikeshedding of syntax, logos, github organisations, etc.
<discocaml>
<contificate> because they think their dream language will be their first and just create a gordian knot of complexity for themselves
<discocaml>
<contificate> at least, in OCaml, you can manage the complexity quite well - but other languages aren't very forgiving
<discocaml>
<contificate> I'm not an expert but, if I ever wrote a long-form resource about compilers, it'd be totally project orientated, with natural extension points (a few more modern books are structured this way) - many domains of programming are a kind of discipline where you better get a few toys under your belt
<discocaml>
<dubious245> I haven't looked at any books on compilers really because I assume they mostly covering parsing and I don't think that is particular hard or useful and I dont want to pay for or aquire a book and spend time reading and only like the back 20% is any sort of useful.
<discocaml>
<dubious245> -# On the flip side I don't struggle with parsing because my professor last year made me write so many of the stupid things.
<discocaml>
<contificate> most compiler books have redeeming chapters, but there's a lot that's only in papers
ridcully has quit [Quit: WeeChat 4.5.2]
ridcully has joined #ocaml
<discocaml>
<tornato> your mom has a redeeming chapter
<discocaml>
<contificate> thanks
<discocaml>
<tornato> no problem
<discocaml>
<tornato> im so sick of providing shareholder value
<discocaml>
<contificate> need to crash out into b2b saas selling vibecoded slopware any day now
<discocaml>
<tornato> someone got fired before over a bad demo apparently
<discocaml>
<contificate> when I was a child, I was a member of various forums dedicated to reverse engineering, game modification, etc. that kind of thing
<discocaml>
<contificate> and people used to list "written in x86_64" as a feature of their product
<discocaml>
<contificate> makes me wonder what the latest in buzzwording is
<discocaml>
<tornato> idk
<discocaml>
<contificate> I was gonna joke and say "written in OCaml", but that'd be pretty good
<discocaml>
<youngkhalid> written in OCaml is a flex
<discocaml>
<tornato> most people that write using functional languages don't advertise it as a feature of their project
<discocaml>
<youngkhalid> x86_64 > MIPS btw (dont @ me xD)
<discocaml>
<tornato> most people that write using functional languages don't advertise it as a feature of their product
<discocaml>
<contificate> nobody is debating you there
wbooze has quit [Ping timeout: 268 seconds]
<discocaml>
<tornato> other than Jane Street which wants the world to know how nerdy they are
<discocaml>
<contificate> Jane Street could fund development in any language to be honest
<discocaml>
<contificate> could switch to Forth for the banter alone
<discocaml>
<tornato> most companies FP is kind of a like, thing a few teams do that is looked down upon by the people providing shareholder value
<discocaml>
<tornato> when I left my old company they said they were going to rewrite all my purescript apps in "more maintainable" typescript
<discocaml>
<youngkhalid> Yaron Minsky was visionary
<discocaml>
<youngkhalid> without him there wouldn't be any ocaml there
<discocaml>
<contificate> what upsets me most about TypeScript is, ignoring the "when in Rome" influence in web development, I really don't believe it even begins to address the problems I have with vanilla JavaScript
<discocaml>
<tornato> vanilla javascript is basically lisp\tm
<discocaml>
<tornato> vanilla javascript is basically lisp ™️
<discocaml>
<tornato> SICP in javascript!!!
<discocaml>
<tornato> kms
wbooze has joined #ocaml
<discocaml>
<contificate> scheme didn't make sense to me until I after I'd learned OCaml
<discocaml>
<contificate> can't think of a more mentally destructive way to introduce recursion than to make it over cons cells with `car` and `cdr` accessors
<discocaml>
<contificate> no wonder students leave universities thinking it's an academic parlour trick for writing the factorial function
<discocaml>
<tornato> I had ChatGPT open and one of the tabs was "... size discussion" during the demo
<discocaml>
<tornato> woops
<discocaml>
<contificate> some companies are shoving AI down the throats of developers, with developer surveys and the like
<discocaml>
<tornato> honestly I'm fine vibe coding some form revisions
YuGiOhJCJ has joined #ocaml
wingsorc has joined #ocaml
bartholin has quit [Quit: Leaving]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<discocaml>
<dubious245> I should probably try using an LLM at some point (other than the one at the top of google search)
<discocaml>
<shawnfrostx> what are some abstractions out there for retryable effectful functions? there’s lwt_retry. anything else?
<discocaml>
<shawnfrostx> runtime doesn’t matter. i’m just looking for some well designed APIs
<dh`>
ACID transactions are the gold standard for retryable stateful computations