06:48 <discocaml> <struktured> Can anyone think of an example of `filter_map` where separately doing the `filter` followed by the map or the `map` followed by `filter` is less efficient than a version which leverages `filter_map` directly? By more efficient, I don't mean the allocation overhead but instead some sort of computation that you only have to do once instead of twice.

06:48 <discocaml> <struktured>

06:49 <discocaml> <struktured> Every example I come up with can be typically be optimized just by changing the ordering of the operations to suit the problem.

06:49 <discocaml> <struktured> Can anyone think of an example of `filter_map` where separately doing the `filter` followed by the `map` or the `map` followed by `filter` is less efficient than a version which leverages `filter_map` directly? By more efficient, I don't mean the allocation overhead but instead some sort of computation that you only have to do once instead of twice.

06:49 <discocaml> <struktured>

06:49 <discocaml> <struktured> Every example I come up with can be typically be optimized just by changing the ordering of the operations to suit the problem.

06:51 <discocaml> <struktured> Can anyone think of an example of `filter_map` where separately doing the `filter` followed by the `map` or the `map` followed by `filter` is less efficient than a version which leverages `filter_map` directly? By more efficient, I don't mean the allocation overhead but instead some sort of computation that you only have to do once instead of twice.

06:51 <discocaml> <struktured>

06:51 <discocaml> <struktured> Every example I come up with can typically be optimized just by changing the ordering of the operations to suit the problem.

07:14 <discocaml> <darrenldl> i mean if you ignore allocation overhead, then doing `map` before `filter` seems to necessarily accommodate all of `filter_map`, including shared computation results between mapping and filtering stages

07:31 <discocaml> <struktured> That's exactly what I thought too. thanks for confirming

08:41 <discocaml> <sim642> If the filtering condition isn't a direct check on the element and gives a result to use, then you don't want to repeat it

08:51 <discocaml> <sim642> For example, instead of filtering on Map.mem and mapping to Map.find, you could filter-map with Map.find_opt. It avoids looking each element up twice in the map

09:31 <discocaml> <darrenldl> sure, but the idea was whatever you can ascertain during the filter phase, you could very well captured that in a `map` first, and then run it through `filter`

09:31 <discocaml> <darrenldl> could have*

09:32 <discocaml> <darrenldl> (in the above case, `... |> map Map.find_opt |> filter Option.is_some`, which is still just one lookup)

09:33 <discocaml> <darrenldl> (well okay one more map at the end, and not as clean, hm)

10:01 <discocaml> <Et7f3 (@me on reply)> [ -1; 1 ] |> map (fun i -> "test".(i)) |> filter (... WTF OOB already done ...)

10:01 <discocaml> <Et7f3 (@me on reply)> then suppose we always filter before map

10:01 <discocaml> <Et7f3 (@me on reply)> [ 1; 2; 3 ] |> filter (fun x -> x mod 3 = 0) |> map (fun x -> x * 3)

10:01 <discocaml> <Et7f3 (@me on reply)> [ -1; -2 ] |> filter (fun x -> "test".(x) = 't') |> map (fun x -> ~-x) AGAIN OOB

10:16 <discocaml> <Et7f3 (@me on reply)> Oops sorry for typing in my first example. It was just to demonstrate that `map` should always be after `filter`. Then it is computational equivalent. Second example also show that doing map before filter might produce unexpected result (or we modify with mod 9)

10:16 <discocaml> <Et7f3 (@me on reply)> The last case suppose you have only negative index: the correct code would test -x throw that value and only keep boolean. Then redo map. Ok -x is cheap to compute but it is wasted computational time

13:18 <pgiarrusso> @Et7f3 if the map argument is pure, you can always filter after map. But it is true that you'll map more elements, so that can be much slower.

13:21 <pgiarrusso> But then you could do a first map for any computation needed both by filter and map, then filter, then map again to conclude.

13:25 <pgiarrusso> If you care for the allocations, I guess you'd need to get fusion somehow (not sure if OCaml can do that?), or fuse all by hand in a single concat_map

15:54 <famubu> Hi. I was trying to get familiar with module types in ocaml and did this: https://bpa.st/SKGQ

15:54 <famubu> But that's giving error. Does anyone know how to fix this? I'm sure it's something trivial. I've included the error as a comment in the paste.

16:01 <discocaml> <hockletock> put the type in the signature if you want it to be visible outside the module

16:02 <discocaml> <hockletock> make the second line `type t = int` rather than simply `type t`

16:05 <discocaml> <hockletock> if you don't want to expose the type in the signature you need to provide a way to construct values of the given type e.g. add a `val of_int : int -> t` to the sig and `let of_int = Fun.id` to the module definition

16:10 <famubu> Ah.. okay. I get it. Because of the signature, the value of `t` is opaque. Thanks!

16:26 <discocaml> <Et7f3 (@me on reply)> pgiarrusso: does sqrt is a pure function ? Because if we map sqrt on negative integer you get garbage (complex number). So the pure criteria shouldn't come in play. So I really think we should filter before map

16:30 <pgiarrusso> for “map before filter” of course you must preserve enough info to run the filter

16:31 <discocaml> <Et7f3 (@me on reply)> The question was if we don't consider allocation overhead. So without filter_map you need first filter for precondition check then map that produce common value used by filter and map then filter and map again yo clean.

16:33 <discocaml> <Et7f3 (@me on reply)> Suppose I have function with invalid input run indefinitely I really need to filter to verify precondition

17:13 <pgiarrusso> Indeed. To me it's the same rule — I'm among those who count divergence as a side effect 😀

20:38 <discocaml> <rbjorklin> Anyone know of a good write-up for converting a library from Lwt only to also supporting Async via use of functors? If no write-up exists any recommendation of a repo that does this in a clean way would be appreciated.

20:45 <Anarchos> rbjorklin it is way over my head

21:20 <companion_cube> I don't know if it's clean but look maybe at cohttp? I think it does it (not entirely sure)