Proposal: (◇) alias for (<>)

[unclechu]

I personally always define this for myself:

(◇) ∷ Semigroup α ⇒ α → α → α
(◇) = (<>)
{-# INLINE (◇) #-}
infixr 6 ◇

What do you think about to include it to this package? There are two such symbols which look pretty similar: (◇) and (⋄). You could add both:

(◇) ∷ Semigroup α ⇒ α → α → α
(◇) = (<>)
{-# INLINE (◇) #-}
infixr 6 ◇

(⋄) ∷ Semigroup α ⇒ α → α → α
(⋄) = (<>)
{-# INLINE (⋄) #-}
infixr 6 ⋄

But I prefer first one since second one is pretty similar to (∘) because it's too small.

[unclechu]

If you decide to add it I think it should be in Prelude.Unicode since nowadays Semigroup's (<>) is provided by Prelude.

[subttle]

⋄ is described as 'DIAMOND OPERATOR' (U+22C4) ◇ is described as 'WHITE DIAMOND' (U+25C7) My current preference is for ⋄ because the symbol is specifically designated as an operator.

[Anton-Latukha]

For info.

In unicode-prelude <> was ⊗.

Well, because <> is really a "tensor product": https://ncatlab.org/nlab/show/tensor+product

Not to throw a wrench into the discussion. But I kinda do on the face of it.

I am OK for any decision personally, ⋄ seems also a good symbol for this, and in theory ⋄ is often the most generalized notation for the operation, I also can imagine <> be ◇ because it is the most basic operation.

[kindaro]

Perhaps instead the symbol ⊕, currently standing for mappend, can be re-assigned?

[roelvandijk]

I think there are two parts to this.

1. A nice unicode alternative for Semigroup's <>
2. Relation between Semigroup's <> and Monoid's mappend

Regarding 1, I try not to invent novel symbols but stick to symbols that are already in use for the same concept. The diamond operator ⋄ definitely meets this requirement because it is just a nicer way of writing the shape made by <>. I slightly prefer ⋄ over ◇ for the reasons given by @subttle.

Regarding 2, the haddock documentation for mappend is relevant:

NOTE: This method is redundant and has the default implementation mappend = (<>) since base-4.11.0.0. Should it be implemented manually, since mappend is a synonym for (<>), it is expected that the two functions are defined the same way. In a future GHC release mappend will be removed from Monoid.

So I'm ok with adding ⋄ for <>. The question (hinted at by @kindaro) is what to do with ⊕? Do we only keep it as mappend? (which since base-4.11.0.0 should be equal to <>). This would mean ⊕ will disappear once mappend is removed from a future release of base.

We can also choose to reassign ⊕ to be <> once base decides to drop mappend. That should give the least amount of headache to users of this library.

[Anton-Latukha]

Tensor product: ⊗ (Ox). It is for a monoidal category, and Hask is monoidal in algebraic types (monoidal both in product (product types) and coproduct (sum types) (there is no other types in function signatures I know of, (meaning there are none without essentially hacking the Haskell type system)). In Haskell ⊗ even can be simplified, for literally stating only Semigroup requirement we can drop Monoidal requirement, so ⊗ without monoidal requirement becomes "product" ⨯ (0x2a2f) symbol name: "Vector or cross product", × (0xd7) symbol name: "Multiplication sign". Since in Haskell the product type operation itself is ` - for<>the⨯can be used without any disambiguations in notation or understanding. Since coproduct (sum type) is also a product, so they all are product (⨯`) operations.

In other words, Haskellers in programming use <> to combine the same structures intuitively without even thinking about that all those structures are always algebraic, and also monoidal, so what they tell Haskell to do - is ⊗ them, they say to the Haskell to combine the parts and produce (⨯) the result, that view and understanding would aling them to the theory, so when people see ⨯ in theory - they already see it as <>.

---

Basically, the project needs to prefer one of the two (or sit on both stools by supporting and developing two different modes).

• scientific notation.
• intuitive meaning replication notation.

That should be explicitly put, in that way you solve the scientific and practical programmers holly war in the threads about the notation. But if the scientific approach was chosen - the deep discussions and some terms and notation holly warring and refactoring inside it are inevitable and embraced.

In any case - I am happy that the project standardizes notation more, more hammering away at standardization is better. In any way doing this - it is better than no discussion on standardization.

[danwdart]

Now that mappend = <> by definition, maybe this can be easier.