<div dir="ltr">Yep, it is just hard coded, but to be fair there have been very few new Accelerate backends. It does pull in extra dependencies though, if you forget to add the appropriate `-f-X` flag.<div><br></div><div>The type class approach you mention sounds like how the LLVM-based packages are architected.</div><div><br></div><div>-Trev</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 31 Mar 2017 at 20:46 Henning Thielemann <<a href="mailto:googlegroups@henning-thielemann.de">googlegroups@henning-thielemann.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
On Fri, 31 Mar 2017, Trevor McDonell wrote:<br class="gmail_msg">
<br class="gmail_msg">
>   * accelerate-fft: FFI bindings to discrete Fourier transforms (FFTW and cuFFT)<br class="gmail_msg">
>     (<a href="https://hackage.haskell.org/package/accelerate-fft" rel="noreferrer" class="gmail_msg" target="_blank">https://hackage.haskell.org/package/accelerate-fft</a>)<br class="gmail_msg">
<br class="gmail_msg">
I was curious how you solved the problem of addressing target specific<br class="gmail_msg">
implementations of functions like the FFT. Looking at the source code it<br class="gmail_msg">
looks like you have hard-coded a selection of back-ends. I hoped that we<br class="gmail_msg">
would be able to specify back-end capabilities via a type-class. This way<br class="gmail_msg">
the user could add more back-ends with their respective FFT<br class="gmail_msg">
implementations. Maybe that's stuff to be defered to Accelerate-2.0. :-)</blockquote></div>