Consider moving orphan instance monoidString into purescript-monoid?

[hdgarrood]

Since the String type comes from the Prim module, if we assume that Monoid should stay in 'userland', the only option to avoid having an orphan instance for Monoid String would be to move it into purescript-monoid.

I'm happy to put PRs together for this if you agree.

[garyb]

This was only just reversed recently actually, so that purescript-monoid could be moved into a better place in the dependency hierarchy. We have a similar situation with Array also, there's a whole bunch of orphan instances in purescript-arrays.

[hdgarrood]

Ah, ok then. If orphan instances are acceptable, then I guess I will need to handle orphans in psc-docs etc in purescript/purescript#1067? Currently, in that branch, all instances are grouped under their related classes and types, like Haddock does - orphan instances don't appear in the output at all.

[paf31]

I would rather not have orphans at all, but the current choice is to have data modules depending on class modules, so strings depends on monoids and the Monoid instance goes in strings. I think the only way to get rid of orphans would be to change to class modules depending on data modules.

[garyb]

I hadn't thought about the fact I was making an orphan when I moved it over actually. Orphans are really not awesome, but the Prim types do make it a little awkward... maybe this should go back to Monoid afterall.

[paf31]

I used to not care quite so much, but the psc-docs changes (which are a good thing) make me care about orphan instances now :)

[garyb]

Avoiding orphans would also mean moving the Functor...Monad instances for Array into the prelude.

[paf31]

Avoiding orphans would also mean moving the Functor...Monad instances for Array into the prelude.

Which I actually think we should do anyway, especially if we're removing special support for arrays. I might even argue for moving [] out of Prim and into purescript-arrays.

Edit: sorry, I mean, I think we should move the type into arrays.

[hdgarrood]

Would it be possible to move the Array / [] type into purescript-arrays and still allow the compiler to understand array literals, ie [1,2,3]?

[paf31]

I'm actually in favor of removing array literals, which might seem drastic, but I think there really are very few cases where you want to just dump an array literal (which can't be constructed neatly otherwise) into code. The only case I can think of is something like a cipher or protocol.

Edit: to be clear, I want it to be completely clear that we have better tools and arrays are for low-level interop only.

[garyb]

How about... all of the Halogen HTML DSL?

[paf31]

Well that would probably change to use List, and we could still use : or <> to construct lists.

Ideally, [1,2,3] would mean Cons 1 (Cons 2 (Cons 3 Nil))), but I don't think that's an option sadly.

[garyb]

Hmm, I think that would make things pretty annoying:

icon :: forall p i. H.HTML p i
icon = H.div [ A.classes [ B.colXs1, Vc.navIcon ] ]
             [ H.a [ A.href homeHash
                   , A.classes [B.navbarBrand, Vc.logo]
                   ]
                   [ glyph B.glyphiconFolderOpen ]
             ]

Would become something like:

icon :: forall p i. H.HTML p i
icon = H.div ( A.classes (B.colXs1 : Vc.navIcon : Nil) : Nil )
             ( H.a ( A.href homeHash
                   : A.classes (B.navbarBrand : Vc.logo : Nil)
                   : Nil
                   )
                   (glyph B.glyphiconFolderOpen : Nil)
             : Nil
             )

(and I probably made a mistake somewhere in there)

It's already quite laborious to write compared with HTML or virtual-dom/h.

[paf31]

It's not ideal, I agree. But, I can't find a way to reconcile "arrays are low-level, don't use them" with "we have syntactic support for arrays".

In the Halogen case, we could go the blaze-html route:

icon :: forall p i. H.HTML p i
icon = H.div (A.classes (B.colXs1 <> Vc.navIcon))
             (H.a (A.href homeHash
                   <> A.classes (B.navbarBrand <> Vc.logo))
                   (glyph B.glyphiconFolderOpen))

(HTML represents a list of VTree nodes)

[garyb]

Wouldn't removing pattern matching be enough? That would prevent the biggest misuse of them, encouraging use of folds instead.

[paf31]

I think if we remove the type syntax and pattern matching,that should hopefully discourage people from using them. We probably also need a better list implementation in core. Removing array literals is drastic, and reduces expressivity - I just worry that people will continue to abuse arrays.