My prosaic solution would be to have more stock implementations of mconcat
(here balancedMconcat, though some parallelMconcat's would also be fun) that
make use of the associativity guarantee. Then use that explicitly:--
balancedMconcat . fmap Sum $ [a, b, c, 2, 3, d]
rather than asking the comp
Oops, I mixed up associative with commutative.
On Tue, Sep 14, 2010 at 1:27 PM, Bas van Dijk wrote:
> On Mon, Sep 13, 2010 at 4:23 PM, Nick Bowler wrote:
>> ... not all Num instances have an associative (+).
>
> Indeed:
>
> $ cabal install repr # [1]
> ...
> $ ghci
> Prelude> :m Text.Repr
> P
On Mon, Sep 13, 2010 at 4:23 PM, Nick Bowler wrote:
> ... not all Num instances have an associative (+).
Indeed:
$ cabal install repr# [1]
...
$ ghci
Prelude> :m Text.Repr
Prelude Text.Repr> show (1 + 2 :: Repr Int) == show (2 + 1 :: Repr Int)
False
because:
show (1 + 2 :: Repr Int) == "1 +
In message ,
"S. Doaitse Swierstra" writes:
>Currently Haskell has infix, infixl and infixr operators. I see a use for infi
>xlr as well. This indicates that the implemtation may assume the operator to b
>e associative, and thus has the freedom to "balance" an expression containing
>several opera
On 2010-09-10 19:13 +0100, Ian Lynagh wrote:
> When first reading the proposal, I thought the idea was to allow the
> compiler to more easily perform optimisations like
> a+b+c+2+3+d => a+b+c+5+d
Of course, since I don't think fixity can be specified per-instance of
Num, one would not be able
I don't think a syntactic property (how operators are parsed) should
be mixed up with a semantic property (being associative).
At least not in Haskell.
On Fri, Sep 10, 2010 at 7:51 PM, S. Doaitse Swierstra wrote:
>
> Currently Haskell has infix, infixl and infixr operators. I see a use for
> inf
On Fri, Sep 10, 2010 at 11:14:53PM +0200, S. Doaitse Swierstra wrote:
>
> On 10 sep 2010, at 20:13, Ian Lynagh wrote:
>
> > On Fri, Sep 10, 2010 at 07:51:10PM +0200, S. Doaitse Swierstra wrote:
> >>
> >> Currently Haskell has infix, infixl and infixr operators. I see a use for
> >> infixlr as w
Am Freitag, den 10.09.2010, 23:18 +0200 schrieb S. Doaitse Swierstra:
> On 10 sep 2010, at 20:13, Ian Lynagh wrote:
> > How would the compiler work out which parsing to prefer? Or would it
> > assume that infixlr expressions are best balanced?
>
> Yes, that is the idea.
To me, it seems weird that
On 10 sep 2010, at 20:13, Ian Lynagh wrote:
> On Fri, Sep 10, 2010 at 07:51:10PM +0200, S. Doaitse Swierstra wrote:
>>
>> Currently Haskell has infix, infixl and infixr operators. I see a use for
>> infixlr as well. This indicates that the implemtation may assume the
>> operator to be associat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/10/10 14:13 , Ian Lynagh wrote:
> When first reading the proposal, I thought the idea was to allow the
> compiler to more easily perform optimisations like
> a+b+c+2+3+d => a+b+c+5+d
> but I guess that wasn't something you were thinking about?
On Fri, Sep 10, 2010 at 07:51:10PM +0200, S. Doaitse Swierstra wrote:
>
> Currently Haskell has infix, infixl and infixr operators. I see a use for
> infixlr as well. This indicates that the implemtation may assume the operator
> to be associative, and thus has the freedom to "balance" an expres
Currently Haskell has infix, infixl and infixr operators. I see a use for
infixlr as well. This indicates that the implemtation may assume the operator
to be associative, and thus has the freedom to "balance" an expression
containing several operator occurrences.
The reason that I bring up thi
12 matches
Mail list logo
