hubFS: THE place for F#

Hi,

In F#, one can define lazy evaluation at the call site of a function, i.e.

let f n = n.Force() + 1

then I can pass an expresion in n lazily by calling f as:

f (lazy 5 + 3)

but is there a way to make F# add the 'lazy' automatically, i.e. define f such that it does not eagerly evaluate its arguments?

I could imagine something like

let lazy f n = n.Force() + 1

f (5 + 3)

would then evaluate the expression only when f forces it, without annotation required by the client.

Possible, or whistful thinking?

cheers,

Kurt

Since F# is not a lazy language, it does not seem to be possible.

It might be even undesirable - in contrast with lazy Haskell, F# does not isolate side effects and working with lazy values requires paying special attention to effects in order not to face a hard-to-find bug. So explicitly marking parameters as lazy seems to be better in all cases except effect-free code which is relatively rare in practice because .NET framework is absolutely imperative.

However, active patterns may simplify the function definition:
instead of
let f n = n.Force() + 1

which will not even compile without further type annotations, you may write

open Lazy
let f (Lazy n) = n + 1

I suspect you are asking for exactly the same reason I am!

I want to define an implication operation, which can very nicely be defined as:

let inline (==>) l r = not l || r

But of course, I want this to short-circuit in the same way as ||, but the RHS is evaluated before calling the operator definition.  The RHS might have side-effects or throw exceptions.  I was hoping that the 'inline' would work around this, but it does not.

If anyone has any brilliant ideas for working around this, I would like to know them!

Howard

Library sources, file "prim-types.fs", module IntrinsicOperators:

// Lazy and/or.  Laziness added by the F# compiler.

let (||) x y = if x then true else y

So it's "compiler magic" again and it looks like there's no way to achieve the result with ordinary code except with explicit laziness

hmansell:

I suspect you are asking for exactly the same reason I am!

Heh, exactly the same reason. Are you psychic? :)

Anyway, for consolation: it _is_ safe, i.e. if the left side of the implication is defined as a lazy type, the compiler will complain if it's not in fact lazy.

Kurt

I saw the same problem with fscheck's implication operator (I work with Galen, who reported this problem to you).  I was trying to do a similar thing for a slightly different purpose.

Howard

I can see why one wouldn't want a lazy value being automatically coerced into a non-lazy one via:

    let f (x : float Lazy) =
        let y : float = x   //  probably bad

As you say, it would make it hard for the developer to realize that a side effect might be taking place and deal with it. On the other hand, it isn't clear to me what might go wrong if one had:

    let f (x : float Lazy) = ...

    f (3. + 4.) // Automatically goes 'lazy' without the key word.

It seems as if you've now simply transitioned to a lazy value and the only way to get it is an explicit Force. The addition of the lazy keyword (currently required) just seems verbose in this case and not particularly helpful.

Can you provide insight for the curious?

Hiser, I admit that explicit laziness is too verbose in some cases, especially when implementing the implication operator discussed above. As for your example - well, nothing can really go bad in such a simple case. Frankly speaking, this expression is subject to compile-time optimization yielding a constant value (I don't know whether F# currently performs such optimisations).
But in general it would be impossible for a compiler to distinguish between "safe" and "unsafe" expressions where "safety" means side effects independence. Even extending the language with an additional entity such as "pure" functions would not help much because F# targets .NET framework which has been designed without functional languages in mind.

So the language designer has to decide whether to allow implicit lazy value coercion in all cases or not.
Laziness itself is a nice programming technique making a programming language more expressive. And F# does not tend to be as side-effects intolerant as Haskell which makes it much more suitable for practical programming. But the combination of laziness and side effects may be quite confusing especially when it goes beyond several simple functions. Avoiding potentially unsafe constructs could be a matter of convention but the compiler cannot make any guarantees. Of course, making laziness explicit does not guarantee that everything is correct but it does really help to keep the side effects in mind when you have to deal with them.
Moreover, implicit type conversion (note that 'a and 'a lazy are different types) is not the "F# way" and it is contrary to the language design. I'm not quite sure but I guess it might break the type inference system.

Implementing logical operators is one of the cases where explicit laziness is very annoying and eager evaluation semantics is undesirable. A common practice is to make boolean operators lazy by the compiler itself. For example, in C++ boolean `or` operator (||) does not evaluate its second argument if the first one is true. But if you define the same operator for your own data type it will always evaluate both arguments. So does F#. Examining the generated IL code shows that these operators are actually implemented by code expansion rather than a separate function so that 'a || b' expression is translated into 'if a then true else b'. That leads to one more reason to avoid laziness when implementing the discussed implication operator: in F# laziness adds a significant performance penalty in comparison with a simple function call. And that's not suitable for simple functions because dealing with lazy value (actually a discriminated union type) would take much more time than the function logic itself. I think that the only solution could be some code generation technique like lisp-style macros. The F# manual says that inline functions are implemented by code expansion but this does not result in simple code substitution - otherwise function semantics might be different depending on the inlining and that could be very confusing (just imagine different behaviour of debug and release builds).
So I think we currently can't expect some nice and easy way to deal seamlessly with laziness.