# News aggregator

### Proposal: Add "fma" to the RealFloat class

This proposal is very much in the spirit of the earlier proposal on adding
new float/double functions; for instance see here:
https://mail.haskell.org/pipermail/libraries/2014-April/022667.html
"fma" (a.k.a. fused-multiply-add) is one of those functions; which is the
workhorse in many HPC applications. The idea is to multiply two floats and
add a third with just one rounding, and thus preserving more precision.
There are a multitude of applications for this operation in engineering
data-analysis, and modern processors come with custom implementations and a
lot of hardware to support it natively.
I created a ticket along these lines already:
https://ghc.haskell.org/trac/ghc/ticket/10364
Edward suggested that the matter should further be discussed here.
I think the proposal is rather straightforward, and should be
noncontroversial. To wit, we shall add a new method to the RealFloat class:
class (RealFrac a, Floating a) => RealFloat a where
...
fma :: a -> a -> a -> a
The intention is that

Categories: Offsite Discussion

### Looking for retainers of PINNED objects

Hi all,
I'm profiling a fairly large program which seems to have a space leak. The
heap profiling (-hc) shows that PINNED objects are accumulated over time.
In order to check the retainers of the objects, I ran the retainer
profiling. Unfortunately it didn't output anything with -hr -hcPINNED.
Also, this is just a guess though, the retainer profiling without any
filters (I mean just -hr) doesn't seem to include PINNED objects at all.
Is there a way to check what retains the PINNED objects?
Thanks,
Mitsutoshi
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Categories: Offsite Discussion

### monad-peel takeover

I'd like to take the maintenance of monad-peel as it's currently broken
and Anders seems unavailable.

Categories: Offsite Discussion

### Maintainship of edit-distance and lattices

Hi,
I’d like to help with maintaining of mentioned packages:
- http://hackage.haskell.org/package/edit-distance <http://hackage.haskell.org/package/edit-distance>
- http://hackage.haskell.org/package/lattices <http://hackage.haskell.org/package/lattices>
Max doesn’t seem to be active on GitHub, there are
- a PR to edit-distance fixing the build on GHC 7.10, open for 26 days: https://github.com/batterseapower/edit-distance/pull/3 <https://github.com/batterseapower/edit-distance/pull/3>
- a PR to lattices opened at Jan 8 2015 (open for over 3 months already) https://github.com/batterseapower/lattices/pull/3 <https://github.com/batterseapower/lattices/pull/3>
I could take over the maintainership of the packages, if Max doesn’t respond in two weeks
- Oleg Grenrus
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### Ord for partially ordered sets

What is the validity of defining an Ord instance for types for which
mathematically the `compare` function is partially ordered?
Specifically, I have a pull request for fgl [1] to add Ord instances
for the graph types (based upon the Ord instances for Data.Map and
Data.IntMap, which I believe are themselves partially ordered), and
I'm torn as to the soundness of adding these instances. It might be
useful in Haskell code (the example given is to use graphs as keys in
a Map) but mathematically-speaking it is not possible to compare two
arbitrary graphs.
What are people's thoughts on this? What's more important: potential
usefulness/practicality or mathematical correctness?
(Of course, the correct answer is to have a function of type a -> a ->
Maybe Ordering :p)
[1]: https://github.com/haskell/fgl/pull/11

Categories: Offsite Discussion

### Export ($!) from Data.Function

Hello,
Right now ($!) operator can be imported either from Prelude or GHC.Base.
The later is specific to GHC, so it makes sense to avoid it.
There are reasons to avoid Prelude too (e.g. because it pollutes name
space, changes too often, etc.) We need a home module for all identifies
from Prelude, so that one can import them without importing Prelude.
Data.Functor seems to be a good candidate for ($!) operator home module.
It already exports ($) operator.
Thanks,
Yuras

Categories: Offsite Discussion

### Applicative instance of ExceptT is wrong

I've recently discovered a flaw in the Applicative and Alternative
instances of EitherT. I've posted the following pull request to fix them:
https://github.com/ekmett/either/pull/38
The pull request contains the description of the problem.
ExceptT of "transformers" contains exactly the same flaw. However it's not
hosted on GitHub, so I don't know a better place to report the issue then
here.
Best regards,
Nikita Volkov
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### Exceptions with Context Re: Proposal: Add exception info

hrm, i like this proposal more, and it seems like with some fleshing out
it can be strictly more extensible yet backwards compatible than michael's
I'll need to mull it a bit more before I cast my vote, but this seems to
sketch out a design that provides the same information, but in a more
extensible/backwards compatible fashion (at least in a first cut of
thinking about it)
(i'm splitting this into a new thread so the discussions dont get mixed up)
On Tue, Apr 21, 2015 at 9:40 PM, davean <davean< at >xkcd.com> wrote:
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### Proposal: add alterLookupWithKey to Data.Map.Lazy (containers)

Github issue: https://github.com/haskell/containers/issues/151
Summary: add alterLookupWithKey :: Ord k => (k -> Maybe a -> Maybe a) -> k
-> Map k a -> (Maybe a, Map k a) function to Data.Map.Lazy.
Details: implement alterLookupWithKey function which takes an update
function, key and map, allowing to insert, delete or update a value in a
Map and return updated map with a new value.
Motivations:
For insert/update/delete: same as for alter :: Ord k => (Maybe a -> Maybe
a) -> k -> Map k a -> Map k a - it allows to perform insert/update/delete
within single lookup.
For returning updated value: same as for *LookupWithKey functions - in case
of update we mind be interested in the updated value.
For a "key" parameter: hornestly, don't know. *LookupWithKey functions are
having (k -> .. ) -> k -> <a> -> Map k a -> (Maybe a, Map k a) signatures,
but I don't see any reason to pass the key to the update function, because
we always can capture the key in a closure if we whant to. The only reason
is to respect exist

Categories: Offsite Discussion

### Data.Tree traversals

Data.Tree makes Tree into a Traversable in only one way: depth-first. It
seems to me that we should have a newtype to traverse in breadth-first
order.
David Feuer
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### Proposal: liftData for Template Haskell

I propose adding the following function to Language.Haskell.TH:
-- | 'liftData' is a variant of 'lift' in the 'Lift' type class which
-- works for any type with a 'Data' instance.
liftData :: Data a => a -> Q Exp
liftData = dataToExpQ (const Nothing)
I don't really know which submodule this should come from;
since it uses 'dataToExpQ', you might put it in Language.Haskell.TH.Quote
but arguably 'dataToExpQ' doesn't belong in this module either,
and it only lives there because it is a useful function for defining
quasiquoters and it was described in the quasiquoting paper.
I might propose getting rid of the 'Lift' class entirely, but you
might prefer that class since it doesn't go through SYB (and have
the attendant slowdown).
This mode of use of 'dataToExpQ' deserves more attention.
Discussion period: 1 month
Cheers,
Edward

Categories: Offsite Discussion

### bed & breakfast library update?

I've asked a couple of times over the last eight moths for an update of
this library that would compile on 7.8 to be published, and gotten no
response.
If you're not able or interested in maintaining this library any longer,
please let the community know so that someone else can take over those
duties.
If you can't or don't respond, I'll have to assume you're no longer able
to, and see about getting another maintainer.
Thank you,
Mike
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### Floating and Data.Fixed

Hello libraries list,
(Warning: this whole message may be a waste of time, you may wish to skip
it.)
I'd like to inquire about the possibility of a Floating instance for
Data.Fixed. (Unfortunately, not knowing of the existence of this list or
the appropriate procedure, I created a trac ticket to ask about this,
because that was the only forum I knew of. It's
https://ghc.haskell.org/trac/ghc/ticket/10297. Sorry.)
The original idea was along these lines:
lift :: (HasResolution a) => (Double -> Double) -> Fixed a -> Fixed a
lift f = realToFrac . f . realToFrac
instance (HasResolution a) => Floating (Fixed a) where
pi = realToFrac pi
sin = lift sin
-- etc, similar lift2 function for (**), logBase
This allows the use of transcendental functions on Fixed values.
Conceptually, transcendental functions on fixed point values aren't
problematic, and are actually pretty widely used in certain
gaming/simulation/signal processing applications.
I've since learned that this may not be a good idea. A commenter

Categories: Offsite Discussion

### Proposal: Add exception info

Control.Exception currently lacks a good way to supply extra
information along with exceptions. For example, exceptions could be
thrown along with their callstack[1] or implicit stack[2], but we have
no generic way to include this information with exceptions.
Proposed Solution
=================
The proposed solution is to add a list of `SomeExceptionInfo` to the
`SomeException` datatype. This list stores additional information
about the exception. These `ExceptionInfo` instances use a mechanism
which is pretty much identical to the dynamic way the `Exception` type
works:
data SomeException = forall e . Exception e =>
SomeExceptionWithInfo e [SomeExceptionInfo]
data SomeExceptionInfo = forall a . ExceptionInfo a =>
SomeExceptionInfo a
class Typeable a => ExceptionInfo a where
displayExceptionInfo :: a -> String
addExceptionInfo
:: (ExceptionInfo a, Exception e)
=> a -> e -> SomeException
addExceptionInfo x (toException -> SomeExceptionWithIn

Categories: Offsite Discussion

### Bed & Breakfast maintainer?

Anyone out there maintaining (or willing to take over) the
bed-and-breakfast package?
0.4.3 (the latest release) doesn't compile with 7.8 because of the changes
to Typeable. The git repo has fixes for this in it, along with some other
stuff, but that's nearly a year old, and hasn't been released yet.
My requests to the author & maintainer (Julian Fleischer <
julian.fleischer< at >fu-berlin.de>) have gone unanswered.
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Categories: Offsite Discussion

### SIMD

What’s the story with this? I tried to follow the instructions here: https://ghc.haskell.org/trac/ghc/wiki/SIMD <https://ghc.haskell.org/trac/ghc/wiki/SIMD> but I get
Dominic Steinitz
dominic< at >steinitz.org
http://idontgetoutmuch.wordpress.com
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users< at >haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Categories: Offsite Discussion

### New gtk2hs 0.12.4 release

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News