Vavr: Create interface NonEmptyList

[danieldietrich]

List.Cons <: NonEmptyList <: List

This is useful in conjunction with Validation, see http://eed3si9n.com/learning-scalaz/Validation.html#NonEmptyList

NonEmptyList is best placed as top level class within javaslang.collection.

[mvh77]

You can also check out Scalactic Chain which is a non empty list and Every which is a non empty vector:
http://doc.scalatest.org/2.2.4/index.html#org.scalactic.Chain
http://doc.scalatest.org/2.2.4/index.html#org.scalactic.Every

I hope you don't plan on doing any API breaking changes in any future minor milestone?

[danieldietrich]

Thanks Martti, I will check those out.

Javaslang needs to be stable on minor releases!

[danieldietrich]

I don't see the reason why to have NonEmptyList. Why not use List.Cons instead?
I will close this issue, it looks artificial to have such an interface only for List but not for all Traversables or at least for all sequences. But that would be too much for Vavr.

[andys8]

@danieldietrich I was looking for a implementation in Java and I expected vavr to contain it. Is there a recommendation to achieve a type safe list/collection/traversable, that has at least one element? Or is it something think is not related or relevant for vavr? Just curious :)

For comparison:

• http://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-List-NonEmpty.html
• https://package.elm-lang.org/packages/mgold/elm-nonempty-list/4.0.1/
• https://typelevel.org/cats/datatypes/nel.html
• https://pursuit.purescript.org/packages/purescript-lists/4.0.1/docs/Data.List.NonEmpty
• https://gcanti.github.io/fp-ts/modules/NonEmptyArray.ts.html
• http://www.functionaljava.org/javadoc/4.5/functionaljava/fj/data/NonEmptyList.html

[szatmariandras]

@danieldietrich

Why not use List.Cons instead?

The constructor of List.Cons is private, so there is no way to create an instance of it other than through the methods on List. However, those return instances of List, so you cannot even type hint it like:

other.<List.Cons>foldLeft(List.of(head), mapper)

If you have the stomach you can try typecasting, but then every method on the Cons returns a List instead of Cons, so you get out of the non-emptyness right away:

other.foldLeft((List.Cons) List.of(head), List.Cons::prepend);

There are many reasons to use this data structure, see @andys8 's exhaustive list of links.

[danieldietrich]

Let's wait for Java 14+. There will be Records and object deconstruction/pattern matching via switch expression introduced. I do not want to mimic Haskell or Scalaz/Cats. It should work the same way Java users would expect it from standard Java.

ATM we should not expose Cons and Nil at all because it is not clear if and how upcoming sealed types can be used in Vavr. However, I cannot just remove them because of backward compatibility and Vavr's pattern matching (which will be deprecated).

Why do you want to expose Cons and Nil. What is your use case. Why can't it be achieved by checking isEmpty et al.

[szatmariandras]

@danieldietrich

Maybe you misunderstood me. I wouldn't expose Cons, it only came up because you wrote

I don't see the reason why to have NonEmptyList. Why not use List.Cons instead?
before.

I agree to not change anything on the List implementation itself. I'm arguing for NonEmptyList, which a separate type of its own, for slightly different purposes.
Here's a short one from one of the links from before:

A list that is known, at compile-time, to be nonempty. This means head and tail are guaranteed to succeed and you don't have to carry Maybes throughout your program.

[danieldietrich]

There are two reasons not to do it:

1. I don't see a benefit on the use-site? Why would one need the type List.Cons?
2. We once exposed List.Cons as return type and had to change it because we experience problems in APIs like pattern matching. Also the visitor pattern requires our APIs to return a homogenous return type.

We will leave it as is.