Use NonEmpty for group, group' and groupBy?

[sharkdp]

Using purescript-nonempty, the signature of group could be changed from

group :: forall a. Eq a => List a -> List (List a)

to

group :: forall a. Eq a => List a -> List (NonEmpty List a)

I believe this is not just more descriptive, but also useful because it helps people to avoid unsafePartial <<< Data.List.Partial.head or similar constructions.

On the downside, it pulls in the purescript-nonempty dependency.

The same applies to group' and groupBy.

[paf31]

Sounds good, but we would need to deal with the non-core dependency somehow. We should also apply this to the arrays library.

[sharkdp]

Personally, I'm a big fan of the NonEmpty data type, so I'd love to see it in core 😄. The library is small and rather "innocent", so I guess the maintenance overhead is not too high.

Another option could be to have a separate package, something like purescript-nonempty-lists, which would provide the alternative group functions.

[garyb]

As it happens, the desire to use NonEmpty popped up in purescript-foreign yesterday too, which is also in core, and since it is small and reasonably fundamental moving it over seems sensible to me too 👍

[paf31]

Sounds good to me. My main concern with NonEmpty vs a specific NonEmptyList is that it lacks some instances like Semigroup. I think we could add them, but they might have slightly unexpected signatures like Alternative f => Semigroup (NonEmpty f) (@garyb I think you PR'd this at one point?)

[sharkdp]

I guess we could have NonEmpty in core and still have a specialized nonemptylists package somewhere else?

My main concern with NonEmpty vs a specific NonEmptyList is that it lacks some instances like Semigroup

Do you mean there could/should be a NonEmptyList, different from NonEmpty List in order to write different instances for it?

[garyb]

@paf31 seems familiar, I do remember proposing some slightly strange instances that we didn't go with in the end due to concerns about consistency or something?

[sharkdp]

So if you guys end up deciding that you want to move nonempty to core, I'd be happy to send a pull request to make the changes to group, etc.

I guess it is easy enough to convert a NonEmpty List back to a List by using fromNonEmpty (:).

[jdegoes]

Personally, I'm a big fan of more pervasive use of NonEmpty in making safe APIs (I'd love for it to be in core), and I also prefer the full abstraction (NonEmpty) as opposed to a specialized version that works in fewer places (NonEmptyList), though I'd probably want to take care to add operations that work as expected for lists to NonEmpty's with the proper structure.

Currently I mis-use Tuple a (List a) for non-empty. 😢

[paf31]

So I'm quite keen to keep nonempty ignorant of List, except via appropriate interfaces like Alternative. With that proviso, I'd also like to see it move to core and get used more.

[garyb]

Let's do it then. I think we're all in agreement :)

[garyb]

Bump for @paf31 - still want to make nonempty core and do this?

[paf31]

I like the idea of using NonEmpty, but ideally I'd like some way of using it generically. The attempts to use things like Alternative before have had mixed results, so I find myself wondering about

class Consable f where
  nonEmpty :: NonEmpty ~> f
  toNonEmpty :: forall a. f a -> Maybe (NonEmpty a) 

again. I have reservations about this class too, but maybe it would fit nicely into purescript-nonempty. It generalizes lists (strict and lazy), streams, sequences and arrays, at least.

[garyb]

How would that work with the above? group :: forall a. (Consable f, Eq a) => List a -> List (f a)? I think the concrete type makes more sense here.

I haven't found working with NonEmpty List to be much of a problem, because when you want to treat it like a list you can just oneOf it and proceed as normal - I mainly use it like an invariant-guaranteeing-newtype.

The point about moving it into core was there's another case it was suggested for foreign too: purescript/purescript-foreign#41. I'm quite in favour of using it wherever we can, since it seems we're missing a trick not to use the type system to encode basic invariants like this, as without that sometimes you have to write functions with cases that will never be reached to satisfy the partial pattern checker, etc.

[paf31]

No I think group should return NonEmpty List a. I just wanted some way of writing generic functions which consume NonEmpty structures, but we can come back to that later if we need it.

[garyb]

Oh I see! That makes sense. 😄