On 07/01/2014 02:35 PM, Sebastian Graf wrote:
>
> Actually, like bearophile pointed out, it's not that Option is a
> range, but that ranges and Option are monads,

Option 'is' a range as much as it 'is'* a monad.

> e.g. mappable and flattenable.

i.e. empty, front, popFront have conforming implementations.

> Being mappable and flattenable is no unique trait of
> ranges,

It is also not everything there is to ranges. OTOH, every range 'is' a monad, so saying that Option 'is' a range is more precise than saying that it 'is' a monad

> that's where the mixup comes from I think.
> ...

The 'mixup' comes from implementing Option at a suboptimally high level of abstraction. More abstraction is unlikely to help here. :o)


* (This is a little sloppy.)

On 2014-07-01 12:45:11 +0000, w0rp said:

> I'm also strongly in favour of Option/Maybe types in general, as a replacement for null. null is one of my pet hates, and things are much nicer when the lack of a value is represented in the type system. (T or Option!T)

I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert.  I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used.

I also liked garbage collected pointers being expressed by the type system.  Clarifies when libraries are expecting to take ownership of a pointer, etc.

-Shammah

On Tuesday, 1 July 2014 at 20:34:05 UTC, Shammah Chancellor wrote:
> On 2014-07-01 12:45:11 +0000, w0rp said:
>
>> I'm also strongly in favour of Option/Maybe types in general, as a replacement for null. null is one of my pet hates, and things are much nicer when the lack of a value is represented in the type system. (T or Option!T)
>
> I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert.  I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used.
>
> I also liked garbage collected pointers being expressed by the type system.  Clarifies when libraries are expecting to take ownership of a pointer, etc.
>
> -Shammah

Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value.

In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error.

Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.

On Wednesday, 2 July 2014 at 04:26:50 UTC, Wanderer wrote:
> Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value.
>
> In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error.
>
> Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.

You're exactly right. Where nullable is most useful is with types that don't have null values. Ints, floats, chars, etc. Then in some hypothetical function IndexOf, instead of returning -1 or int.max or throwing an exception or whatever else we can think up, we simply return a Nullable!int to specify that the index of a particular item may exist or not, depending on if that item is in the array.

Nullable!int IndexOf(int[] arr, int val)
{
    foreach (int i, n; arr)
    {
        if (n == val)
        {
            return Nullable!int(i);
        }
    }

    return Nullable!int();
}

This pattern is very prevalent in functional languages, even when returning objects from functions, because many functional languages do not have nullable objects. Therefore, the concept of "null" is encoded in the type system as some kind of Option type.

On Wednesday, 2 July 2014 at 04:26:50 UTC, Wanderer wrote:
> Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value.
>
> In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error.
>
> Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.

The difference between Option!T and allowing null references for T is that if you take away the possibility of T being a null reference, you never have to check for it, which reduces the number of bugs. Then you can create semantics for Option!T that force you to think about the possibility of lack of value.

Options also kind of fit as ranges too, so in Scala you use map on option types, combine several Option[T] values together into a Seq[T], etc.

On 2014-07-02 04:26:47 +0000, Wanderer said:

> On Tuesday, 1 July 2014 at 20:34:05 UTC, Shammah Chancellor wrote:
>> On 2014-07-01 12:45:11 +0000, w0rp said:
>> 
>>> I'm also strongly in favour of Option/Maybe types in general, as a replacement for null. null is one of my pet hates, and things are much nicer when the lack of a value is represented in the type system. (T or Option!T)
>> 
>> I would have disagreed with you in the past, but I just read some examples from Rust and other languages with strong type systems and I'm a convert.  I'd like to see a compiler flag to turn off null assignment to reference types to enforce Option/Nullable to be used.
>> 
>> I also liked garbage collected pointers being expressed by the type system.  Clarifies when libraries are expecting to take ownership of a pointer, etc.
>> 
>> -Shammah
> 
> Uhm, I'm sorry, but I don't see any difference between two approaches - null-not null vs. one value/no value.
> 
> In both cases, there is a possibility of a situation when the value that "should be there", is not there. It can be either because it's not available yet, or because programmer made a mistake in the code. But in either case, when you try to use the value that's "not there" without cheking first, you get a runtime error.
> 
> Correct me if I'm wrong, but "Option" being suggested here, is just a nullable reference in disguise.

I don't see a huge difference either.   I didn't realize Nullable was already around.  The main thing is that is valuable is that Nullable/Option extended to reference types, and then disabling the usual null assignment to references.   The reason for this is that you can clearly discern when nulls are possible through the type system and when you need to check for them.   Not every function should have to be prepared to check for nulls -- and can express that it doesn't by not accepting a Nullable type.

I wonder if we could have a compiler flag to disable null references as an experiment.

-Shammah

On Wednesday, 2 July 2014 at 11:48:18 UTC, Shammah Chancellor wrote:
> I don't see a huge difference either.   I didn't realize Nullable was already around.  The main thing is that is valuable is that Nullable/Option extended to reference types, and then disabling the usual null assignment to references.

There is a very important difference when all other types considered non-nullable - something we can only achieve by convention in D.

On 2014-07-02 12:04:03 +0000, Dicebot said:

> On Wednesday, 2 July 2014 at 11:48:18 UTC, Shammah Chancellor wrote:
>> I don't see a huge difference either.   I didn't realize Nullable was already around.  The main thing is that is valuable is that Nullable/Option extended to reference types, and then disabling the usual null assignment to references.
> 
> There is a very important difference when all other types considered non-nullable - something we can only achieve by convention in D.

Well.   I'm not sure how much work it would be, but I'd like to investigate having a compiler flag that disables null references and leaves only null pointers available for C compatibility.  I think it would be an interesting experiment.   The D type system is certainly powerful enough to support going that direction (ala Rust, Haskell)

-Shammah