Question about Option<int>

[kasajian]

Very nice work.

I read the justification for Option<> and it occurred to me that it if you simply look at the basic Option class, without the extensions, it smells a lot like Lazy<>. I would curious what disadvantage there would be using Lazy<> instead of Option<> and making the rest of the framework base on that?

[louthy]

Hi Kasajian. Option<T> and Lazy<T> don't perform the same role. Lazy<T> is deferred processing of a function until the value is required (if at all), and Option<T> is a type that can represent a value or not a value (strictly, there's no laziness to it). A bit like a regular C# reference where it can be a value or be null; however (unlike a null reference) Option<T> explicitly denies access to the contract of the generic parameter type of the Option, if there isn't a value inside.

There is a lazy Option type in the library, and that is TryOption<T>, it's lazy out of necessity due to the fact that it needs to be a delegate so that it can catch any thrown exceptions. Take a look at TryMonadTests.cs to see some examples.

Lazy<T> is closer to 'memoization' in the functional world. Take a look at memo function in Prelude_Memoize.cs

http://en.wikipedia.org/wiki/Memoization

[kasajian]

Thank you for the explanation.

And I agree with you that that's the purpose of the Lazy class, for momization. I was just saying that if put aside as to how the value get inside of Lazy or Option, they are similar in that:

1. The are a container of a value.
2. They work with both value types and objects.
3. They may or may not contain a value.
4. You can query it to determine if has a value.

Lazy doesn't create inner Value until you attempt to access it via the Value property. If you use the version of Lazy where you provide an initialization function, then you can simply access the Value property to force it to contain a value when one exists.

To illustrate, take a look a simple usage of it as an alternative to TryGetValue for Dictionary:

http://programmers.stackexchange.com/questions/159096/return-magic-value-throw-exception-or-return-false-on-failure/264516#264516

(my alias is zumalifeguard)

I can't disagree with you if your position is that using Lazy in this way is hackish and you may not want to rely on it for your framework. I was just curious if that, in fact, your stance.

[louthy]

As I say the behaviour is different. Using a None doesn't turn it into a Some, that is what happens when you use a Lazy. Option types are in one state, and they stay in that state. Lazy start in a 'valueless' state and then gain a value on usage.

[kasajian]

Thank you. You're right. When you have Option in your library, it's ideal. I was suggesting that without such library, if one wishes to return a value from a method that may be an object, null or no-value, then Lazy can be as an internal implementation that mimics Option. The client only sees a version of Lazy with a value or without a value. They don't use it to perform deferred instantiation. Anyway, I think I got the answer to my question. Thanks for your time.