#5744: List layouts
---------------------------------+------------------------------------------
Reporter: nsch | Owner: nsch
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.2.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by nsch):
Does the performance between
{{{
mconcat [a,b,..]
}}}
and
{{{
a `mappend` (b `mappend` ..)
}}}
actually differ much in performance (at all?) if `mconcat` is `foldr
mappend mempty`? GHC should (is? out of the box? with use of some
pragmas?) be able to get the same performance out of both versions,
shouldn't it? I'm not familiar enough with the whole optimization
process/benchmarking GHC to tell for sure…
The big problem I have with using monoids/semigroups for this layout is
that it seems to be such a specialization already of general (yes,
general) lists. After all, the reason why I like the `be` keyword so much
is that lists literally don't do ''anything'' but concatenating one
statement to the other. Monoids already do a lot more (combining all
values). And then there's this question about left/right associativity,
where I totally agree with simonmar - this shouldn't be a "built-in bias".
Using lists for the `be` layout would offer a simple solution to this:
define your own specialized version of `mconcat` and apply it to the
`be`-list before using your monoid. After all, the `mconcat` function
already '''generalizes all lists to monoids''' if the monoid instance of
the list elements is given! Furthermore, my initial list-example doesn't
work anymore with a monoid/semigroup layout as `mappend` for lists is
`(++)` and not `(:)` (which wouldn't match the `a -> a -> a` type of
`mappend`) and you would get something like
{{{
Couldn't match expected type `[Bool]' with actual type `Bool'
In the expression: True
In a stmt of a semigroup layout block: True
In the expression:
be { True;
False }
}}}
if the resulting type should be a simple list (here: of boolean values)
instead of a custom monoid that would do exactly the same.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5744#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
