<dh`>
but also, the parser is like the first 5% of any nontrivial dsl implementation and it's not the thing you should spend a long time thinking about
Tuplanolla has quit [Quit: Leaving.]
ygrek has joined #ocaml
algm has joined #ocaml
algm has quit [Remote host closed the connection]
<discocaml>
<contificate> prec is necessary evil I'm afraid
algm has joined #ocaml
algm has quit [Remote host closed the connection]
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 252 seconds]
ygrek has quit [Remote host closed the connection]
discocaml has quit [Read error: Connection reset by peer]
discocaml has joined #ocaml
casastorta has joined #ocaml
cr1901_ has joined #ocaml
cr1901 has quit [Ping timeout: 252 seconds]
afrosenpai has quit [Ping timeout: 248 seconds]
afrosenpai has joined #ocaml
Serpent7776 has joined #ocaml
Haudegen has joined #ocaml
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 265 seconds]
bartholin has joined #ocaml
bartholin has quit [Quit: Leaving]
itszor has joined #ocaml
_jbrown_ has quit [Ping timeout: 252 seconds]
Anarchos has joined #ocaml
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 252 seconds]
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 272 seconds]
semarie has quit [Quit: quit]
semarie has joined #ocaml
Frostillicus has joined #ocaml
<Frostillicus>
New to the language and I have a question about pattern match syntax. Examples above and below section 4.1 in the docs here https://ocaml.org/manual/5.3/coreexamples.html. Sometimes the pattern will have a | on all of the and other times this will be elided. What are the rules for when these can be omitted
<Frostillicus>
*all of the clauses
<dmoerner>
it can be omitted on the first one. you can think of it kind of like an infix "or"
<Frostillicus>
Thank you
Haudegen has quit [Quit: Bin weg.]
ygrek has joined #ocaml
Frostillicus has quit [Ping timeout: 245 seconds]
Frostillicus has joined #ocaml
Frostillicus has quit [Ping timeout: 252 seconds]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 276 seconds]
hsw_ has quit [Quit: Leaving]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
hsw has joined #ocaml
Haudegen has joined #ocaml
Frostillicus has joined #ocaml
trillion_exabyte has quit [Ping timeout: 244 seconds]
trillion_exabyte has joined #ocaml
<discocaml>
<yawaramin> kind of like a trailing comma but in the other direction
<dh`>
%prec is never needed :-)
<dh`>
writing out precedence in longhand can be annoying but it's not really a big deal, and then you know it's the way you actually want it
<dh`>
whereas the problem with all these directives is that they operate at the state machine level rather than the grammar level, so you have to understand the state machine to use them safely
<dh`>
and the whole point of an LR parser generator is that the state machine is someone else's problem
<discocaml>
<._null._> Are you advocating for non-ambiguous grammars ?
wbooze has quit [Remote host closed the connection]
wbooze has joined #ocaml
wbooze has quit [Write error: Connection reset by peer]
Serpent7776 has quit [Ping timeout: 245 seconds]
Haudegen has quit [Quit: Bin weg.]
Frostillicus has quit [Ping timeout: 245 seconds]
<dh`>
yes, yes I am
wbooze has joined #ocaml
Frostillicus has joined #ocaml
<discocaml>
<contificate> well, people don't write such grammars - we agree on the problems of the directives but that's inherited from yacc, I'd expect everyome using Menhir to be using them
<discocaml>
<contificate> > writing out precedence in longhand can be annoying but it's not really a big deal,
<discocaml>
<contificate> most people can't parse arithmetic with the factored grammar using these tools
<discocaml>
<contificate> so, yes, it is a big deal - you don't have an OCaml parser if you don't have directives, nobody is gonna deal with that
<discocaml>
<contificate> the current `parser.mly` file for OCaml is more than 4000 lines, fully reliant on the directives, even with ghost tokens for use with `%prec` (e.g. `%prec below_WITH`)
<discocaml>
<._null._> What's the issue with disambiguating grammars through precedence and associativity indications? I know there's the case of tokenless application, but apart from that ?
wingsorc has joined #ocaml
<discocaml>
<contificate> reasoning about it is reasoning about the state machine
<discocaml>
<contificate> the key insight is that a rule's precedence is inferred from the last terminal in the rule
<discocaml>
<contificate> which is all fun and games for an arithmetic grammar that looks like `expr STAR expr`
<discocaml>
<contificate> so resolving the nice class of conflict, shift/reduce conflicts, is still reasoning at the level of the state machine, with extremely crude directives
<discocaml>
<contificate> most people can't factor a grammar to be non-ambiguous
<discocaml>
<contificate> like it's an academic exercise to do this for arithmetic and it's a slog, until you know the trick
Frostillicus has quit [Ping timeout: 245 seconds]
<discocaml>
<contificate> I'd sooner write the parser as handwritten before playing grammar tetris
<discocaml>
<._null._> Have I never dealt with a difficult grammar if menhir's --explain has always been sufficient for me?
<discocaml>
<contificate> yes, at the risk of insult, I'd say so
<discocaml>
<contificate> it takes quite a bit of fortitude to write a good grammar that works with these tools
<discocaml>
<contificate> even just parsing a subset of ML means you have to work around application via juxtaposition
<discocaml>
<._null._> It's definitely possible, but I'm curious what difficult grammars there are, because I've written quite a few
<discocaml>
<contificate> where literally everyone copies a trick worked out by someone else
<discocaml>
<._null._> Including ML subsets, but where applications were already dealt with
<discocaml>
<contificate> where you factor it into "simple_expr" and normal "expr" and simple_expr connects to normal expr by way of `simple_expr -> '(' expr ')'` etc.
<discocaml>
<contificate> ignoring the poll above
<discocaml>
<contificate> the unanimous advice you would get from a compilers community is anti-LR parsing for programming languages
<discocaml>
<contificate> most people aren't educated in LR parsing to form a serious opinion but they're competent people who have struggle to use the tools at one point or another
<discocaml>
<contificate> most people aren't educated in LR parsing to form a serious opinion but they're competent people who have struggled to use the tools at one point or another
<discocaml>
<._null._> So, what kinds of rules or rule conflicts are there that make LR annoying (again, except for tokenless application)
<discocaml>
<._null._> So, what kinds of rules or rule conflicts are there that make LR annoying (again, except for tokenless application) ?
<discocaml>
<contificate> people always run into something
<discocaml>
<contificate> any expression orientated thing with infix and prefix operators is sufficient to gatekeep people from the compilers world, lol
<discocaml>
<contificate> I'm not saying there aren't people skilled at grammar design and mechanical transformations
<discocaml>
<contificate> I just take issue with "writing out precedence in longhand can be annoying but it's not really a big deal"
<discocaml>
<contificate> because, even if you have the mechanical algortihm for factoring all this out and getting it closer to what you want, there's no doubt a bunch of administrative non-terminals will be introduced and the grammar will be larger and more complex
<discocaml>
<contificate> there's projects out there that just have shift/reduce and reduce/reduce conflicts because the reasoning is that the tool may happen to resolve it correctly without explicit disambiguation by way of directives
<discocaml>
<contificate> this is true for Caml Light's grammar, with the anti-generative-LR parsing take from the ZINC paper
<discocaml>
<._null._> I'm not advocating for transforming grammars, I'm trying to understand where precedence and associativity fall short
<discocaml>
<contificate> take anyone who voted for Menhir from the poll above and get them to parse a reasonable subset of OCaml without running into problems
<discocaml>
<contificate> they've ever done it before or will be having problems
<discocaml>
<contificate> asking people to do it live - a joy Discord gives us - is also useful
<discocaml>
<contificate> people love to love thnisg
<discocaml>
<contificate> people love to love things
<discocaml>
<contificate> but we've all watched Scheme experts struggle to write high school equations in S-expression form - live on video calls - after dying on hills about it
<discocaml>
<._null._> Guess I'll try. I imagine parsing expressions would be a sufficient subset
<discocaml>
<contificate> I was obsessed with LR parsing at a time, which may seem hard to believe
<discocaml>
<contificate> have written custom tools for educating people about LR parsing
<discocaml>
<cod1r> what did you use to build the GUI
<discocaml>
<cod1r> oh it's a web app
bartholin has joined #ocaml
Frostillicus has joined #ocaml
<discocaml>
<lecondorduplateau> I have voted menhir because I already have implemented (copied) a grammar and remember struggling while modify it a bit just to handle cases I want to implement
Frostillicus has quit [Remote host closed the connection]
<discocaml>
<lecondorduplateau> I haven't understood menhir today
Frostillicus has joined #ocaml
<discocaml>
<deepspacejohn> it may be interesting to have a similar poll in the Discourse forum with more options, just to see what the general state of parsing in OCaml is like right now.
<discocaml>
<youngkhalid> Maybe you're not interested in this, but I'll send it anyways.
<discocaml>
<youngkhalid> You can make GUI's in OCaml as well with [Bogue](https://github.com/sanette/bogue) (uses SDL2 under the hood)
<discocaml>
<youngkhalid> Maybe you're not interested in this, but I'll send it anyways in case anyone does.
<discocaml>
<youngkhalid> You can make GUI's in OCaml as well with [Bogue](https://github.com/sanette/bogue) (uses SDL2 under the hood)
<discocaml>
<yawaramin> styling GUIs is hard
<discocaml>
<youngkhalid> you say in general or with this specific lib ?
<discocaml>
<youngkhalid> didn't try it yet, but has to be harder than css / tailwind that's for sure
<discocaml>
<yawaramin> in general i think it needs professionals or a lot of dedicated time to polish UIs
<discocaml>
<dubious245> Almost 30% of respondents think you should write your own.
<discocaml>
<deepspacejohn> I'm not sure if the poll got enough data to really say anything. 7 people responded, so 30% was 2. That's partially why I think a poll on the forum might be interesting since it's exposed to a bigger audience.
Frostillicus_1 has joined #ocaml
Frostillicus has quit [Ping timeout: 276 seconds]
Frostillicus_1 has quit [Ping timeout: 252 seconds]
<discocaml>
<yawaramin> also it was restricted to only 2 options, people who prefer other options probably didn't vote at all. sampling bias
<discocaml>
<youngkhalid> I mean Frontend dev (+ Web designer in some cases) is a whole job 😅
<discocaml>
<youngkhalid> People underestimate how hard is to make good UI's (actually most SWE's don't know how to make a good one, it's a lot of strategies / pseudo-"rules" (choice of colors, accesibility...etc) that have to be learnt)
<discocaml>
<youngkhalid> And it's not a bad thing to not know, it's just that it's one of the hundred fields that exist / not their job : )
<discocaml>
<cod1r> im a frontend dev and im so bad
<discocaml>
<cod1r> 🤣
<discocaml>
<yawaramin> right but desktop UI stylish + polishing is a whole different level of dark arts that few know
<discocaml>
<youngkhalid> Ahahah it's getting easier and easier in the web world though with all the new libs (importing components via npx directly, with stuff like shadn, what the unovue guys do...etc)
<discocaml>
<yawaramin> web, you can kinda wing it with CSS frameworks. making your own desktop framework: you have to start from scratch. you lose all the UI polish that the major platforms put decades of work into
<discocaml>
<youngkhalid> The downside is that it gets more and more monotone as these people are using the same components
<discocaml>
<youngkhalid> But avoids doing everything from 0 for someone who want to **get things done**
<discocaml>
<yawaramin> is that really a bad thing though, now i don't need to leave N different button styles
<discocaml>
<yawaramin> learn*
<discocaml>
<youngkhalid> it's better for people who don't want to spend hours for styling stuff (and they have reason for not doing so, actually enterprises don't want you to be spending time doing that, time costs $$ ahah )
<discocaml>
<youngkhalid> And honestly, sometimes you **don't need to**
<discocaml>
<youngkhalid> So yeah let's say it's like 95% a good thing (more pros than cons)
<discocaml>
<youngkhalid> And most of these libs, their components allow you to custom-them a lot by using props (in React for example)
<discocaml>
<cod1r> i think a lot of companies are starting to just ship electron and use js + react
<discocaml>
<contificate> js_of_ocaml is like magic, I've made many web UIs for programs that use OCaml for business logic
<discocaml>
<youngkhalid> Maybe you'll eventually have to create a whole custom component from scratch, but instead of 100 custom components that you used to create before, with these libs now you need to use 98 components from there an only 2 custom ones, still a better option.
<discocaml>
<youngkhalid> Web world is fascinating world and a very active field, honestly FOSS community carried a lot
<discocaml>
<youngkhalid> The web world is fascinating and a very active field (especially the frontend side) , honestly FOSS community carried a lot
<discocaml>
<yawaramin> i've been building web stuff with Dream, it feels very natural. props to Antron's API design
<discocaml>
<youngkhalid> React, Vue, (before all those: Laravel / Symphony / Angular ), the most used runtime NodeJS and all their related utils emerged 100% thanks to FOSS
<discocaml>
<contificate> I don't really believe in trying to bind widget libraries to langs for desktop GUI in OCaml - just so much work when you can make many programs client/server architecture with such low latency, I've done Qt UIs that use dbus to invoke OCaml and you couldn't tell it's not C++ business logic
<discocaml>
<youngkhalid> Hell they even invented Elm for functi programming in the web like 13 years ago bruh (*haskell lovers happy for once* )
<discocaml>
<yawaramin> interesting, did you use Qt Quick?
<discocaml>
<contificate> No, normal Qt
<discocaml>
<youngkhalid> (Actually it was made by a guy writing a compiler in Haskell for his PhD)
<discocaml>
<contificate> My toxic trait is believing I could actually bind Qt quite well to OCaml, no QML stuff
<discocaml>
<yawaramin> ironically though, the JavaScript SPA people are moving away from virtual DOM to direct updates
<discocaml>
<youngkhalid> in the functional programming world, they did this web stuff first
myrkraverk has joined #ocaml
<discocaml>
<youngkhalid> As soon as I saw the js_of_ocaml, ocsigen stuff, I knew they were in some way inspired by the elm (as it was made specifically to be compiled to JS)
<discocaml>
<youngkhalid> As soon as I saw the js_of_ocaml, ocsigen stuff, I knew they were in some way inspired by Elm (as it was made specifically to be compiled to JS)
<discocaml>
<yawaramin> actually Ocsigen came first
myrkraverk_ has quit [Ping timeout: 252 seconds]
<discocaml>
<youngkhalid> Tbh I thank Haskell as well for slapping me so hard in the face, and making me like functional programming (not the almost 100% pure languages tho), but without it i wouldn't have even tried OCaml i think
<discocaml>
<youngkhalid> But I'm still persuaded Elm had a bigger impact in funct. prog. web dev
<discocaml>
<youngkhalid> (as the language itself was made specifically for that)
<discocaml>
<yawaramin> yes, it was a direct influence on the design of Redux
<discocaml>
<dubious245> I do feel 2 could easily be an anomaly. If you extended the poll to 100s you might still on see around 2 voting for rolling your own. I just thought it was funny that the do it the hard way had 30%.
<discocaml>
<contificate> depends who you poll
<discocaml>
<contificate> if you poll a compiler community, you'll get handwritten as a majority without question
<discocaml>
<youngkhalid> If you poll a vibe coders channel you would get none of those 😂
<discocaml>
<youngkhalid> Guys if you want I can make another poll with more options (I just put 2 because I thought that was the max and It was as made just for me, to have a clearer vision between these specific 2 options, not to say these are the ultimate and only options or whatever), don't take it too seriously xD
<discocaml>
<contificate> the scope needs to be narrowed
<discocaml>
<contificate> parsing _what_? I still have use cases for LR parsing but it's fallen out of being my preference for parsing programming languages
<discocaml>
<youngkhalid> is this better ? ('other" option + allow many answers )
<discocaml>
<contificate> No
<discocaml>
<youngkhalid> So ?
<discocaml>
<contificate> You basically need Angstrom, Dypgen, tree sitter perhaps, etc. and to specify what you're parsing
<discocaml>
<contificate> I used Angstrom for parsing websocket frames because it was simple and easy and has a buffered mode
<discocaml>
<youngkhalid> As far as I know I can't put a "Custom answer" in a poll
<discocaml>
<youngkhalid> It has to be predefined
<discocaml>
<contificate> no, you'd simply specialise in your question
<discocaml>
<contificate> I have my preferences for different parsing tasks
<discocaml>
<youngkhalid> woah, that's opening a whole thread xD can't be reduced to a poll
<discocaml>
<youngkhalid> so the poll wasn't the problem
<discocaml>
<youngkhalid> after all
<discocaml>
<contificate> I'd love to put Leroy's ZINC commentary to him on the Discourse and see what's changed these days
<discocaml>
<youngkhalid> But I get what you're saying, it's a more complex question than a multiple choice thing
<discocaml>
<youngkhalid> It's a question like "what's the best programming language for everything" ?
<discocaml>
<youngkhalid> Well the answer is IT DEPENDS of the use case ! : )
<discocaml>
<youngkhalid> (*OCaml as the answer is allowed too ^^*)
<discocaml>
<youngkhalid> Well the answer is IT DEPENDS on the use case ! : )
Haudegen has quit [Quit: Bin weg.]
ygrek has quit [Remote host closed the connection]
Frostillicus_1 has quit [Ping timeout: 245 seconds]
<discocaml>
<._null._> I was looking for how prefix + is handled, I'm just going to assume it's the same as prefix -
<discocaml>
<._null._> Also, if "+." is not a keyword, but prefix (+.) is not redefinable, what's its status (same for (-.)) ?
_jbrown_ has joined #ocaml
<discocaml>
<._null._> EDIT: "-." *is* a kayword
<discocaml>
<._null._> keyword*
itszor has quit [Ping timeout: 244 seconds]
<dh`>
sorry, got called away by $WORK
<dh`>
so, yes, writing unambiguous expression grammars is a trick, but it's a pretty easy trick to pick up
<dh`>
adding in let-bindings is a headache because their precedence is asymmetric
<dh`>
it's certainly doable, and it's no harder to crib than the equivalent with precedence rules
<dh`>
and it's more robust and more maintainable
<discocaml>
<._null._> The page on lexical conventions mentions | as a valid infix operator, when it is not
<dh`>
it's like many other things, people can't be arsed to put a few hours into learning something and so the typical state of the art is dismal
<dh`>
parser generators _should_ provide tools for these common cases that operate at the grammar level so you can reason about them
<dh`>
but dont'
<dh`>
(another related case is nested if/else)
<discocaml>
<octachron> @NULL, the first table is a subtable of the second how are they contradicting each other?
<discocaml>
<octachron> The `-.` prefix operator is a syntactic sugar for `~-.` and can be redefined.
<discocaml>
<._null._> Contradicting was not the right wors, but it's weird that it's incomplete
<discocaml>
<._null._> word*
<discocaml>
<octachron> Ah maybe, the idea was that the first table only enumerates "operator-like" constructs.
<discocaml>
<._null._> Ok, I got confused by the fact that you can't override the behaviour of any of [+ - +. -.] before constants (and they all work)
<discocaml>
<._null._> The first table doesn't include ?... (and neither include prefix + and +.)
<dh`>
anyway, I would in general not recommend writing a recursive-descent parser for a new language without at least sorting the grammar out in advance with an LR(1) tool
<dh`>
(or stronger than LR(1), but such aren't so readily available)
<discocaml>
<octachron> Ah yes, they are handled as being part of the literal (which indeed create very strange behaviour when redefining `~+`).
<discocaml>
<._null._> I knew in a corner of my mind that + and - had such a specific behaviour, but the fact that +. and -. specifically did, and that they can be applied to integers, was the real surprising factor
<discocaml>
<octachron> For the documentation, my memory is that the last time people tried to document prefix `+`, the discussion derived on removing prefix `+` from the grammar.
<discocaml>
<._null._> Colour me surprised
Frostillicus_1 has quit [Remote host closed the connection]
Frostillicus_1 has joined #ocaml
Frostillicus_1 has quit [Ping timeout: 245 seconds]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 252 seconds]
Tuplanolla has joined #ocaml
algm has joined #ocaml
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 244 seconds]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 248 seconds]
Serpent7776 has quit [Ping timeout: 252 seconds]
myrkraverk has joined #ocaml
myrkraverk_ has quit [Ping timeout: 272 seconds]
myrkraverk_ has joined #ocaml
myrkraverk has quit [Ping timeout: 252 seconds]
Frostillicus_1 has joined #ocaml
<discocaml>
<contificate> speak of the devil - but it's so obvious from `--explain` alone, right? 😏
<discocaml>
<contificate> the main problem with people asking for help with this stuff is they really need to link some kind of godbolt-esque LR manipulation tool - tedious to sit and try to do it all in your head
<discocaml>
<._null._> In this case it's understandable and not too hard to fix, don't you agree ?
<discocaml>
<._null._> I'm currently struggling with non-delimited separated non-trivial lists, I believe they should be better supported out of the box
<discocaml>
<contificate> sure, but I see that they've done a "simple_" factoring which is an idiom you learn from reading other peoples' grammars
<discocaml>
<contificate> not got enough skin the game to reply to that Reddit thread with a solution, but maybe some day I'll see about compiling Menhir to JS and seeing if we can just reason about grammars in the browser, as was the rough intent of a previous thing I developed
<discocaml>
<._null._> I don't see any nonsimple counterpart here
<discocaml>
<contificate> I only glanced over it, but that was the gist I got - may be wrong, just found it particularly relevant to the discussion here, "just use LR parser generators bro" winning the poll, no nuance at all
<discocaml>
<._null._> Maybe I missed it, but what would you recommend instead. Manual parsers have the same issue as menhir in that they arbitrarily solve conflicts, but at least menhir tells you when this happens
<discocaml>
<._null._> ?*
<discocaml>
<._null._> That was badly explained: all grammars that have conflicts are problematic, manual parsers simply solve conflicts arbitrarily, which menhir can also do, but at least menhir makes it known
<discocaml>
<contificate> I think you can build up a more understandable and maintainable parser for expression-orientated languages using Pratt parsing, with some safety delimitation by way of properties you may compute from a grammar (FIRST and FOLLOW sets)
<discocaml>
<contificate> this isn't so radical a view, as it's basically how every mainstream compiler (Clang, GCC, etc.) works
<discocaml>
<contificate> "precedence climbing" is another name for Pratt parsing, sometimes written with slightly different loop structure and naming convention (omitting of "denotation" as terminology)
Frostillicus_1 has quit [Ping timeout: 252 seconds]
<discocaml>
<contificate> at the end of the day, you need a thorough test suite for all compiler-related things, for regression purposes
<companion_cube>
I'd still write a reference menhir parser imho