Scala Standard Library 2.13.3 - scala.Option Scala Standard Library 2.13.3 - scala.Option final def fold[B](ifEmpty: => B)(f: (A) => B): B Coming from the scala land, I’m used to seeing the Option.fold take a thunk as argument that only gets executed if the…

There’s no point using lazy here since you’re immediately forcing, you can just use a normal thunk: let init () = linspace (t, x_max) |> Tensor.unsqueeze ~dim:1 in let handle_cdim _ dim () = let splits = Tensor.split t ~split_size:1 ~dim in let x_maxs = List.map splits ~f:(Fn.compose Te…

It looks like you lazy-based solution is more verbose than a simple pattern matching: match channel_dim with | None -> linspace (t, x_max) |> Tensor.unsqueeze ~dim:1 | Some dim -> let splits = Tensor.split t ~split_size:1 ~dim in let x_maxs = List.map splits ~f:(Fn.compose Tensor.to_f…

I agree that it is simpler in this case. I was trying to avoid a match statement since reading “fold” tells me that the Option container is removed but with a match statement I have to read the branches to figure out what happens to the container. My reasoning is similar to why one would prefer map …

Generally speaking, OCaml doesn’t have a call-by-name function parameter feature like Scala. In OCaml we need to be explicit about delayed evaluation. So usually we end up using a function or a lazy value. The main exception to this is for the || (or) logical operator, which does need to have delay…

This is … fertile food for thought. One says to oneself that lazy itself is a counter-example: its argument is lazily evaluated, right? And so, perhaps what one might want, is a systematic methodology for recognizing arguments that are to be evaluated lazily. Something like (inventing syntax that…

[image] Chet_Murthy: One says to oneself that lazy itself is a counter-example: its argument is lazily evaluated, That’s why I said ‘The main exception’, to avoid going into a rabbit hole :wink: (also, lazy is not a function i.e. value-level, it’s a language-level syntax. || is the only truly…

grin I’m only half-kidding, of course, Yawar. Half, b/c I can see the sense in “well, why not? It might be useful!” But also, “boy howdy, that’s a big, biiig can of worms, mang”.

I realize this thread has spun off on a tangent, but I think it should be noted that Lazy.force is not concurrency-safe. So making ways of hiding or implicitly using it before there is an effect system in place to expose “forcers” seems like a bad idea.

I went with this way of writing it since it avoided Lazy while also letting me use fold combinator. Thanks everyone for your inputs!

[image] yawaramin: || is the only truly value-level operator with lazy evaluation) && also does lazy evaluation. Is it not just as much of a value-level operator?

Option.fold with init taking a thunk

Learning

jjb February 23, 2023, 11:16pm 2

This is called get_lazy in Containers. I would expect a version using Lazy to be slower.

2 Likes

Topic		Replies	Views
How do you feel about an Option.merge function in Stdlib? Ecosystem stdlib	31	2349	April 30, 2020
Default of Option.value? Learning	1	286	May 8, 2024
Using let-binding syntax to implement option 'or' Learning	3	1008	October 28, 2019
Lazy dynamic programming in OCaml? Learning lazy , dynamic-programming	1	954	August 12, 2023
Basic questions in ocaml Learning	11	10129	November 7, 2019

Option.fold with init taking a thunk

Related topics