<discocaml>
<otini_> e.g. to “derive” a list printer:
<discocaml>
<otini_> ```ocaml
<discocaml>
<otini_> let pp_list : 'a Fmt.t -> 'a list Fmt.t =
<discocaml>
<otini_> fun pp_v -> Tpf_fmt.data1 Tpf_std.list pp_v
<discocaml>
<otini_> ```
<discocaml>
<otini_> unlike with typeclasses every “instance” has to be called explicitly, but we have learned to deal with this using naming conventions, with ppx_deriving and the like
toastal has joined #ocaml
<rustyne>
there is something really sweet in the approach of typeclasses in Coq, where you can let it guess the class most of the time and choose it explicitly when you want or need to
gooby323 has joined #ocaml
<gooby323>
Do you think the Unboxed OCaml stuff Jane Street has been working on will be making it to us mortals any time soon?
<octachron>
Not anytime soon. This is a R&D project with a lot of moving pieces that must fit together to create a good design.
<octachron>
There are also the slightly worrying part that Janestreet experiments a lot nowadays with their compiler forks on their own code base that they control completely.
<octachron>
Which creates an impedance mismatch with the rest of the OCaml ecosystem, where one cannot expect libraries to switch to the lastest backward-incompatible implementation of a new feature every three months.
<gooby323>
Ah I see, that makes sense, although I think that regions could be an unintrusive feature if the implementation just leaves unannotated code boxed, so that old code and new unannotated code remains fully boxed with traditional semantics
jabuxas has quit [Ping timeout: 256 seconds]
<octachron>
As far as I can see, local regions are rather on the very intrusive side in term of splintering the language in dialects?
<gooby323>
Currently yes with all the Jane Street forks, but if it were included in the main compiler, and if I'm understanding locality correctly, the unannotated code has the same semantics as traditional OCaml, I guess in that sense similar to locally abstract types, so even with such a feature added to the main language, existing code should continue working as before
<discocaml>
<froyo> having a halfway integration where the compiler infers locality as a sort-of transparent optimization would be a much easier sell on jst part.
<discocaml>
<froyo> imo levity polymorphism is a more compelling feature with bigger perf wins.. idk if it's as intrusive but it'd allow for better behaved less wasteful data structures..
<octachron>
"Continue working as before" is a bare minimum; C++ without template works as before, but can you ignore templates in recent C++ code?
m5zs7k has quit [Ping timeout: 252 seconds]
<discocaml>
<eval.apply> for the regions stuff, local values are allocated on a *separate* stack nothing like normal values so it's definitely intrusive
<discocaml>
<eval.apply> and they are barely just now starting to do the unboxing stuff, you can't even use it yet for much on HEAD
m5zs7k has joined #ocaml
wingsorc has quit [Ping timeout: 268 seconds]
waleee has joined #ocaml
<adrien>
hey, I'm using pyml and I define a python function that I'd like to call; I know how to do that for a function from a python module, but not for a top-level definition; does anyone know how to do it? :D
<adrien>
I guess I found I need to use Py.Module.main
<adrien>
let f = Py.Module.get_function (Py.Module.main ()) "your_function_name" in f [| arg1; arg2; ... |]
waleee has quit [Ping timeout: 268 seconds]
bartholin has quit [Quit: Leaving]
toastal has left #ocaml [Error from remote client]
gweithio has joined #ocaml
jabuxas has joined #ocaml
luc4 has joined #ocaml
jabuxas has quit [Quit: oops :p]
<luc4>
Hello! I'm new to ocaml. I'm porting an open source app to newer ocaml versions. I have a lot of cases in which I need to compare the bytes type to a string literal. What I'm currently doing is something like: myBytes = (Bytes.to_string "someliteral"). This, however, requires a copy. I could also cache the conversion in a variable, and then compare. Any other efficient solution?
<luc4>
*sorry, I meant Bytes.of_string
<octachron>
You could implement a `Bytes.t -> String.t -> bool` comparison
<discocaml>
<otini_> yes, that would be one of the legitimate use cases of `Bytes.unsafe_to_string`
<gooby323>
Could just compare them as `Seq`s maybe
<gooby323>
Apparently `String.to_seq` just calls `Bytes.unsafe_of_string` anyways
<discocaml>
<otini_> yes, and going through a lazy sequence is even slower than making a copy
<octachron>
With a custom compare, you can compare int by int in a for-loop to decrease the overhead
<luc4>
octachron: that would make it convenient, but how would you implement it without a copy? Can I memcmp in C maybe?
<gooby323>
otini_: Ah, because of the seq item allocations?
<discocaml>
<otini_> @gooby323 yeah
<discocaml>
<otini_> @octachron I believe this is what `String.equal` does already
<discocaml>
<otini_> people who want to squeeze every last bit of performance may want to implement a custom string comparison function using memcmp https://github.com/ocaml/ocaml/pull/12427
<octachron>
otini_, the point is to have a version of `=` that compare byte and string directly
<octachron>
another option would be to use `let cmp (x:String.t) (y:Bytes.t) = Obj.repr x = Obj.repr y` or the any variant
<luc4>
discocaml: that caml_string_equal function you posted seems pretty much what I'm doing.
<luc4>
discocaml: and it is even used for caml_bytes_equal
<luc4>
discocaml: maybe I could call it for string and bytes as well.
<discocaml>
<otini_> octachron, luc4: what I had in mind was just
<discocaml>
<otini_> ```
<discocaml>
<otini_> let bytes_equal_string (b : Bytes.t) (s : string) = String.equal (Bytes.unsafe_to_string b) s
<discocaml>
<otini_> ```
<discocaml>
<otini_> you also?
<discocaml>
<otini_> this performs a word-per-word comparison, and you can replace String.equal with a custom primitive that uses memcmp if needed
<luc4>
discocaml: I think that may be a good solution! Let me try. Thanks!
<discocaml>
<otini_> np
<discocaml>
<otini_> (not sure who the discocaml username is referring to)
<luc4>
my client reports that name
<gooby323>
Yeah luc4 when you see discocaml, the actual username is after it between the <...> since they are chatting from Discord x)
<gooby323>
It's like <discocaml> <something>
<luc4>
gooby323: ah, I see, thanks. Never heard of it.
<discocaml>
<octachron> The discord bridge is named discocaml on the irc side. I was more suggesting an implementation that avoid unsafe function.
gweithio has quit [Quit: leaving]
palainp has joined #ocaml
<discocaml>
<otini_> @octachron I see
toastal has joined #ocaml
<discocaml>
<octachron> The avantage is that this relies only on {Bytes,String}.{get,get_int64_ne} and not on compiler internals.
<discocaml>
<otini_> in the defense of my solution, it’s explicitly documented as an acceptable usage of the unsafe function
pi3ce_ has quit [Ping timeout: 256 seconds]
pi3ce has joined #ocaml
jabuxas has joined #ocaml
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #ocaml
gooby323 has quit [Quit: Konversation terminated!]