Thinking aloud, I dónt know if the transition to more abstract type
signatures can be aleviated using language directives.
Someting like:
Restrict (++) String - String - String
that locally would restrict the type within the module.
Althoug it does not avoid breaking the old code, It permits
On 4 May 2012, at 10:02, Alberto G. Corona wrote:
Restrict (++) String - String - String
that locally would restrict the type within the module.
import qualified Prelude
import Prelude hiding ((++))
(++) :: String - String - String
(++) = Prelude.(++)
Fine ;)
So the transition should not be so problematic. An OldPrelude.hs may
be created easily with this.
Once again, thinking aloud.
2012/5/4 Malcolm Wallace malcolm.wall...@me.com:
On 4 May 2012, at 10:02, Alberto G. Corona wrote:
Restrict (++) String - String - String
that locally
In the context of string-like types ++ seems quite sensible because
the Monoid instances concat the strings.
However, not all Monoid instances imply concatenation. A Monoid
instance might provide choice. For example, we could define a parser,
module Main where
import Data.Monoid
newtype
See the relevant trac ticket [1] and the linked mailing list thread.
Erik
[1] http://hackage.haskell.org/trac/ghc/ticket/3339
On Sun, Apr 1, 2012 at 22:58, aditya bhargava bluemangrou...@gmail.com wrote:
After asking this question:
Plus one might argue that using to mean different is a bad choice, as it
graphically means strictly inferior or strictly superior which implies
comparability, whereas equality and comparison are two different things.
(e.g. Eq and Ord are two distinct classes in Haskell).
Le 1 avril 2012 23:06,
It is somewhat idiomatic to read it as TeX's \diamond symbol. Various
papers set with Lhs2TeX use it for general composition operator
(sometimes concat / mappend).
On 2 April 2012 10:05, Yves Parès yves.pa...@gmail.com wrote:
Plus one might argue that using to mean different is a bad choice, as
After asking this question:
http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend
I found out that the new infix operator for `mappend` is (). I'm
wondering why ghc 7.4 didn't generalize (++) to work on monoids instead. To
me, (++) is much more clear.
There are many reasons, but some of the more cited ones are that () will
break less code than (++) would, since (++) is ubiquitous and () is most
used in some pretty printers. Yes, mappend's type can be refined to that of
the current list (++), but the increased polymorphism still has the
On Sun, Apr 1, 2012 at 1:58 PM, aditya bhargava
bluemangrou...@gmail.com wrote:
After asking this question:
http://stackoverflow.com/questions/9963050/standard-way-of-joining-two-data-texts-without-mappend
I found out that the new infix operator for `mappend` is (). I'm wondering
why ghc 7.4
10 matches
Mail list logo