00:15 <discocaml> <masterbuilder> they are ok to use for primitive types though right?

00:16 <discocaml> <masterbuilder> the normal equality operators

00:16 <discocaml> <masterbuilder> why avoid them in all cases?

00:17 <discocaml> <darrenldl> i guess easier to avoid it completely rather than spending time combing through your own code to make sure you only used it on primitive types

00:19 <discocaml> <masterbuilder> sure I get that but it's only a problem for nontrivial data types and you know when you are using those right?

00:19 <discocaml> <masterbuilder> or if it's a type you don't know anything about and want to play it safe

00:20 <discocaml> <masterbuilder> but the regular types that you use all the time won't trip you up, so it seems a little paranoid

00:20 <discocaml> <masterbuilder> but I guess the uniformity is nice in its own right

01:17 <discocaml> <darrenldl> eh, it helps future refactoring

01:17 <discocaml> <darrenldl> say when you replace a primitive type with something more complex

01:21 <discocaml> <masterbuilder> I suppose that's true, but if you're doing that kind of refactor you can track down all the use sites rather than relying on compiler errors, though the latter is more convenient for sure

01:23 <discocaml> <masterbuilder> but personally I don't think pessimizing the present for some hypothetical future is necessarily a good position, that's another type of paranoia, I guess if you don't care either way it's better to avoid it but I think using methods rather than operators is a bit of an eyesore

02:22 <discocaml> <btcflip> when is ocaml the right tool?

02:25 <discocaml> <jumpnbrownweasel> @masterbuilder Containers and Base don't prevent you from using =, <, etc for scalars (int, float, bool, char), only for all other types (where this is risky and slow). so this provides a safeguard without any real downside. maybe you got that, but i wasn't sure.

02:25 <companion_cube> @btcflip when is it not?

02:26 <discocaml> <masterbuilder> I didn't know that actually, that is cool

02:26 <discocaml> <btcflip> i guess my question is when or why would you confidently use ocaml over existing languages like node or go say if you were building a web server. what does it do better?

02:27 <companion_cube> over node: correctness, speed

02:27 <companion_cube> over go: idk, Go is pretty good for that stuff I suppose. But if you're doing more than just a web server, OCaml is nicer imho

02:30 <discocaml> <jumpnbrownweasel> <https://discuss.ocaml.org/t/why-should-i-use-ocaml/7064/3>

02:30 <discocaml> <jumpnbrownweasel> <https://discuss.ocaml.org/t/favorite-benefits-of-ocaml/12069>

02:32 <discocaml> <btcflip> on another note, is `>>=` and `>|=` ocaml operators? they seem to be only used with lwt but can they be used outside of it

02:34 <companion_cube> you can define them as operators in OCaml, and yes, lwt does define them

02:34 <companion_cube> >>= is definitely used outside of lwt, it's the classic "monadic bind"

02:36 <discocaml> <btcflip> thats pretty cool i didn't know you could define operators in ocaml, thats why i was so confused

02:37 <companion_cube> you can! there are restrictions, notably that the precedence (how it parses) is entirely determined by the first character of the operator

02:37 <companion_cube> so `++!` will parse at the same level as `+`

05:40 <discocaml> <bluddy5> It's very easy to make mistakes with the comparison operators. For example, a higher order function (which ocaml encourages for code reuse) may work well on some types, but will break subtly on other types. It's not even easy to reason about when comparison will break. Hashtables can seem to work for a while until they stop working, causing subtle bugs. And when you go back to change a primitive type to something else, will you remember to cha

05:40 <discocaml> <bluddy5> This is why they should always be avoided.

08:20 <qwr> ocaml comparison operators are a bit weird in being a bit pseudopolymorphic, afaik compiler uses single implementation that operates on runtime memory layout with basically no type information (it follows pointers the same way as GC)

08:21 <qwr> that's why it can break with some types and is suppressed in some alternative libraries like ocaml core

08:22 <qwr> but personally i find it too convenient to use :)

08:34 <qwr> the implementation follows from not having overloading, so these have to be parametrically polymorphic, and ocaml erases the types at runtime without monomorphisation, i.e. the runtime code is single instance that generally won't know the actual types

08:35 <qwr> (which keeps emitted code size down, and makes fast incremental compilation easy, but its tradeoff like always)

09:13 <steenuil> I'm trying to decide how to structure the API for the X11 bindings I'm writing. the protocol consists in sending requests to a socket and getting back a response or an error with the same "sequence number" and also events

09:14 <steenuil> does requiring the user to spin up a background Lwt thread (or whatever they're called) that reads responses sound reasonable? I'd like it to have a simple request-response API for the general use case

09:15 <steenuil> where you can just call let* () = X11.create_window conn in ... or something like that

09:20 <steenuil> then the current thread would write the request to the socket and the background thread would read the response and associate it with the request and send the reply (or an error) back and fulfill the Lwt value

10:10 <discocaml> <froyo> Bluddy: stdlib containers have `equal` functions which take an equality predicate or implement their own equality via a functor provided `compare` + normalization... Hashtbl has a functor interface for similar reasons... I feel like polyeq fud is a bit overblown. Just need to be aware of it especially when designing your own (polymorphic) apis. As for "designing for the future", it probably is a bigger problem that you're exposing the internal

10:10 <discocaml> <froyo>

10:10 <discocaml> <froyo> polyeq is a nice compromise and I'll die on that hill lol

10:36 <discocaml> <bluddy5> I disagree. It's not enough to be aware of it either. If you use polymorphic equality, it will bite you at some point, and it could be when you least expect it. It could be when you have a whole system set up and running and it fails because someone used comparison over a list of maps, and it worked well until one day it didn't. This is the worst class of bugs, because you'll think everything is fine and your tests might pass, but out of the b

11:40 <discocaml> <leviroth> @jumpnbrownweasel : that thing about scalars is not true, at least in base. Base shadows polymorphic comparisons with ones that operate only on ints. To compare other types you need to get a comparison for that specific type (or recover polymorphic comparisons from the `Poly` module).

12:45 <discocaml> <masterbuilder> that's a good point. I've been reading up on polymorphic compare more and I have to say it is quite shocking to find out how it is implemented. as for solving this problem, is there any reason why the compiler can't statically dispatch on the types and if they are compatible use the corresponding `equal`/`compare` functions if available (or for the built-in types use specialized comparison functions), and otherwise error? is it because i

12:52 <qwr> consider let foo a b = a = b;; the function is polymorphic and the a = b callsite don't know anymore the type parameter, also passing (=)

12:52 <qwr> i.e. imho this could work only with full monomorphisation of polymorphic functions

12:54 <qwr> so the implementation is forced by one of the ground design decisions of how parametric polymorphism is implemented in the compiler

12:56 <qwr> imho it could kind-of fixed by using overloading with the modular implicits proposal

12:56 <qwr> but that wouldn't be backwards compatible

12:57 <qwr> however, it would be possible then to have module that overrides the default (=)/(<>) definitons with more sane ones

13:06 <discocaml> <bluddy5> Type classes were invented precisely to deal with this issue in haskell. Other functional languages piggyback on object-oriented mechanisms in their runtimes. OCaml can't directly support type classes and requires its analog, which is modular implicits (which you mention).

13:12 <discocaml> <froyo> is it intentional that the types of possible printer functions aren't documented in the install_printer directive help docstring and error messages?

13:23 <discocaml> <octachron> Not really? This is probably more a case of uncaught assumptions (aka "what could it be except <insert the current answer whatever its degree of complexity>??" ) .

13:30 <discocaml> <leviroth> @masterbuilder in general the problem with looking at the type and then picking “the” comparison function is that there can be more than one comparison function with the right type, and then what do you do? (And the same goes if you replace “comparison function” with “print function”, “module”, etc.) As you anticipate, modular implicits are an attempt to give a reasonable procedure for answering this question.

13:58 <companion_cube> we really should just not mention modular implicits

14:17 <discocaml> <jumpnbrownweasel> You're right it is only `int`, not all scalars, I'll edit and correct my message.

14:19 <discocaml> <jumpnbrownweasel> @masterbuilder Containers and Base don't prevent you from using =, <, etc for `int` (edit: corrected this, it does not apply to other scalars). so this provides a safeguard without any real downside. maybe you got that, but i wasn't sure.

14:26 <discocaml> <jumpnbrownweasel> One thing that's a little funny is that `Hashtbl` is always used as the example of where polymorphic `=` doesn't work, yet there is no `Hashtbl.equal` method to use as a substitute. It may be better to use `Map` and `Set` as the examples.

14:26 <discocaml> <jumpnbrownweasel>

14:26 <discocaml> <jumpnbrownweasel> I have implemented a `Hashtbl.equal` that I think is fairly efficient, but I don't know if it would be accepted in the stdlib.

14:28 <companion_cube> how does it work? do you sort the individual buckets?

14:39 <discocaml> <jumpnbrownweasel> Nope. It uses `iter` to walk through hashtbl A. When the key changes, it calls `find_all` on hashtbl B to get its list of values. A context ref is used to maintain the current key and list of values. When the key stays the same between iterations, it expects values to be iterated in the same order as in the value list. When a value matches it is popped from the list so at each iteration it checks the head of the list. It has to check

14:41 <companion_cube> hmm

14:43 <discocaml> <jumpnbrownweasel> The assumption is that two hash tables are equal if they have the same keys, and the same list of values per key in the same order. If the values were not in the same order, the behavior of the hashtables would be different.

14:56 <discocaml> <jumpnbrownweasel> I'll post the code in the containers channel in case you're interested.

14:57 <companion_cube> sure :)

14:57 <companion_cube> you probably need a bidirectional test, btw. Inclusion in both ways…

15:12 <discocaml> <jumpnbrownweasel> The 1Hashtbl.length1s are compared up front. And if the value list length is different for a given key, the key comparison at each iteration will detect this.

15:12 <discocaml> <jumpnbrownweasel> The `Hashtbl.length`s are compared up front. And if the value list length is different for a given key, the key comparison at each iteration will detect this.

16:48 <discocaml> <xavierm02_> @therewolf I can't think of an example where a type have two equality functions and it does not make sense to instead have two types with one equality per type. Do you have one in mind?

16:48 <discocaml> <xavierm02_> My impression is that often, one of the equalities refines the other one, so that the type equipped with the latter can be though of as a quotient of the former, and it makes sense to abstract the quotient type to prevent it from being convertible to the initial type.

16:48 <discocaml> <xavierm02_> (The only other case I can think of are int and uint, but I also believe that these should not be convertible)

16:51 <discocaml> <xavierm02_> (Well for integers, the equality test is the same for both anyway)

16:53 <discocaml> <octachron> You don't necessarily want to split a type in two just because you have two distinct equivalences on the type.

16:53 <discocaml> <xavierm02_> (Well for integers, the equality test is the same for both anyway, but if you think more generally about typeclass they give an example of two incomparable notions of "less than" on the same type)

17:03 <discocaml> <xavierm02_> @octachron Do you have a concrete example where you would not want to split the types?

17:03 <discocaml> <jumpnbrownweasel> A partial comparator, for grouping, is one example.

17:04 <discocaml> <hockletock> comparing vectors by magnitude

17:05 <discocaml> <xavierm02_> Ok so like strings compared by their first letter.

17:05 <discocaml> <xavierm02_> Hm

17:08 <discocaml> <octachron> Polar coordinate: it might make sense to compare without the modulo 2π on the period because your points really live on a Riemannien surface and not the plane.

17:09 <discocaml> <octachron> So you have two equivalences on your points: the projection on the plane, and the exact comparison and you might want to switch view on the same data.

17:10 <discocaml> <xavierm02_> I'm starting to get my thoughts in order: If you have a type `t` with several equalities that are totally ordered, the equality you want to put in the typeclass ought to be obvious (the stricted one?).

17:10 <discocaml> <xavierm02_> I'm starting to get my thoughts in order: If you have a type `t` with several equalities that are totally ordered, the equality you want to put in the typeclass ought to be obvious (the strictest one?).

17:13 <discocaml> <octachron> Why impose a choice? Even more so when conversion is not free if you have containers where a deep identity traversal still requires a traversal.

17:21 <discocaml> <xavierm02_> Well if you want to have a typeclass-like handling of `(=)`, you need to choose at most one equality per type to bind to `(=)`.

17:22 <discocaml> <froyo> `Fun.on Vector.magnitude compare` if only... \😔

17:23 <discocaml> <froyo> or `Fun.on (Fun.flip String.get 0) compare`

17:24 <discocaml> <froyo> `(fun s -> s.[0])` did we deprecate that? idr

17:45 <discocaml> <xavierm02_> In all examples so far, we have `eq2 x y = eq1 (f x) (f y)` for some easily-computable function `f`. Does anyone have an example where this is not the case?

18:02 <discocaml> <octachron> Well, by definition, all cases are covered by your example with `eq1` = `eq2` and `f` = `Fun.id`.

18:55 <discocaml> <octachron> No that was a bad argument. More meaningfully, you can have no meaningful equality of the full type, and different equivalences corresponding to different quotients. For instance, there is no good canonical equality on `float -> float`. You can devise a few equivalences however. For instance `f ~ g` if for any polynomial `p` of degree at most `k` `∫_[0,1] (f - g) p = 0` for a given numerical integration scheme.

22:14 <Anarchos> is there a mean to install an opam package without opam doing a tar of the whole installation ?

22:14 <discocaml> <xavierm02_> Ah so basically an undecidable (or way too expensive to compute) equality that can be approximated by reasonable equivalences! There's indeed no reasonable choice of equality in these cases

23:51 <jusensei2> Hi, I'm playing a game in which there's a server that receives messages via TCP and returns a secret if I send the right 4 digit combination. I wrote a program that sends each digit sequentially and it is very slow. I want to change my program so that I can have multiple open connections to the server which would speed up the time it takes for me

23:51 <jusensei2> to guess the password. However, being new to Ocaml I'm not sure what library I should use to accomplish this. Some options seem to be eio and lwt. The eio documentation claims that it replaces lwt so I am inclined to use that one but I would like to hear some suggestions. Any help would be appreciated, thank you :)

23:52 <jusensei2> Slight typo: I meant to say that my initial program sends each combination sequentially (ie 0000, 0001, 0002, etc)