#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):
Replying to [comment:10 ehird]:
> As far as desugaring goes, I would suggest that it reorder the
expressions (including flattening nested `mdo`s) to be right-associative,
and to avoid `mappend`ing things with `mempty`, e.g.
Actually, this extension would never ever (!) use `mempty`, which is why
some have argued that `Monoid` may not exactly be the correct type class
for this. A `Semigroup` typeclass might be more appropriate:
{{{
class Semigroup a where
gappend :: a -> a -> a
}}}
Which should satisfy associativity:
{{{
(a `gappend` b) `gappend` c = a `gappend` (b `gappend` c)
}}}
The `Semigroup` instance for monoids is trivial.
> `mdo { } ≡ mempty`
I think this should return a "Empty 'mdo' block" error, just as `do` does.
Simply for consistency and to avoid that 'mdo' (or 'be' or whatever
keyword will be used) will be used as synonym for `mempty`. Again, the use
of semigroups would offer an obvious solution to this question.
> `mdo { a } ≡ a`
This is obvious.
> `mdo { mdo { as... }; bs... } ≡ mdo { as...; bs... }`
This would translate to:
{{{
=> mdo { as ... } `mappend` bs `mappend` ...
=> (as `mappend` ..) `mappend` bs `mappend` ...
}}}
Because of associativity this is equivalent to what you suggested.
> `mdo { a; as... } ≡ a `mappend` mdo { as... }`
Again, this is the obvious translation rule.
And by the way, `mdo` is already a reserved key word.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5744#comment:11>
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
