rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
marc_ has quit [Remote host closed the connection]
azimut has quit [Ping timeout: 260 seconds]
<discocaml>
<jobhdez> For those who have programmed with ocaml and Haskell what are the main differences you noticed? Is ocaml really a more practical language?
<discocaml>
<rgrinberg> Answers to that question are likely to be very skewed here.
<discocaml>
<rgrinberg> From my experience, debugging space leaks is hard, and gets harder with larger codebases. Tools to debug space leaks were very immature as well
rgrinberg has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
darchitect has joined #ocaml
darchitect has quit [Ping timeout: 256 seconds]
<discocaml>
<darrenldl> you might want to qualify for clarity's sake which lang you were referring to : v
Serpent7776 has joined #ocaml
Tuplanolla has joined #ocaml
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
oriba has joined #ocaml
bartholin has joined #ocaml
<discocaml>
<contextfreebeer> Cool, I'll give it another chance
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
rgrinberg has quit [Client Quit]
rgrinberg has joined #ocaml
<discocaml>
<fabric.input_output> why is this happening? (`type t = { ip : Ipaddr_sexp.V4.t; port : int } [@@deriving sexp, compare]`)
<discocaml>
<_ggole> My uninformed guess is that `%test_eq` is using `=`, which has been given the type `int -> int -> int` by opening `Core` or something like that
<discocaml>
<_ggole> You can test that by doing `let f : 'a. 'a -> 'a -> bool = (=)`
<discocaml>
<_ggole> Which will complain if `=` has the more restrictive type
waleee has joined #ocaml
<discocaml>
<Kali> darrenldl: it is almost certainly haskell; space leaks are a notorious problem for it due to the way you can build up enormous thunks that could've been strictly evaluated just fine
<discocaml>
<Kali> there are lots and lots of articles about avoiding space leaks in haskell
<discocaml>
<idontwantausernamefeckoff> lazy evaluation always interested me about haskell
<discocaml>
<Kali> there are some pretty wild things you can do with it, and it certainly can make some... *aesthetically pleasing* solutions, it's not very good for writing fast or low memory solutions
<discocaml>
<Kali> https://redd.it/5xge0v here's some pretty crazy solutions using laziness in haskell for instance
<discocaml>
<fabric.input_output> yeah ok that does indeed happen, how do I fix this though, even if I remove `open Core` and add the `Core.` prefix at the places where it is used doesn't fix it
<discocaml>
<_ggole> You could try `let (=) = Stdlib.(=) in [%test_eq ...]`, but if there is a variant of `%test_eq` that lets you pass an equality predicate, I would use that
<discocaml>
<_ggole> (And add `equal` to your list of `@@deriving`.)
<discocaml>
<fabric.input_output> I can't because `Ipaddr_sexp.V4.t` doesn't derive equal, but even when I do it manually with `let equal (a : t) (b : t) = compare a b = 0`, it still keeps erroring
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<discocaml>
<fabric.input_output> oops there was a `let open Core in` in the testing function sorry
jabuxas has joined #ocaml
Serpent7776 has quit [Ping timeout: 272 seconds]
azimut has joined #ocaml
<discocaml>
<regularspatula> If you’re planning to use core, it is designed to be opened …so you will run into this sort of thing
<discocaml>
<hakimfb> hello, I would like make a cma file compiled from a set of cmo. However when i move the cma file into another folder, and load it on the toplevel ocaml everything is ok, but nothing can be called 😦 If i check the content of my cma file with ocamlobjinfo i see my module correctly. anyone has this trouble?
<discocaml>
<hakimfb> oups i forget to add the cmi files! Sorry!!
rgrinberg has joined #ocaml
rgrinberg has quit [Ping timeout: 255 seconds]
rgrinberg has joined #ocaml
Serpent7776 has joined #ocaml
<discocaml>
<fabric.input_output> yeah but it was overriding other stuff that were supposed to override the stuff from `Core`
jabuxas has quit [Ping timeout: 255 seconds]
<discocaml>
<idontwantausernamefeckoff> how do i get dune to link in a c library?
<discocaml>
<idontwantausernamefeckoff> with (flags (:standard -cclib -lcurl)) i get undefined reference errors
<discocaml>
<idontwantausernamefeckoff> from the linker
<companion_cube>
What's the error like? Do you have a .a for it ?
<companion_cube>
Anyway you should use dune's specialized stanzas for foreign archives
<discocaml>
<idontwantausernamefeckoff> this is using the ctypes with pkg-config, which is generating the right flags
<discocaml>
<idontwantausernamefeckoff> i can build the library with the stubs, but not an executable depending on it
<discocaml>
<idontwantausernamefeckoff> so i cant reference stubs created by ctypes from other libraries??
<discocaml>
<idontwantausernamefeckoff> i have no idea why that would be the case
dnh has joined #ocaml
neiluj_ has joined #ocaml
neiluj has quit [Ping timeout: 268 seconds]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
neiluj_ has quit [Quit: Konversation terminated!]
dnh has joined #ocaml
jabuxas has joined #ocaml
jabuxas has quit [Remote host closed the connection]
jabuxas has joined #ocaml
jabuxas has quit [Remote host closed the connection]
bartholin has quit [Quit: Leaving]
jabuxas has joined #ocaml
jabuxas has quit [Client Quit]
jabuxas has joined #ocaml
jabuxas has quit [Client Quit]
<discocaml>
<bluddy5> I used to work on a fairly large Haskell codebase. It's a good language, but laziness by default sucks, and purity causes the most incredible contortions. I don't like needing to write monadic code just to get something done. Also, Haskell programmers tend to be in love with being terse, making it extremely difficult to read haskell code. It's very neat when you can get away with *writing* things in a terse way, but when you go back to *readin
jabuxas has joined #ocaml
rgrinberg has quit [Ping timeout: 255 seconds]
<discocaml>
<Kali> i find ocaml being more explicit being only slightly more painful to write, but far easier to read
<discocaml>
<Kali> you can pretty safely guess what the types are just by looking at code
<discocaml>
<jobhdez> Thanks! I have built a compiler in Haskell and want to try ocaml next. I’m also moving away from pure functional programming. I think a mostly functional approach that allows mutation is best
<discocaml>
<bluddy5> Yeah the ideology sounds good until you realize it goes too far for not much benefit. You can get 90% there by just using self-discipline, and then you have the option of mutation when you need it for performance.
<discocaml>
<Kali> i do appreciate being able to see side-effects in types
<discocaml>
<Kali> hopefully ocaml's effects will become typed soon
<discocaml>
<functionalprogramming> i have read elsewhere that effect handlers don't really compose
<discocaml>
<bluddy5> I agree. The only issue I have is that without type-based dispatch, OCaml has a harder time generalizing (for example if I want to generalize over different kinds of containers), and certain basic functionality is just not as convenient as in other languages. A good example that came up here recently is just having a byte stream type for files, buffers or anything else.
<discocaml>
<functionalprogramming> i am not sure if the self discipline argument is so good, we have static typing because it forces itself upon us while dynamic typing would be like self discipline
<discocaml>
<Kali> > A good example that came up here recently is just having a byte stream type for files, buffers or anything else.
<discocaml>
<Kali> this seems like a lacking in the stdlib, not an inherent restriction to ocaml
<discocaml>
<Kali> and the stdlib lacking things is certainly an issue, but not related to issues with generalizing
<discocaml>
<bluddy5> I think dynamic typing for certain things is fine. You don't have to force everything on the user -- at a certain point the gain is minimal. I feel that haskell's purity is really useful a very small fraction of the time. Similar to laziness.
<discocaml>
<bluddy5> But you pay the cost all the time.
<discocaml>
<bluddy5> No it's a real issue. The best solution for many of these things is objects, but OCamlers don't like using them. So we're left with no solution.
<discocaml>
<Kali> i see
<discocaml>
<bluddy5> There have been plenty of discussions about the possible solutions, like a record of functions or a first-class module. None are ideal for this kind of thing.
<discocaml>
<bluddy5> It's also similar to Rust's tradeoffs. Do you want to have to think about memory ownership? It gives you advantages but it's also got a mental overhead. But if you're programming in the realtime domain, you have to think about that stuff anyway, so the price is worth it.
rgrinberg has joined #ocaml
justache has quit [Ping timeout: 256 seconds]
<discocaml>
<idontwantausernamefeckoff> the object system seems like a self fulfilling prophecy
justache has joined #ocaml
<discocaml>
<idontwantausernamefeckoff> people don’t use it because it’s slow and uncommon, it doesn’t get more attention in the compiler and stdlib because people don’t sue it
<discocaml>
<bluddy5> Personally I wish it was a regular object system like other languages. The way it was implemented, it's really too dynamic to make it efficient without a lot of effort.
<discocaml>
<fabric.input_output> I haven't looked at the object system, but is it like dynamic dispatch inheritance type of thing?
<discocaml>
<lukstafi> Just goes to prove that OCaml's features are there for good reason. Objects are not going away, and maybe shouldn't be shunned into the visitor pattern corner.
<discocaml>
<lukstafi> Precisely.
<discocaml>
<Kali> does anyone know where i can read about some performance statistics about objects vs modules?
<discocaml>
<Kali> people always say they're slower but like, how much slower
<discocaml>
<lukstafi> It's virtual methods in the C++ sense (not as powerful as multi-dispatch.)
<companion_cube>
On microbenchmarks iirc it's maybe 2 or 3x the overhead of calling a record field fonction
<companion_cube>
But that's if you don't do anything else
<discocaml>
<Kali> what would doing something else entail