00:27 <companion_cube> I assume astring has this feature, containers certainly does

00:27 <companion_cube> Both are saner dependencies than compiler-libs

00:28 <discocaml> <yawaramin> any moderately complex project likely already has astring or something similar in its transitive deps anyway

03:12 <discocaml> <dubious245> What makes for a bad type system? In your opinion? Asking this in general as a curiosity while working on my compiler.

03:30 <discocaml> <contificate> I don't care for overcomplicated stuff or esolang-esque slop as is present in C++

03:31 <discocaml> <yawaramin> unsoundness ie the possibility of the runtime type being different from the static type

04:55 <discocaml> <raiinyzen> why OCaml? why do you (yes you) like it?

04:57 <dh`> for me, because it has working sum types and haskell isn't fit for large projects

05:05 <discocaml> <dubious245> It compiles.

05:05 <discocaml> <dubious245>

05:05 <discocaml> <dubious245> I find how the expression and functions evaluate to be very intuitive to me and this makes writing code very easy. Refactoring code and refining it is very easy and even enjoyable.

05:05 <discocaml> <dubious245>

05:05 <discocaml> <dubious245> While I have some disagreements with its type system I do enjoy that it is statically typed and it tries to get the most from its static typing without bringing that extra weight into the runtime. That last part is **fascinating** to me. Like a moth staring at a flame.

05:05 <discocaml> <dubious245>

05:05 <discocaml> <dubious245> It has a native build system and package manager and I do not have to jump through hoops to include other libraries or build large project.

05:05 <discocaml> <dubious245>

05:05 <discocaml> <dubious245> It isn't very opinionated for the most part. It doesn't raise a fuss if I implement something functionally or imperatively. I can blend the two styles in ways that are comfortable to me.

05:07 <discocaml> <dubious245> Oh and the code is compact wile still reading very well. It has several tools for removing too many parens that some functional languages suffer from.

08:16 <discocaml> <._null._> Undecidability

09:03 <discocaml> <froyo> if it's decidable and sound, or asks me to annotate only when I need features which I know the decidability of isn't possible, then: not having wildcards to skip parts of the sig when I want to annotate.

09:04 <discocaml> <froyo> (Rust lol)

09:42 <discocaml> <froyo> (I mean rust fails both the pre and post conditions here. It requires annotations on every function definition)

09:42 <discocaml> <froyo> (and it isn't decidable in the general case)

09:45 <discocaml> <froyo> anyway it's the difference between a constraining attitude and a specifying one

11:12 <discocaml> <contificate> not only that but, by comparison with other languages, it compiles very fast

11:13 <discocaml> <contificate> just such a nice experience to sit in emacs, see merlin say your buffer typechecks (immediately, ignore enormous - generated - files), and then build it very quickly

11:13 <discocaml> <contificate> other language have slow tooling by comparison and it's not even close

11:13 <discocaml> <contificate> other languages have slow tooling by comparison and it's not even close

14:24 <discocaml> <uberpyro181> What makes this question hard is that different languages are tools optimized to do different things. I would expect a scripting language to have a less restrictive and less burdensome type system than a language for game development, and I would want a heavy type system if I care about proving any properties about my code.

14:25 <discocaml> <uberpyro181> How a type system is designed depends on what featuers are present in the term language, e.g. runtime macros make static typing very difficult

14:25 <discocaml> <uberpyro181> How a type system is designed depends on what features are present in the term language, e.g. runtime macros make static typing very difficult

14:25 <discocaml> <uberpyro181> Or if subtyping is desired, that could change the approach significantly

14:27 <discocaml> <uberpyro181> I guess in some sense, the best type system is the one that verifies every proeprty that you care about and admits everything you don't

14:27 <discocaml> <uberpyro181> as a play off the usual saying that "low level code is everything you don't care about"

14:28 <discocaml> <uberpyro181> but in a vacuum, there are specific properties that you might care about

14:29 <discocaml> <uberpyro181> obvious proof and rewriting properties like confluence, soundness, principal types, etc

14:29 <discocaml> <uberpyro181> stability of substitution

14:30 <discocaml> <uberpyro181> I guess it also comes down to the philosophical question of why some of these properties matter, e.g. why do we expect substitution to always be a total function

14:31 <discocaml> <uberpyro181> I think during the design of ML there was a fair amount of discussion for some of these things, e.g. what are the properties you would expect to hold

14:34 <discocaml> <uberpyro181> aside from stuff you might expect like decidability, soundness, principal types, there is also stuff you might want like complete inference, extensibility (e.g. how easily can you extend case analyses), modularity (how well can you reuse code or build it from components), etc

14:39 <discocaml> <uberpyro181> if the question is really "what makes a system bad" rather than "good", i guess that makes it a lot easier, because there are a lot of ways it can go wrong

14:44 <discocaml> <contificate> I'm in the rare camp that thinks SML is "acceptable", so it's hard to sway me on a lot of things

14:44 <discocaml> <contificate> I don't think the type system matters too much, there's some niceties here and there - but the reality is like

14:44 <discocaml> <contificate> if you dropped GADTs from OCaml, I wouldn't flinch - if pattern matching disappeared, I'd never use it again

14:45 <discocaml> <contificate> that kind of importance of actual features over rules for combining terms of those features

15:15 <theblatte> is there a way to tell opam I don't want it to recompile the world due to "upstream or system changes"? it happens almost every time I have to do an opam operation on my work-managed machine, maybe because some system packages get updated

15:17 <discocaml> <yawaramin> as far as i remember it doesn't recompile the world, usually the compiled artifacts can be reused if the package versions didn't change

15:18 <theblatte> well it starts by recompiling ocaml itself, so then all the other packages need recompilation because of that

15:19 <theblatte> ocaml and ocaml-variants get hit with "upstream or system changes", everything else follows

15:22 <discocaml> <yawaramin> this should be happening only when 'opam upgrade' is run, and then only if if it somehow changes the compiler version

15:24 <discocaml> <octachron> This is can happen if the opam package changes too

15:34 <discocaml> <dubious245> The question is specifically what makes a bad type system; either what features seem completely at odds with your typical goals or makes for a very negative experience. Everyone has different end goals and ideals for a 'good' system and they will happily share that on the internet. They dont always articulate why some systems are bad to them. I think its good to look around and behind to see what people think makes for a bad type system, ra

15:47 <theblatte> yawaramin: this is never because I ran opam upgrade :/

15:48 <theblatte> I work on an unrelated opam package and do a lot of pinning/unpinning/adding/removing that package, and half the time this results in the world getting rebuilt

15:49 <theblatte> opam doesn't say anything more about why it wants to rebuild ocaml so I guess it's going to be hard to debug further

15:50 <discocaml> <yawaramin> oh ok, if you are developing a project with multiple packages, have you tried vendoring with dune instead of the opam pin workflow?

15:51 <discocaml> <yawaramin> dune should be more intelligent about rebuilding

15:53 <theblatte> I don't want to vendor llvm :)

15:55 <theblatte> well, I guess vendoring doesn't have to come with an actual checkout, but there's going to be hassle either way

15:55 <discocaml> <yawaramin> i mean 'vendor' like just check out the repo in your project and gitignore it 🙂

15:56 <theblatte> yawaramin: right. maybe! sounds similar, modulo opam bugs ^^

17:01 <discocaml> <rbjorklin> Anyone know if there has been more progress on Thread Local Storage outside of [the PR](https://github.com/ocaml/ocaml/pull/13355) and [this discussion](https://github.com/ocaml/ocaml/discussions/13356)?

17:07 <companion_cube> I wish

18:30 <discocaml> <mbacarella> holy cannoli, claude code just blew my mind

18:31 <discocaml> <mbacarella> I have some ocaml service that calls getenv in a bunch of places and I've been manually maintaining a list at the top of my main function that probes for all of the env vars to exist. the idea here being to make sure you don't roll something out that depends on an env var that you don't notice isn't set until much later.

18:32 <discocaml> <mbacarella> I have a surly comment at the top of that function that says "must resist urge to parse all *.ml files into an AST and generate this function at build time" and decided this might be something I should throw claude code at

18:32 <discocaml> <mbacarella> and... it succeeded 🤯

18:32 <discocaml> <mbacarella> it parsed everything with ppxlib, crawled the AST looking for getenv calls, generated the check_env_vars function and even set up the dune rules

18:32 <discocaml> <mbacarella> cost: $2.64

18:33 <discocaml> <mbacarella> programming done by humans is OVER

18:34 <discocaml> <yawaramin> leave the Claude. take the cannoli

18:34 <discocaml> <mbacarella> somewhere in the middle claude got frustrated and tried to switch to using regexes and I said no, use ASTs, and it was like "oh yeah good point"

18:34 <discocaml> <mbacarella> so, even LLMs get lazy

18:36 <discocaml> <mbacarella> all programmers are now PMs, sorry

18:36 <discocaml> <mbacarella> all human programmers are now PMs, sorry

18:37 <discocaml> <froyo> theblatte: if opam tracks ocaml from system, and the system upgrades ocaml from underneath it, opam needs to recompile everything iirc

18:37 <discocaml> <froyo> vs installing it directly thru opam

19:16 <dh`> ...where if you update it, it still recompiles everything?

19:17 <discocaml> <._null._> Yes, but ocaml won't be upgraded behind your back

19:27 <discocaml> <froyo> it would be if it's provided by the package manager

19:27 <discocaml> <froyo> opam has that registered as the ocaml-system pseudo-package

19:28 <discocaml> <froyo> and because when ocaml upgrades, paths & magic numbers may change, exes and libs built with old ocaml need recompilation

19:31 <discocaml> <froyo> $ opam info --sw=system-alias ocaml-system -f synopsis

19:31 <discocaml> <froyo> The OCaml compiler (system version, from outside of opam)

19:32 <discocaml> <froyo> dh`: oh. true I guess

19:32 <discocaml> <froyo> but in that case you invoked opam upgrade on your own

19:33 <discocaml> <froyo> whereas opam complains and suggests a recompilation seemingly spontaneously if: ocaml was installed via the system's package manager, and got recently upgraded

19:34 <discocaml> <froyo> and I even think opam upgrade won't upgrade ocaml until you allow it to touch the switch invariants anyway

19:34 <discocaml> <froyo> so it's _more_ your intention

19:35 <discocaml> <froyo> does it make sense why I went with the other scenario then

19:37 <discocaml> <froyo> damn nevermind then. I missed the message where they said they're doing pins/unpins/etc

20:09 <dh`> right, I think the message herein is "don't let the system autoupdate" and "don't forget to update other things after doing system updates"