Updates for 0.8 (again... "moduleified")

[garyb]

Ok, this is the last time I'll faff around with this now.

The content is much as it was before, with some new additions (explained below), and I've moved things out into modules. This at least makes the relationships between things clearer in case we ever do split things out into separate packages, as I was working on before, and also may make for tidier imports rather than having a mega list of things imported from Prelude, if things are imported from the modules individually instead.

Controversial/discussion points:

• The full modules from purescript-control have been moved here for Functor, Apply, etc. The thing I had in there that re-exported stuff from Prelude to make a cohesive module export that included the classes as well as functions like ($>) was pretty gross, and those functions are really damn useful anyway, so I brought them in. The modules can be removed from purescript-control accordingly, leaving the other, less-core control stuff (Alternative, Comonad, and associated hierarchies). I figure adding the stuff here will have no major effect on bundled compiled code size, thanks to DCE.
• A chunk of Data.Ord from purescript-orders was moved into the Data.Ord in here. I'd suggest the Down, Min, Max newtypes can stay in orders in their own modules to avoid the conflict with the "new" Data.Ord.
• Data.Void was added, although without coerce as that requires Contravariant. coerce can go and live there instead.
• return was dropped in favour of pure
• (<>) was dropped in favour of (++), I know we still haven't settled this, but ¯_(ツ)_/¯... commence flamewar. My reasons: (++) is more suggestive of appending when dealing with things like strings, arrays. Almost all other operators based around (<>) are for functorial types. Bad memories of VB 😄.
• There's a Data.Function in here with const, flip, ($), (#), and I pulled in on from purescript-functions. I suggest we rename the module currently provided by that package to Data.Function.Uncurried or something similar instead.

edit: now resolves #57, resolves #58.

[hdgarrood]

👍 lgtm. I'm not sure about the Partial constraint on unsafeCompare though - It isn't a partial function, it just might give a nonsense answer sometimes. If Partial is for "The type system won't protect you here, so be careful when you use this function", then I'm not sure Partial is the most appropriate name.

[hdgarrood]

Oh also, does BoundedOrd need to be finite? What if you had a type which represented the interval [0,1]? Totally ordered, has upper and lower bounds, but not finite.

[garyb]

Good point with Partial on unsafeCompare, I'll drop it.

I think the BoundedOrd/finite thing is an issue of terminology. I'd thought of any Bounded type as finite, in that it falls within a finite range, but you're right that it could have infinite inhabitants (in theory, not in practice if we're using JS numbers 😉), so it's probably not the right word to use.

[hdgarrood]

Ah yeah, not with JS numbers of course, but we can get a lot closer to "infinite" with ratios of arbitrary precision integers.

[garyb]

• Rephrased the comments for Bounded and BoundedOrd to avoid the use of "finite"
• Dropped Partial constraint from unsafeCompare

[garyb]

• Ok, after more votes on IRC it seems (<>) is the winner for semigroup
• Fixed that (>>>) was defined as compose rather than (<<<) as it should have been

[paf31]

👍 LGTM!

[garyb]

Cool, I'll work on the compiler inlining updates to support this and the existing Prelude tomorrow then 😄

[garyb]

I think this is good to go for an v1.0.0-rc.1 release now. I've rebased to include the recent Show instance fixes for Char and String, and rolled in the change to make Unit a foreign value.