06:51 <greenbagels> oh WOAH the ocaml.org/docs page now references CS3110 and RWO? :o

06:51 <greenbagels> "now" as in "since i last noticed" :p

07:15 <greenbagels> Also; so RWO has a section describing the difference between Hashtbl and Map; but I believe they're describing those data structures provided by JS's Base module, so I'm unsure what claims are unique to that

07:19 <discocaml> <functionalprogramming> thats the problem

07:19 <greenbagels> but what i gather is that ocaml out-of-the-box provides the 3 major types of associative arrays: 1.) a list-based one, in the List module; 2.) a hash-based one, in the Hashtbl module; and 3.) a binary tree-based one, in the Map module

07:21 <greenbagels> are the major differences between these 3 just the standard performance implications of the implementations, plus the mutable vs immutable nature of the three?

07:35 <dh`> I don't entirely follow the question because there's a lot of kinds of tree-based maps

07:39 <greenbagels> yeah sorry im rambling a bit

07:39 <greenbagels> basically in my mind when looking at these 3 options there's like 2 things that stand out most immediately to me

07:40 <greenbagels> 1.) the choice of data structure used in the implementation, which in my mind largely determines the performance characteristics of lookups, updates, etc.

07:41 <greenbagels> 2.) whether the operations over the type are side-effecting or not / whether the type is mutable

14:16 <discocaml> <deepspacejohn> Am I correct to believe that the only way to guarantee evaluation order is with let-bindings?

14:16 <discocaml> <._null._> If you consider `;` as a form of let-binding, since they do in the same way

14:17 <discocaml> <._null._> Also, the condition in an if/then/else and the scrutinee of a match are evaluated before the branch

14:17 <discocaml> <deepspacejohn> ah, yes that sounds right. That doesn't apply for what I'm doing though.

14:18 <discocaml> <deepspacejohn> I'm actually trying to write a DSL that's using an infix operator to simulate `;` to sequence its "unit" expressions, and I just realized everything's evaluating backwards 🤦‍♂️

14:18 <discocaml> <._null._> Unless I'm missing something, the only places where evaluation order isn't defined is arguments, in either function application or "constructor application"

14:31 <reynir> I always get the arguments to `dune cache trim` wrong - I always think --trimmed-size will trim the cache down to that size but no that's what --size does

15:02 <hannes> reynir: I suggest to disable the cache, see https://github.com/ocaml/dune/issues/7819#issuecomment-1840946723 "cache at its current state is indeed problematic" (and I've suffered quite a bit from it, including it filling up my hard drive)

15:16 <discocaml> <elliottcable> Hm. Is there any well-liked-but-smallish library that defines an interoperable "this is, indeed, a _unicode_ string" type? before we go roll our own, I thought I'd check; but I didn't see anything in uutf or w/e

15:17 <companion_cube> ah sadly no

15:17 <discocaml> <elliottcable> there's plenty of tools/implementations of doing the actual work that we'll need to do at the boundaries between unicode/raw-bytes; the only real remaining issue is whether we wrap all that into a `UTF8.t` of our own, or use soemthing vaguely standard

15:17 <companion_cube> we could absolutly have `type Ustring.t = private string`

15:17 <discocaml> <elliottcable> is there a batman-cape emoji — a very "sounds like a job for … ~companion_cube!~" moment :P

15:18 <companion_cube> https://c-cube.github.io/ocaml-containers/last/containers/CCUtf8_string/index.html I mean there's this, but it should be in its own library (or stdlib, really)

15:18 <discocaml> <elliottcable> v. ocaml-trace-y; "this thing is almost a no-op, can we please just _agree_ on the one thing? thanks"

15:18 <companion_cube> ahah yeah, having people coalesce around a particular solution is the *hard* part alas

15:19 <discocaml> <elliottcable> psh no it's not, just be loud and aggresive, that solves all problems, right? :P

15:21 <companion_cube> I mean that's where I'd hope dbunzli would just propose that to the stdlib

15:21 <discocaml> <elliottcable> i remember a deep discussion this on a GitHub issue on ocaml/ocaml, but i can't find it with a quick ddg

15:23 <companion_cube> when even the search engine people can't find it… :p

15:24 <companion_cube> that said I'm not sure the stdlib would accept stuff like that :/

15:33 <discocaml> <elliottcable> oh god am i "search engine people now" halp

15:33 <companion_cube> :D maaaaybe?

15:33 <discocaml> <elliottcable> anyway low-key expect opinionated `ocaml-unicode` from me, then, if nobody else is gonna do it, soon, big shrug

15:34 <companion_cube> you're thinking of a encompassing library? that collates together the uutf, uucp, etc. alongside new types?

15:35 <discocaml> <elliottcable> that's ambitious; probably not — but I'm open to thoughts? (… or somebody else doing it better than I will :P)

15:35 <discocaml> <elliottcable> was thinking just litearally a private type; and wrappers for the uutf/uucp functions that should take/return that private type, but not the rest of uutf/uucp

15:35 <companion_cube> actually uutf might not be needed after 4.14

15:36 <companion_cube> since the stdlib has codecs

15:36 <discocaml> <elliottcable> oh yeah, I forgot; fantastic

15:36 <companion_cube> no I mean, you could have a `utf8_string` library with mostly the type alias and helpers

15:36 <companion_cube> and then `utf8_string.normalize`, `utf8_string.compare`, etc. that come with optional uu** dependencies to add features :)

15:36 <discocaml> <elliottcable> but yep, precisely that — maybe a GADT over an `encoding` variant, though, so I don't need a dozen modules …

15:37 <companion_cube> do you need multiple encodings, or do you want to embrace the truth that only UTF8 is worthy?

15:37 <companion_cube> 🙃

15:38 <discocaml> <elliottcable> hahahaha. if i'm keeping this inside ahrefs, definitely waaaaay too lazy to make it fancy; but if i want to try and convince people to accept it (and by "accept it", realistically, I mean "publish submodules that take/return `Unicode.t` as an addition to the usual ones operating over `bytes`"), then I suppose i have to be not-lazy and try and make it general >,>

15:40 <companion_cube> just don't call it `Unicode.t` plz

15:41 <companion_cube> more descriptive

15:43 <companion_cube> … like `Utf8_string.t` say

15:43 <discocaml> <elliottcable> yeah, I don't want to conflict w/ anybody, either. (looking at you, compiler-lib `Trace` module …)

15:47 <companion_cube> lolol yeah

15:47 <companion_cube> so annoying

16:42 <discocaml> <dalpy> Hello, where do I ask questions about menhir?

16:56 <discocaml> <elliottcable> here is probably fine; https://dontasktoask.com/

17:01 <discocaml> <dalpy> damn, I'll cut to the chase then: has anyone ever played around with menhir's new syntax? I don't understand why binding the same rule several times with a `~` pattern is not allowed. This example grammar raises the error:

17:01 <discocaml> <dalpy> ```

17:01 <discocaml> <dalpy> %token TRUE "true" FALSE "false" IF "if" THEN "then" ELSE "else" EOF

17:01 <discocaml> <dalpy>

17:01 <discocaml> <dalpy> %start <expr> main

17:01 <discocaml> <dalpy>

17:01 <discocaml> <dalpy> %%

17:01 <discocaml> <dalpy>

17:01 <discocaml> <dalpy> let main :=

17:01 <discocaml> <dalpy> ~ = expr; EOF; <>

17:01 <discocaml> <dalpy>

17:01 <discocaml> <dalpy> let expr :=

17:01 <discocaml> <dalpy> | "true"; { Ast.True }

17:02 <discocaml> <dalpy> | "false"; { Ast.False }

17:02 <discocaml> <dalpy> | "if"; ~ = expr; "then"; ~ = expr; "else"; ~ = expr; <Ast.If>

17:02 <discocaml> <dalpy> ```

17:03 <discocaml> <dalpy> suppose `Ast` is an external module that defines the `True` `False` and `If` constructors

17:10 <discocaml> <._null._> What error do you get ?

17:13 <discocaml> <dalpy> Error: The variable expr is bound several times.

17:15 <discocaml> <._null._> Then apparently it doesn't support the syntax if you need to make more than one call to the same rule, you'll have to name them (I suspect the production won't need changing)

17:18 <discocaml> <dalpy> naming rules, aside, the semantic action changes to `{ Ast.If (e1, e2, e3) }`, which kinda sucks

17:18 <discocaml> <dalpy> naming rules aside, the semantic action changes to `{ Ast.If (e1, e2, e3) }`, which kinda sucks

17:21 <discocaml> <dalpy> might open an issue on menhir's GitLab repository for this

17:57 <discocaml> <._null._> It doesn't work if you keep `<Ast.If>` ?

19:42 <discocaml> <dalpy> it actually does, silly me not keeping that part. Thank you