<p dir="ltr">There is a CPU being design with an interesting architecture. Take a look at the Mill CPU at <a href="http://millcomputing.com">millcomputing.com</a>.</p>
<p dir="ltr">A facsinating feature is the use of a belt of values vs registers. The values on the belt are immutable and fall off (~auto gc'd?) unless expressly saved or returned.</p>
<p dir="ltr">It is also desined to make function calls very cheap. </p>
<p dir="ltr">tomberek</p>
<div class="gmail_quote">On Jan 20, 2016 3:49 AM, <<a href="mailto:haskell-cafe-request@haskell.org">haskell-cafe-request@haskell.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Haskell-Cafe mailing list submissions to<br>
<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:haskell-cafe-request@haskell.org">haskell-cafe-request@haskell.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:haskell-cafe-owner@haskell.org">haskell-cafe-owner@haskell.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Haskell-Cafe digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Doc generation? (Patrick Redmond)<br>
2. Re: Doc generation? (Mark Fine)<br>
3. Host-Oriented Template Haskell (Ericson, John)<br>
4. [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking (Daniel Gr?ber)<br>
5. CPU with Haskell support (Henning Thielemann)<br>
6. Re: Doc generation? (Noon Silk)<br>
7. Re: Doc generation? (Mikhail Glushenkov)<br>
8. Re: CPU with Haskell support (Auke Booij)<br>
9. Re: CPU with Haskell support (Darren Grant)<br>
10. Re: CPU with Haskell support (Henning Thielemann)<br>
11. Re: CPU with Haskell support (Ben Lippmeier)<br>
12. Re: CPU with Haskell support (Richard A. O'Keefe)<br>
13. Re: CPU with Haskell support (Gleb Popov)<br>
14. Re: Doc generation? (Sven Panne)<br>
15. Re: Doc generation? (Mikhail Glushenkov)<br>
16. Re: CPU with Haskell support (Joachim Durchholz)<br>
17. Re: Doc generation? (Sven Panne)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 19 Jan 2016 08:39:20 -0800<br>
From: Patrick Redmond <<a href="mailto:plredmond@gmail.com">plredmond@gmail.com</a>><br>
To: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CAHUea4Ht0p8=HwphL+--V7j3Xftt=<a href="mailto:8drrZDuOQtcB38rPPkJ2w@mail.gmail.com">8drrZDuOQtcB38rPPkJ2w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I don't know what's happening with hackage, but if you're using stack in<br>
your workflow a simple workaround is to build docs locally and search them<br>
with a shell script. For example:<br>
<br>
$ stack haddock async<br>
<br>
And then muck around in .stack-work or ~/.stack. I've written a<br>
bash/fish script to do the search for you here:<br>
<a href="http://plredmond.github.io/posts/search-haddocks-offline.html" rel="noreferrer" target="_blank">plredmond.github.io/posts/search-haddocks-offline.html</a><br>
<br>
On Tuesday, January 19, 2016, Francesco Ariis <<a href="mailto:fa-ml@ariis.it">fa-ml@ariis.it</a>> wrote:<br>
<br>
> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:<br>
> > Does anyone know what is happening here?<br>
> ><br>
> > Not a single one of the packages on<br>
> > <a href="http://hackage.haskell.org/packages/recent" rel="noreferrer" target="_blank">http://hackage.haskell.org/packages/recent</a> has docs generated at the<br>
> moment.<br>
> ><br>
> > Some older ones, upload this year, also do not -<br>
> > <a href="http://hackage.haskell.org/package/pipes-concurrency" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/pipes-concurrency</a><br>
><br>
> Docs not being built can be quite frustrating; for those dark times I<br>
> build them locally:<br>
><br>
> <a href="http://ariis.it/static/articles/no-docs-hackage/page.html" rel="noreferrer" target="_blank">http://ariis.it/static/articles/no-docs-hackage/page.html</a><br>
><br>
> Living with a flaky WiFi, saves me from screaming at the monitor quite<br>
> some times.<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a> <javascript:;><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/517bfc2f/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/517bfc2f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 19 Jan 2016 09:51:40 -0800<br>
From: Mark Fine <<a href="mailto:mark.fine@gmail.com">mark.fine@gmail.com</a>><br>
To: Patrick Redmond <<a href="mailto:plredmond@gmail.com">plredmond@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<<a href="mailto:CANRZ_fkC4-wM8-UyzeQEFJiiUZ02qo22CHdhfUt68wQeaRX8UA@mail.gmail.com">CANRZ_fkC4-wM8-UyzeQEFJiiUZ02qo22CHdhfUt68wQeaRX8UA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Also, if the packages are on stackage, you can look at the documentation<br>
there:<br>
<br>
<a href="https://www.stackage.org/package/pipes-concurrency" rel="noreferrer" target="_blank">https://www.stackage.org/package/pipes-concurrency</a><br>
<br>
Mark<br>
<br>
On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <<a href="mailto:plredmond@gmail.com">plredmond@gmail.com</a>><br>
wrote:<br>
<br>
> I don't know what's happening with hackage, but if you're using stack in<br>
> your workflow a simple workaround is to build docs locally and search them<br>
> with a shell script. For example:<br>
><br>
> $ stack haddock async<br>
><br>
> And then muck around in .stack-work or ~/.stack. I've written a<br>
> bash/fish script to do the search for you here:<br>
> <a href="http://plredmond.github.io/posts/search-haddocks-offline.html" rel="noreferrer" target="_blank">plredmond.github.io/posts/search-haddocks-offline.html</a><br>
><br>
> On Tuesday, January 19, 2016, Francesco Ariis <<a href="mailto:fa-ml@ariis.it">fa-ml@ariis.it</a>> wrote:<br>
><br>
>> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:<br>
>> > Does anyone know what is happening here?<br>
>> ><br>
>> > Not a single one of the packages on<br>
>> > <a href="http://hackage.haskell.org/packages/recent" rel="noreferrer" target="_blank">http://hackage.haskell.org/packages/recent</a> has docs generated at the<br>
>> moment.<br>
>> ><br>
>> > Some older ones, upload this year, also do not -<br>
>> > <a href="http://hackage.haskell.org/package/pipes-concurrency" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/pipes-concurrency</a><br>
>><br>
>> Docs not being built can be quite frustrating; for those dark times I<br>
>> build them locally:<br>
>><br>
>> <a href="http://ariis.it/static/articles/no-docs-hackage/page.html" rel="noreferrer" target="_blank">http://ariis.it/static/articles/no-docs-hackage/page.html</a><br>
>><br>
>> Living with a flaky WiFi, saves me from screaming at the monitor quite<br>
>> some times.<br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/c6010b86/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/c6010b86/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 19 Jan 2016 13:17:02 -0800<br>
From: "Ericson, John" <<a href="mailto:john_ericson@brown.edu">john_ericson@brown.edu</a>><br>
To: Haskell-Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: [Haskell-cafe] Host-Oriented Template Haskell<br>
Message-ID:<br>
<<a href="mailto:CA%2BVhx4TF0x5-XrKi09A36xVww2HyWr0J3QysqJYdJbKDU3dhDw@mail.gmail.com">CA+Vhx4TF0x5-XrKi09A36xVww2HyWr0J3QysqJYdJbKDU3dhDw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
As is well known, TH and cross-compiling do not get along. There are<br>
various proposals on how to make this interaction less annoying, and I<br>
am not against them. But as I see it, the problem is largely inherent<br>
to the design of TH itself: since values can (usually) be lifted from<br>
compile-time to run-time, and normal definitions from upstream modules<br>
to downstream modules' TH, TH and normal code must "live in the same<br>
world".<br>
<br>
Now this restriction in turn bequeaths TH with much expressive power,<br>
and I wouldn't advocate getting rid of it. But many tasks do not need<br>
it, and in some cases, say in bootstrapping compilers[1] themselves,<br>
it is impossible to use TH because of it, even were all the current<br>
proposals implemented.<br>
<br>
For these reason, I propose a new TH variant which has much harsher<br>
phase separation. Normal definitions from upstream modules can not be<br>
used, lifting values is either not permitted or is allowed to fail<br>
(because of missing/incompatible definitions), and IO is defined to<br>
match the behavior of the host, not target, platform (in the cross<br>
compiling case). The only interaction between the two phases is that<br>
quoted syntax is resolved against the the run-time phase's definitions<br>
(just like today).<br>
<br>
Some of you may find this a shoddy substitute for defining a subset of<br>
Haskell which behaves identically on all platforms, and optionally<br>
constraining TH to it. But the big feature that my proposal offers and<br>
that one doesn't is to be able to independently specify compile-time<br>
dependencies for the host-oriented TH---this is analogous to the<br>
newish `Setup.hs` dependencies. That in turns leads to what I think is<br>
the "killer app" for Host-Oriented TH: exposing the various<br>
prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,<br>
and side-stepping any need for "executable dependencies" in Cabal.<br>
Note also that at least hsc2hs additionally requires host-IO---there<br>
may not even exist a C compiler on the target platform at all.<br>
<br>
Finally, forgive me if this has been brought up before. I've been<br>
thinking about this a while, and did a final pass over the GHC wiki to<br>
make sure it wasn't already proposed, but I could have missed<br>
something (this is also my first post to the list).<br>
<br>
John<br>
<br>
[1]: <a href="https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs" rel="noreferrer" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 19 Jan 2016 22:19:48 +0100<br>
From: Daniel Gr?ber <<a href="mailto:dxld@darkboxed.org">dxld@darkboxed.org</a>><br>
To: <a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
Subject: [Haskell-cafe] [ANN] ghc-mod-5.5.0.0: Happy Haskell Hacking<br>
Message-ID: <20160119211948.GA16744@grml><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I'm pleased to announce the release of ghc-mod 5.5.0.0!<br>
<br>
This is primarily a maintenance and bug fix release. We are releasing this as a<br>
major version bump as we are following a policy of not trying to keep API<br>
compatibility until v6.0 to enable us to clean up ghc-mod's internals and API.<br>
<br>
What's new?<br>
===========<br>
<br>
* Cabal flags are now preserved across automatic reconfigurations<br>
<br>
When ghc-mod detects something influencing the cabal configuration has changed<br>
since the last invocation it will automatically reconfigure the<br>
project. Previously this would call 'cabal configure' without any additional<br>
options thus possibly reverting flags the user might have added to the<br>
configure command previously. Now we extract the current set of flags from the<br>
existing configuration and pass the appropriate options to the configure<br>
command.<br>
<br>
* Rewritten command-line parser (again)<br>
<br>
The home grown sub-command parser based on getopt has been a user experience<br>
disaster so we've replaced it using a new optparse-applicative based parser.<br>
This does have the unfortunate side effect that we had to remove support for<br>
some optional arguments we had supported previously thus breaking<br>
compatibility with very old frontends.<br>
<br>
* Remove CWD requirement from command-line tools<br>
<br>
In v5.4.0.0 we had to add a workaround for a nasty race condition in 'ghc-mod<br>
legacy-interactive' (ghc-modi) which added a requirement that all ghc-mod<br>
command line tools are run in the root of each project's directory. This<br>
limitation has now been removed. Frontends which have implemented this<br>
workaround should be compatible going forward but for performance reasons it<br>
is advisable to disable the workaround for versions after v5.5.0.0.<br>
<br>
* Various bug fixes and smaller improvements<br>
<br>
From the change log:<br>
* Fix cabal-helper errors when no global GHC is installed (Stack)<br>
* Support for spaces in file names when using legacy-interactive<br>
* Fix "No instance nor default method for class operation put"<br>
* Fix a variety of caching related issues<br>
* Emacs: Fix slowdown and bugs caused by excessive use of `map-file`<br>
* Emacs: Add ghc-report-errors to inhibit *GHC Error* logging<br>
<br>
<br>
What is ghc-mod?<br>
================<br>
<br>
ghc-mod is both a back-end program for enhancing editors and other kinds of<br>
development environments with support for Haskell and a library for abstracting<br>
the black magic incantations required to use the GHC API in various<br>
environments, especially Cabal and Stack projects. The library is used by<br>
ambitious projects like HaRe[1], mote[2] and haskell-ide-engine[3]<br>
<br>
<br>
Getting ghc-mod<br>
===============<br>
<br>
GitHub: <a href="https://github.com/DanielG/ghc-mod" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod</a><br>
Hackage: <a href="http://hackage.haskell.org/package/ghc-mod" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/ghc-mod</a><br>
<br>
Editor frontends:<br>
<br>
- Emacs (native):<br>
<a href="https://github.com/DanielG/ghc-mod" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod</a><br>
<a href="https://github.com/iquiw/company-ghc" rel="noreferrer" target="_blank">https://github.com/iquiw/company-ghc</a><br>
- Vim:<br>
<a href="https://github.com/eagletmt/ghcmod-vim" rel="noreferrer" target="_blank">https://github.com/eagletmt/ghcmod-vim</a><br>
<a href="https://github.com/eagletmt/neco-ghc" rel="noreferrer" target="_blank">https://github.com/eagletmt/neco-ghc</a><br>
- Atom:<br>
<a href="https://github.com/atom-haskell/ide-haskell" rel="noreferrer" target="_blank">https://github.com/atom-haskell/ide-haskell</a><br>
<br>
Known issues<br>
============<br>
<br>
For issues other than the ones mentioned below visit our issue tracker:<br>
<br>
<a href="https://github.com/DanielG/ghc-mod/issues" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod/issues</a><br>
<br>
Frequently reported issues<br>
--------------------------<br>
<br>
ghc-mod once compiled is bound to one version of GHC since we link against the<br>
GHC API library. This used to not be a very big problem but since Stack made it<br>
exceedingly easy for users to use more than one version of GHC without even<br>
knowing the number of problems in this area has exploded. We are tracing the<br>
issue in the following issue: <a href="https://github.com/DanielG/ghc-mod/issues/615" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod/issues/615</a><br>
(Support switching GHC versions without recompiling ghc-mod)<br>
<br>
ghc-mod's `case`, `sig` and `refine` commands still do not work properly with<br>
GHC>7.10 (See <a href="https://github.com/DanielG/ghc-mod/issues/438" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod/issues/438</a>). Unless<br>
someone volunteers to fix this issue I will work towards replacing the features<br>
using mote[2] instead as the current code is, from my point of view,<br>
unmaintainable.<br>
<br>
If you do notice any other problems please report them:<br>
<br>
<a href="https://github.com/DanielG/ghc-mod/issues/new" rel="noreferrer" target="_blank">https://github.com/DanielG/ghc-mod/issues/new</a><br>
<br>
----<br>
[1]: <a href="https://github.com/alanz/HaRe" rel="noreferrer" target="_blank">https://github.com/alanz/HaRe</a><br>
[2]: <a href="https://github.com/imeckler/mote" rel="noreferrer" target="_blank">https://github.com/imeckler/mote</a><br>
[3]: <a href="https://github.com/haskell/haskell-ide-engine" rel="noreferrer" target="_blank">https://github.com/haskell/haskell-ide-engine</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/9fea4144/attachment-0001.sig" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/9fea4144/attachment-0001.sig</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 19 Jan 2016 23:12:02 +0100 (CET)<br>
From: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
To: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: [Haskell-cafe] CPU with Haskell support<br>
Message-ID: <alpine.DEB.2.02.1601192250000.16459@sputnik><br>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII<br>
<br>
<br>
Hi all,<br>
<br>
every now and then I think it would be cool to have a microprocessor that<br>
supports Haskell in a way. A processor where lazy evaluation is not<br>
overhead but an optimization opportunity, a processor that can make use of<br>
the explicit data dependencies in Haskell programs in order to utilize<br>
many computation units in parallel. I know of the Reduceron project, which<br>
evolves only slowly and if it somewhen is ready for use it is uncertain<br>
whether it can compete with stock CPUs since FPGA's need much more chip<br>
space for the same logic.<br>
<br>
I got to know that in todays x86 processors you can alter the instruction<br>
set, which is mainly used for bugfixes. Wouldn't it be interesting to add<br>
some instructions for Haskell support? However, I suspect that such a<br>
patch might be rendered invalid by new processor generations with changed<br>
internal details. Fortunately, there are processors that are designed for<br>
custom instruction set extensions:<br>
<a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
<br>
Would it be sensible to create a processor based on such a design? I have<br>
no idea what it might cost, and you would still need some peripheral<br>
circuitry to run it. What could processor instructions for Haskell support<br>
look like? Has anyone already thought in this direction?<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 20 Jan 2016 09:37:26 +1100<br>
From: Noon Silk <<a href="mailto:noonslists@gmail.com">noonslists@gmail.com</a>><br>
To: Mark Fine <<a href="mailto:mark.fine@gmail.com">mark.fine@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CADt_azZv_w+nFgQiOrRVGucKV7Wf4h-Y7YjVfO=<a href="mailto:pMc_QqhFjXw@mail.gmail.com">pMc_QqhFjXw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Mark and All,<br>
<br>
Indeed, I've been generating the docs myself offline; I didn't know about<br>
looking for the docs on stackage; thanks!<br>
<br>
--<br>
Noon<br>
<br>
On Wed, Jan 20, 2016 at 4:51 AM, Mark Fine <<a href="mailto:mark.fine@gmail.com">mark.fine@gmail.com</a>> wrote:<br>
<br>
> Also, if the packages are on stackage, you can look at the documentation<br>
> there:<br>
><br>
> <a href="https://www.stackage.org/package/pipes-concurrency" rel="noreferrer" target="_blank">https://www.stackage.org/package/pipes-concurrency</a><br>
><br>
> Mark<br>
><br>
> On Tue, Jan 19, 2016 at 8:39 AM, Patrick Redmond <<a href="mailto:plredmond@gmail.com">plredmond@gmail.com</a>><br>
> wrote:<br>
><br>
>> I don't know what's happening with hackage, but if you're using stack in<br>
>> your workflow a simple workaround is to build docs locally and search them<br>
>> with a shell script. For example:<br>
>><br>
>> $ stack haddock async<br>
>><br>
>> And then muck around in .stack-work or ~/.stack. I've written a<br>
>> bash/fish script to do the search for you here:<br>
>> <a href="http://plredmond.github.io/posts/search-haddocks-offline.html" rel="noreferrer" target="_blank">plredmond.github.io/posts/search-haddocks-offline.html</a><br>
>><br>
>> On Tuesday, January 19, 2016, Francesco Ariis <<a href="mailto:fa-ml@ariis.it">fa-ml@ariis.it</a>> wrote:<br>
>><br>
>>> On Tue, Jan 19, 2016 at 04:24:24PM +1100, Noon Silk wrote:<br>
>>> > Does anyone know what is happening here?<br>
>>> ><br>
>>> > Not a single one of the packages on<br>
>>> > <a href="http://hackage.haskell.org/packages/recent" rel="noreferrer" target="_blank">http://hackage.haskell.org/packages/recent</a> has docs generated at the<br>
>>> moment.<br>
>>> ><br>
>>> > Some older ones, upload this year, also do not -<br>
>>> > <a href="http://hackage.haskell.org/package/pipes-concurrency" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/pipes-concurrency</a><br>
>>><br>
>>> Docs not being built can be quite frustrating; for those dark times I<br>
>>> build them locally:<br>
>>><br>
>>> <a href="http://ariis.it/static/articles/no-docs-hackage/page.html" rel="noreferrer" target="_blank">http://ariis.it/static/articles/no-docs-hackage/page.html</a><br>
>>><br>
>>> Living with a flaky WiFi, saves me from screaming at the monitor quite<br>
>>> some times.<br>
>>> _______________________________________________<br>
>>> Haskell-Cafe mailing list<br>
>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
<br>
<br>
--<br>
Noon Silk, ?<br>
<br>
<a href="https://silky.github.io/" rel="noreferrer" target="_blank">https://silky.github.io/</a><br>
<br>
"Every morning when I wake up, I experience an exquisite joy ? the joy<br>
of being this signature."<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/f8298446/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/f8298446/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 19 Jan 2016 23:40:31 +0100<br>
From: Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>><br>
To: Noon Silk <<a href="mailto:noonslists@gmail.com">noonslists@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CA+tcxkC7EZdeL6jFK7bA4=<a href="mailto:oARD%2BWCsgctKUqyJ9yMEyV7z1O-Q@mail.gmail.com">oARD+WCsgctKUqyJ9yMEyV7z1O-Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi *,<br>
<br>
On 19 January 2016 at 23:37, Noon Silk <<a href="mailto:noonslists@gmail.com">noonslists@gmail.com</a>> wrote:<br>
> Thanks Mark and All,<br>
><br>
> Indeed, I've been generating the docs myself offline; I didn't know about<br>
> looking for the docs on stackage; thanks!<br>
<br>
Note that with the Git version of cabal-install you can run 'cabal<br>
upload --doc' to upload the docs to Hackage manually.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 19 Jan 2016 22:44:26 +0000<br>
From: Auke Booij <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>><br>
To: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID:<br>
<<a href="mailto:CAP6YhL%2BGkGDjQSQuBE0HcrL8R6MAibSKRWu7jAR5Or8uwbDKfA@mail.gmail.com">CAP6YhL+GkGDjQSQuBE0HcrL8R6MAibSKRWu7jAR5Or8uwbDKfA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
This question is much more involved than you seem to be suggesting.<br>
It's not just about adding "some instructions for Haskell support".<br>
You have to think about how you want to express /every/ haskell term<br>
as a series of bits (preferably predictably many bits), and find a<br>
(finite) combination of logical gates to do arbitrary computations<br>
with them.<br>
<br>
If you want to go anywhere in this directions, perhaps a good start<br>
would be implementing a processor with instructions for (untyped)<br>
lambda calculus. One approach for this could be to take a<br>
(mathematical) model of lambda calculus and see how its elements can<br>
be represented as natural numbers.<br>
<br>
This implementation, I suspect, would be terribly inefficient. Think<br>
about what the lambda application gate would look like in terms of<br>
NAND gates. Yes, it can probably be done in theory. No, it won't be<br>
pretty. And forget about practical.<br>
<br>
Finally, a major advantage of having such "raw" language as an<br>
instruction set is that it allows many many optimizations (e.g.<br>
pipelining (which, I would say, is the single most important reason<br>
that processors are able to run at GHzs instead of MHzs (Pentium 4<br>
processors, famed for their high clock speed, had 31 pipeline<br>
stages))) that I cannot imagine being possible in anything close to a<br>
"lambda calculus processor".<br>
<br>
What is the added value you hope to achieve?<br>
<br>
On 19 January 2016 at 22:12, Henning Thielemann<br>
<<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> every now and then I think it would be cool to have a microprocessor that<br>
> supports Haskell in a way. A processor where lazy evaluation is not overhead<br>
> but an optimization opportunity, a processor that can make use of the<br>
> explicit data dependencies in Haskell programs in order to utilize many<br>
> computation units in parallel. I know of the Reduceron project, which<br>
> evolves only slowly and if it somewhen is ready for use it is uncertain<br>
> whether it can compete with stock CPUs since FPGA's need much more chip<br>
> space for the same logic.<br>
><br>
> I got to know that in todays x86 processors you can alter the instruction<br>
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add<br>
> some instructions for Haskell support? However, I suspect that such a patch<br>
> might be rendered invalid by new processor generations with changed internal<br>
> details. Fortunately, there are processors that are designed for custom<br>
> instruction set extensions:<br>
> <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
><br>
> Would it be sensible to create a processor based on such a design? I have no<br>
> idea what it might cost, and you would still need some peripheral circuitry<br>
> to run it. What could processor instructions for Haskell support look like?<br>
> Has anyone already thought in this direction?<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 19 Jan 2016 15:00:12 -0800<br>
From: Darren Grant <<a href="mailto:dedgrant@gmail.com">dedgrant@gmail.com</a>><br>
To: Auke Booij <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>><br>
Cc: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>>, Haskell Cafe<br>
<<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID:<br>
<CA+9vpFcay+6h97CqG+PBoVTjuEREfMCX5hkkXsqpdG4i=<a href="mailto:NxGBg@mail.gmail.com">NxGBg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Limiting the scope for my own sanity here, there may yet be some<br>
application in various hardware level emulations of continuation passing<br>
calculi, perhaps building on static single assignment.<br>
<br>
It might be possoble to derive an interesting instruction set from the<br>
sorts of intermediate representations we see in compiler infrastructures<br>
like LLVM, but it is hard to guess how these hardware designs would benefit<br>
haskell, rather than the other way around.<br>
<br>
Cheers,<br>
Darren<br>
On Jan 19, 2016 14:44, "Auke Booij" <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>> wrote:<br>
<br>
> This question is much more involved than you seem to be suggesting.<br>
> It's not just about adding "some instructions for Haskell support".<br>
> You have to think about how you want to express /every/ haskell term<br>
> as a series of bits (preferably predictably many bits), and find a<br>
> (finite) combination of logical gates to do arbitrary computations<br>
> with them.<br>
><br>
> If you want to go anywhere in this directions, perhaps a good start<br>
> would be implementing a processor with instructions for (untyped)<br>
> lambda calculus. One approach for this could be to take a<br>
> (mathematical) model of lambda calculus and see how its elements can<br>
> be represented as natural numbers.<br>
><br>
> This implementation, I suspect, would be terribly inefficient. Think<br>
> about what the lambda application gate would look like in terms of<br>
> NAND gates. Yes, it can probably be done in theory. No, it won't be<br>
> pretty. And forget about practical.<br>
><br>
> Finally, a major advantage of having such "raw" language as an<br>
> instruction set is that it allows many many optimizations (e.g.<br>
> pipelining (which, I would say, is the single most important reason<br>
> that processors are able to run at GHzs instead of MHzs (Pentium 4<br>
> processors, famed for their high clock speed, had 31 pipeline<br>
> stages))) that I cannot imagine being possible in anything close to a<br>
> "lambda calculus processor".<br>
><br>
> What is the added value you hope to achieve?<br>
><br>
> On 19 January 2016 at 22:12, Henning Thielemann<br>
> <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
> ><br>
> > Hi all,<br>
> ><br>
> > every now and then I think it would be cool to have a microprocessor that<br>
> > supports Haskell in a way. A processor where lazy evaluation is not<br>
> overhead<br>
> > but an optimization opportunity, a processor that can make use of the<br>
> > explicit data dependencies in Haskell programs in order to utilize many<br>
> > computation units in parallel. I know of the Reduceron project, which<br>
> > evolves only slowly and if it somewhen is ready for use it is uncertain<br>
> > whether it can compete with stock CPUs since FPGA's need much more chip<br>
> > space for the same logic.<br>
> ><br>
> > I got to know that in todays x86 processors you can alter the instruction<br>
> > set, which is mainly used for bugfixes. Wouldn't it be interesting to add<br>
> > some instructions for Haskell support? However, I suspect that such a<br>
> patch<br>
> > might be rendered invalid by new processor generations with changed<br>
> internal<br>
> > details. Fortunately, there are processors that are designed for custom<br>
> > instruction set extensions:<br>
> > <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
> ><br>
> > Would it be sensible to create a processor based on such a design? I<br>
> have no<br>
> > idea what it might cost, and you would still need some peripheral<br>
> circuitry<br>
> > to run it. What could processor instructions for Haskell support look<br>
> like?<br>
> > Has anyone already thought in this direction?<br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/58412564/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160119/58412564/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 20 Jan 2016 00:03:06 +0100 (CET)<br>
From: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
To: Auke Booij <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>><br>
Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID: <alpine.DEB.2.02.1601192357580.16459@sputnik><br>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed<br>
<br>
<br>
On Tue, 19 Jan 2016, Auke Booij wrote:<br>
<br>
> This question is much more involved than you seem to be suggesting.<br>
> It's not just about adding "some instructions for Haskell support".<br>
> You have to think about how you want to express /every/ haskell term<br>
> as a series of bits (preferably predictably many bits), and find a<br>
> (finite) combination of logical gates to do arbitrary computations<br>
> with them.<br>
<br>
I am not thinking about a radically different machine language, just a<br>
common imperative machine language with some added instructions for tasks<br>
often found in machine code generated from Haskell. E.g. mainstream<br>
processors support C function calls with special jump instruction and<br>
stack handling. Maybe there could be instructions that assist handling<br>
thunks or Haskell function calls.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 20 Jan 2016 11:52:21 +1100<br>
From: Ben Lippmeier <<a href="mailto:benl@ouroborus.net">benl@ouroborus.net</a>><br>
To: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID: <<a href="mailto:3EAF442C-90D4-40BE-91CE-EB7AE3E6EAFC@ouroborus.net">3EAF442C-90D4-40BE-91CE-EB7AE3E6EAFC@ouroborus.net</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On 20 Jan 2016, at 9:12 am, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
<br>
> I got to know that in todays x86 processors you can alter the instruction set, which is mainly used for bugfixes. Wouldn't it be interesting to add some instructions for Haskell support? However, I suspect that such a patch might be rendered invalid by new processor generations with changed internal details. Fortunately, there are processors that are designed for custom instruction set extensions:<br>
> <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
<br>
<br>
Your post assumes that the time to fetch/decode the instruction stream is a bottleneck, and reducing the number of instructions will in some way make the program faster.<br>
<br>
Your typically lazy GHC compiled program spends much of its time building thunks and otherwise copying data between the stack and the heap. If it?s blocked waiting for data memory / data cache miss then reducing the number of instructions won?t help anything ? at least if the fancy new instructions just tell the processor to do something that would lead to cache miss anyway.<br>
<br>
See: Cache Performance of Lazy Functional Programs on Current Hardware (from 2009)<br>
Arbob Ahmad and Henry DeYoung<br>
<a href="http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf" rel="noreferrer" target="_blank">http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf</a> <<a href="http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf" rel="noreferrer" target="_blank">http://www.cs.cmu.edu/~hdeyoung/15740/report.pdf</a>><br>
<br>
Indirect branches are also a problem (load an address from data memory, then jump to it), as branch predictors usually cannot deal with them. Slowdowns due to mispredicted branches could perhaps be mitigated by improving the branch predictor in a Haskell specific way, but you might not need new instructions to do so.<br>
<br>
Or another way of putting it: ?If you tell a long story with less words, then it?s still a long story.?<br>
<br>
Ben.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/881d9bb6/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/881d9bb6/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 20 Jan 2016 18:16:49 +1300<br>
From: "Richard A. O'Keefe" <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>><br>
To: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID: <<a href="mailto:A1E52B20-6AF7-4153-A040-97DC2837ED85@cs.otago.ac.nz">A1E52B20-6AF7-4153-A040-97DC2837ED85@cs.otago.ac.nz</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
On 20/01/2016, at 12:03 pm, Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
> I am not thinking about a radically different machine language, just a common imperative machine language with some added instructions for tasks often found in machine code generated from Haskell. E.g. mainstream processors support C function calls with special jump instruction and stack handling. Maybe there could be instructions that assist handling thunks or Haskell function calls.<br>
<br>
I was at a presentation once where the speaker showed how<br>
(thanks to the fact that Prolog doesn't evaluate arguments<br>
in calls) calling a procedure and executing the procedure<br>
could be overlapped, getting a factor of 2 speedup for an<br>
important part of the code. At another presentation a<br>
speaker showed how using a special outboard coprocessor<br>
could dramatically speed up memory management.<br>
<br>
I suspect that neither technique would be much help on today's<br>
machines and for Haskell. However, there is a hint here that<br>
doing something quite different might pay off.<br>
<br>
For example, if branch predictors don't do well with thunk<br>
handling, maybe there is a way of processing thunks that a<br>
quite different kind of branch predictor *might* cope with.<br>
Or maybe something that's expecting to process thousands of<br>
microthreads might not care about branch prediction. (Although<br>
that idea has been tried as a way of handling memory latency,<br>
I don't think it's been tried for Haskell.)<br>
<br>
Perhaps you might look for something different; instead of<br>
'faster on similar hardware' you might look at 'cheaper'.<br>
Could a specialised Haskell processor use less energy than<br>
a standard CPU?<br>
<br>
Don't quit your day job, but don't be too sure there's nothing<br>
left to think of either.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 20 Jan 2016 10:05:48 +0300<br>
From: Gleb Popov <<a href="mailto:6yearold@gmail.com">6yearold@gmail.com</a>><br>
To: Henning Thielemann <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>><br>
Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID:<br>
<<a href="mailto:CALH631nuDoV_4kBkRWjZvNuZK59kJ6fV6A_hnAKGh9YYznHbSQ@mail.gmail.com">CALH631nuDoV_4kBkRWjZvNuZK59kJ6fV6A_hnAKGh9YYznHbSQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Jan 20, 2016 at 1:12 AM, Henning Thielemann <<br>
<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
<br>
><br>
> Hi all,<br>
><br>
> every now and then I think it would be cool to have a microprocessor that<br>
> supports Haskell in a way. A processor where lazy evaluation is not<br>
> overhead but an optimization opportunity, a processor that can make use of<br>
> the explicit data dependencies in Haskell programs in order to utilize many<br>
> computation units in parallel. I know of the Reduceron project, which<br>
> evolves only slowly and if it somewhen is ready for use it is uncertain<br>
> whether it can compete with stock CPUs since FPGA's need much more chip<br>
> space for the same logic.<br>
><br>
> I got to know that in todays x86 processors you can alter the instruction<br>
> set, which is mainly used for bugfixes. Wouldn't it be interesting to add<br>
> some instructions for Haskell support? However, I suspect that such a patch<br>
> might be rendered invalid by new processor generations with changed<br>
> internal details. Fortunately, there are processors that are designed for<br>
> custom instruction set extensions:<br>
> <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
><br>
> Would it be sensible to create a processor based on such a design? I have<br>
> no idea what it might cost, and you would still need some peripheral<br>
> circuitry to run it. What could processor instructions for Haskell support<br>
> look like? Has anyone already thought in this direction?<br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
<br>
I remember reading relevent paper: The Reduceron reconfigured and<br>
re-evaluated. Authors are MATTHEW NAYLOR and COLIN RUNCIMAN.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/df0fdb6a/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/df0fdb6a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 20 Jan 2016 08:09:38 +0100<br>
From: Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>><br>
To: Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CANBN=<a href="mailto:muZG_pSYHVyciMORC5nu0-y%2BykhPdU-npLyCZ4J3srv3A@mail.gmail.com">muZG_pSYHVyciMORC5nu0-y+ykhPdU-npLyCZ4J3srv3A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2016-01-19 23:40 GMT+01:00 Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>><br>
:<br>
<br>
> Note that with the Git version of cabal-install you can run 'cabal<br>
> upload --doc' to upload the docs to Hackage manually.<br>
><br>
<br>
Are there any safeguards on the Hackage server side to guarantee<br>
consistency between the uploaded package and the uploaded docs? (i.e. make<br>
sure it's the right version etc.) Are there checks on the server side that<br>
the cross-package links are correct? Does the server make sure that the<br>
docs contain source links?<br>
<br>
If the answer to any of these questions is "no", I consider even the<br>
possibility of uploading docs by hand a bug. Wrong/partial documentation is<br>
worse than no documentation at all...<br>
<br>
Cheers,<br>
S.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/621dacc2/attachment-0001.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/621dacc2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 20 Jan 2016 08:35:02 +0100<br>
From: Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>><br>
To: Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CA+tcxkDEk2pzTfGWuJ71KJuxY-ibwzOPwOvKhnoDu1Xe=<a href="mailto:u4q1Q@mail.gmail.com">u4q1Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi,<br>
<br>
On 20 January 2016 at 08:09, Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>> wrote:<br>
> Are there any safeguards on the Hackage server side to guarantee consistency<br>
> between the uploaded package and the uploaded docs? (i.e. make sure it's the<br>
> right version etc.) Are there checks on the server side that the<br>
> cross-package links are correct? Does the server make sure that the docs<br>
> contain source links?<br>
<br>
If I'm reading [1] correctly, no such checks are performed.<br>
<br>
> If the answer to any of these questions is "no", I consider even the<br>
> possibility of uploading docs by hand a bug. Wrong/partial documentation is<br>
> worse than no documentation at all...<br>
<br>
You're welcome to open a ticket on the hackage-server bug tracker.<br>
<br>
[1] <a href="https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Features/Documentation.hs#L223" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/blob/master/Distribution/Server/Features/Documentation.hs#L223</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Wed, 20 Jan 2016 08:51:23 +0100<br>
From: Joachim Durchholz <<a href="mailto:jo@durchholz.org">jo@durchholz.org</a>><br>
To: <a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a><br>
Subject: Re: [Haskell-cafe] CPU with Haskell support<br>
Message-ID: <<a href="mailto:569F3C7B.80508@durchholz.org">569F3C7B.80508@durchholz.org</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
Am 19.01.2016 um 23:12 schrieb Henning Thielemann:<br>
><br>
> Fortunately, there are<br>
> processors that are designed for custom instruction set extensions:<br>
> <a href="https://en.wikipedia.org/wiki/Xtensa" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Xtensa</a><br>
<br>
Unfortunately, the WP article does not say anything that couldn't be<br>
said about, say, an ARM core. Other than that Xtensa core being some<br>
VLIW design.<br>
<br>
> Would it be sensible to create a processor based on such a design?<br>
<br>
Very, very unlikely, for multiple reasons.<br>
<br>
Special-purpose CPUs have been built, most notably for LISP, less<br>
notably for Java, and probably for other purposes that I haven't heard of.<br>
Invariably, their architectural advantages were obsoleted by economy of<br>
scale: Mainstream CPUs are being produced in such huge numbers that<br>
Intel etc. could affort more engineers to optimize every nook and<br>
cranny, more engineers to optimize the structure downscaling, and larger<br>
fabs that could do more chips on more one-time expensive but per-piece<br>
cheap equipment, and in the end, the special-purpose chips were slower<br>
and more expensive. It's an extremely strong competition you are facing<br>
if you try this.<br>
<br>
Also, it is very easy to misidentify the actual bottlenecks and make<br>
instructions for the wrong ones.<br>
If caching is the main bottleneck (which it usually is), no amount of<br>
CPU improvement will help you and you'll simply need a larger cache. Or,<br>
probably, a compiler that knows enough about the program and its data<br>
flow to arrange the data in a cache-line-friendly fashion.<br>
<br>
I do not think this is going to be a long-term problem though. Pure<br>
languages have huge advantages for fine-grained parallel processing, and<br>
CPU technology is pushing towards multiple cores, so that's a natural<br>
match. As pure languages come into more widespread use, the engineers at<br>
Intel, AMD etc. will look at what the pure languages need, and add<br>
optimizations for these.<br>
<br>
Just my 2 cents.<br>
Jo<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Wed, 20 Jan 2016 09:49:31 +0100<br>
From: Sven Panne <<a href="mailto:svenpanne@gmail.com">svenpanne@gmail.com</a>><br>
To: Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>><br>
Cc: "<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>" <<a href="mailto:cabal-devel@haskell.org">cabal-devel@haskell.org</a>>,<br>
"<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>" <<a href="mailto:haskell-cafe@haskell.org">haskell-cafe@haskell.org</a>><br>
Subject: Re: [Haskell-cafe] Doc generation?<br>
Message-ID:<br>
<CANBN=<a href="mailto:muhAXJaQQcTsbYGdsva-cTgC8si%2BU%2B-_Mjzt8Z3iJLZMA@mail.gmail.com">muhAXJaQQcTsbYGdsva-cTgC8si+U+-_Mjzt8Z3iJLZMA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2016-01-20 8:35 GMT+01:00 Mikhail Glushenkov <<a href="mailto:mikhail.glushenkov@gmail.com">mikhail.glushenkov@gmail.com</a>>:<br>
<br>
> You're welcome to open a ticket on the hackage-server bug tracker.<br>
><br>
<br>
I've reported this several times through several channels, not sure if yet<br>
another report will have an impact. Here a quick summary of<br>
doc-generation-related issues:<br>
<br>
<a href="https://github.com/haskell/hackage-server/issues/464" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/464</a><br>
<a href="https://github.com/haskell/hackage-server/issues/463" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/463</a><br>
<a href="https://github.com/haskell/hackage-server/issues/421" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/421</a><br>
<a href="https://github.com/haskell/hackage-server/issues/420" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/420</a><br>
<a href="https://github.com/haskell/hackage-server/issues/368" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/368</a><br>
<a href="https://github.com/haskell/hackage-server/issues/244" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/244</a><br>
<a href="https://github.com/haskell/hackage-server/issues/183" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/183</a><br>
<a href="https://github.com/haskell/hackage-server/issues/145" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/145</a><br>
<a href="https://github.com/haskell/hackage-server/issues/55" rel="noreferrer" target="_blank">https://github.com/haskell/hackage-server/issues/55</a><br>
<br>
>From a packager maintainer POV, it's totally unpredictable if/when<br>
documentation gets built, see e.g.<br>
<a href="http://hackage.haskell.org/package/GLURaw-2.0.0.1" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/GLURaw-2.0.0.1</a>: Currently there are no<br>
docs, while the previous version had docs, and the only change was relaxing<br>
the upper bound of OpenGLRaw (<br>
<a href="https://github.com/haskell-opengl/GLURaw/compare/v2.0.0.0...v2.0.0.1" rel="noreferrer" target="_blank">https://github.com/haskell-opengl/GLURaw/compare/v2.0.0.0...v2.0.0.1</a>).<br>
Basically I gave up any hope and rely on stackage and/or local docs... :-(<br>
<br>
Cheers,<br>
S.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/505370f1/attachment.html" rel="noreferrer" target="_blank">http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160120/505370f1/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Haskell-Cafe Digest, Vol 149, Issue 18<br>
*********************************************<br>
</blockquote></div>