From dedgrant at gmail.com  Sun Nov  1 05:50:50 2015
From: dedgrant at gmail.com (Darren Grant)
Date: Sun, 1 Nov 2015 16:50:50 +1100
Subject: [Haskell-cafe] testing for exceptions
In-Reply-To: <CA+9vpFfoTmsgz6zD27GymyNsVMYY8+_o9=tkAanOMQGQ6SXXnw@mail.gmail.com>
References: <563494E6.4070508@home.nl>
 <CA+9vpFcLJkTHbVvown2Q9Be7LZmKsV_KFAKj6WjD6bQoiXPpug@mail.gmail.com>
 <CAPeieQFGOHtFi45e+TUFO8ZFf6dR2qORvNhSidmNyTSPuNS6nQ@mail.gmail.com>
 <CA+9vpFcbeV9r9sMmUcw4NPChyUg1Z_jMj1A9GsXu3gXmXtFkWQ@mail.gmail.com>
 <1446308298.1723186.425412425.590D6D91@webmail.messagingengine.com>
 <CA+9vpFdPfb+73FyyZpNuDz6aWRtizgTvePyMpMRtpmQx9K=CXg@mail.gmail.com>
 <CA+9vpFcrcLwt9xNqmc41KSdw5eSAmg-LeCxDvxS_aBiF5M_F1Q@mail.gmail.com>
 <CA+9vpFfTtmuXfx5dHTcNaao1_ph7OJddp4bSsc9mMTeGMnZdMg@mail.gmail.com>
 <CA+9vpFeH7re1wFJrD64cd05g0-izjqX7PW7qvLf04S75vuYvxQ@mail.gmail.com>
 <CA+9vpFdOeO9QvC6s9OApVUFDG4smQv6UEUVPH5CJXv7QA8G5Qg@mail.gmail.com>
 <CA+9vpFfoTmsgz6zD27GymyNsVMYY8+_o9=tkAanOMQGQ6SXXnw@mail.gmail.com>
Message-ID: <CA+9vpFfKxi6yZ-GA+7HE+onuDNuFrqxnuNxNF_2JssG-jgCd3w@mail.gmail.com>

Great points.

I often run into situations where sketching out non-terminating endpoints
leads to a precise domain, but after peer review it becomes clear that a
much simpler program would result from compromising with a less precise
domain that eliminates these points altogether.

Eliminating branching on constructors in Haskell is a common aspect of this
refinement, it's true.

Cheers,
Darren
On Nov 1, 2015 03:18, <joachifm at fastmail.fm> wrote:

The ability to express non-termination is a feature, not a bug. If the
program truly cannot produce a useful result for some input, it should
crash, the earlier the better. Wrapping the return value ONLY to make a
non-total program *appear* total is kind of ugly (and commits you to a
potentially inappropriate/nonsensical model for the problem at hand). It
is cleaner to either constrain the input to values you're prepared to
deal with or crash when the implicit invariant is violated.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151101/4829df67/attachment.html>

From gracjanpolak at gmail.com  Sun Nov  1 08:06:07 2015
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Sun, 1 Nov 2015 09:06:07 +0100
Subject: [Haskell-cafe] Month in Haskell Mode October 2015
Message-ID: <CAChsM3QnJA4ZYb4M+2OVpXnnNw7c1F_6L=6-=_jWm111XpC6nA@mail.gmail.com>

Welcome Haskell Mode users,

Haskell Mode progress report for October 2015. It is also available online
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015>
and
on reddit
<https://www.reddit.com/r/haskell/comments/3r26px/month_in_haskell_mode_october_2015/>
.

For previous issue see September 2015
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-September-2015>
.
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#what-is-haskell-mode>What
is Haskell Mode?

Haskell Mode is an umbrella project for multiple Emacs tools for efficient
Haskell development. Haskell Mode is an open source project developed by a
group of volunteers. For more information see
https://github.com/haskell/haskell-mode.
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#important-developments>Important
developments

Functionality provided by haskell-indentation received a lot of fixes and
contributions lifting it to a complete new level of quality.
haskell-indentation is now a default indentation mode enabled when
haskell-mode itself is enabled.

ATTENTION TUTORIAL WRITERS: The following line is NO LONGER NEEDED:

   (add-hook 'haskell-mode-hook 'haskell-indentation-mode)

PLEASE REMOVE IT FROM ALL THE TUTORIALS OUT THERE. Thanks.

Note that for backward compatibility all other indentation modes know how
to properly handle new defaults.

We have also improved our development process by defining Complete
functionality
<https://github.com/haskell/haskell-mode/wiki/Complete-functionality> as a
concept.
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#cooperation-with-related-projects>Cooperation
with related projects

As noted last time Haskell Mode wanted to reach out to other projects in
editor space. This has not happened because even better events unfolded.
Things of note:

haskell-ide-(backend) <https://github.com/haskell/haskell-ide> project got
started by Alan Zimmerman. The goal is to bring in all the backend tools
that editors need to properly handle advanced Haskell editing.

ghc-mod <https://github.com/kazu-yamamoto/ghc-mod> does not need to be
introduced. We are thinking how to better split work between haskell-mode
and ghc-mod.

HaRe <https://github.com/RefactoringTools/HaRe> is a Haskell refactorer. It
can rename all the one letter variables to something more descriptive! It
can also do other things. And it has somewhat working Emacs integration.
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#heads-up-tutorial-writers>Heads
up tutorial writers!

There are plenty tutorials out there how to setup haskell-mode. Thanks for
writing those! Note that some of them are quite outdated at this point in
time and a bit confusing due to the improvements in haskell-mode. Can I ask
tutorial writers to contribute directly to haskell mode documentation so
that Haskell Mode Manual can be kept up to date with haskell-mode
developments?

Please contribute documentation back to the project. External tutorials get
out of hand pretty fast. Thanks
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#heads-up-cruft-removal>Heads
up! Cruft removal!

haskell-mode is about to loose some weight so that it can be better carried
by Haskell Mode Community. On the list to be removed are:

   - Remove haskell-bot.el
   <https://github.com/haskell/haskell-mode/pull/960>
   - Remove scc functions <https://github.com/haskell/haskell-mode/pull/961>
   - Remove horizontal whitespace based smart indentation mode
   haskell-simple-indent <https://github.com/haskell/haskell-mode/pull/958>
   - Remove Unicode input method
   <https://github.com/haskell/haskell-mode/pull/939>
   - Remove haskell-checkers.el
   <https://github.com/haskell/haskell-mode/pull/959>

If you use one of the above yourself, feel strongly that it should be
supported by the community and volunteer to write some unit tests and
documentation, please speak up!

The changes above will be merged no earlier than December 2015 so there is
time to chime in.
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#current-project-focus>Current
project focus

Current project focus is to lower entry barrier for newcomers by defining
bite-sized tasks.

Get 50 'well-defined-tasks' done as by the metric:

https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-defined-task+is%3Aclosed

A 'well-defined-task' is a category of tasks that have the field cleared
for them, questions already sorted out and detailed information how to get
them done. So you can just sit, search for 'well-defined-task' label and
enjoy the coding! The point is to lower the entry barrier for new users,
new issue reporters and advanced programmers but Emacs lisp beginners to
contribute to the project.

Current status: 13 well-defined-tasks closed
<https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-defined-task+is%3Aclosed>
plus 13 more open
<https://github.com/haskell/haskell-mode/issues?q=is%3Aissue+label%3Awell-defined-task+is%3Aopen>
.

If only you can help with reaching our targets please do so!
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#issues-closed-in-october>Issues
closed in October

   - Disable Indentation #90
   <https://github.com/haskell/haskell-mode/issues/90>
   - Unicode symbols inside ghci prompt hang inferior-haskell-mode #176
   <https://github.com/haskell/haskell-mode/issues/176>
   - Multi-line -ferror-spans syntax not supported #192
   <https://github.com/haskell/haskell-mode/issues/192>
   - [Discussion] Add end-to-end guide for configuring haskell-mode in a
   place where users will see it #197
   <https://github.com/haskell/haskell-mode/issues/197>
   - Sorting imported functions from a module alphabetically #206
   <https://github.com/haskell/haskell-mode/issues/206>
   - After the newline have to hit twice to start cycling #276
   <https://github.com/haskell/haskell-mode/issues/276>
   - indent-according-to-mode opens the help buffer for haskell-mode-hook
   #290 <https://github.com/haskell/haskell-mode/issues/290>
   - Can't get type info unless file compiles #294
   <https://github.com/haskell/haskell-mode/issues/294>
   - Parsing broken on quasi quotes #323
   <https://github.com/haskell/haskell-mode/issues/323>
   - getLine behaves not correctly in Interactive-Haskell-mode. #333
   <https://github.com/haskell/haskell-mode/issues/333>
   - Overly aggressive indenting after recent Emacs update #377
   <https://github.com/haskell/haskell-mode/issues/377>
   - haskell-indentation-mode parse error on indenting import declaration
   #397 <https://github.com/haskell/haskell-mode/issues/397>
   - Pick one indentation mode as preferred in the documentation/customize.
   #414 <https://github.com/haskell/haskell-mode/issues/414>
   - haskell-indendation and guards #481
   <https://github.com/haskell/haskell-mode/issues/481>
   - Running indent-according-to-mode moves the cursor way to the right #488
   <https://github.com/haskell/haskell-mode/issues/488>
   - haskell-session-change-target should list available targets #534
   <https://github.com/haskell/haskell-mode/issues/534>
   - Haskell-mode crashing and buffer erased (not sure exactly where
   problem is) #594 <https://github.com/haskell/haskell-mode/issues/594>
   - haskell-indentation breaks with UnicodeSyntax #715
   <https://github.com/haskell/haskell-mode/issues/715>
   - Handle Template Haskell / DataKinds names in haskell-indentation #760
   <https://github.com/haskell/haskell-mode/issues/760>
   - No indentation suggested for case clauses #786
   <https://github.com/haskell/haskell-mode/issues/786>
   - Pull in ghc-mod's ghc-make-indent-shallower/deeper into haskell-mode
   #826 <https://github.com/haskell/haskell-mode/issues/826>
   - Clean up example init.el on wiki #843
   <https://github.com/haskell/haskell-mode/issues/843>
   - Indentation mode needs to be able to recover from parser errors #861
   <https://github.com/haskell/haskell-mode/issues/861>
   - haskell-simple-indent-mode non-responsive #867
   <https://github.com/haskell/haskell-mode/issues/867>
   - Get hit by 'Invalid Token := )' #875
   <https://github.com/haskell/haskell-mode/issues/875>
   - Invalid Token :| #878
   <https://github.com/haskell/haskell-mode/issues/878>
   - Parse error: Illegal token: where #883
   <https://github.com/haskell/haskell-mode/issues/883>
   - parse-error "Expecting then" "Expecting else" DoAndIfThenElse in
   indentation #884 <https://github.com/haskell/haskell-mode/issues/884>
   - Illegal tokens and QuasiQuotes #894
   <https://github.com/haskell/haskell-mode/issues/894>
   - Haskell Interactive Shell Stuck in Insert Mode (spacemacs) #895
   <https://github.com/haskell/haskell-mode/issues/895>
   - Syntax highlighting: no difference between data constructor and type ?
   #898 <https://github.com/haskell/haskell-mode/issues/898>
   - Let the enter create a new line despite the indentation errors #905
   <https://github.com/haskell/haskell-mode/issues/905>
   - Parse Error inside QuasiQuotes #907
   <https://github.com/haskell/haskell-mode/issues/907>
   - "Expecting else" error message #917
   <https://github.com/haskell/haskell-mode/issues/917>
   - Support commas in first indentation column #918
   <https://github.com/haskell/haskell-mode/issues/918>
   - haskell-process changes the directory which causes loaded modules to
   be unloaded #923 <https://github.com/haskell/haskell-mode/issues/923>
   - Syntax highlighting only #924
   <https://github.com/haskell/haskell-mode/issues/924>
   - haskell-process.el binds C-c c but should not #926
   <https://github.com/haskell/haskell-mode/issues/926>
   - Simple indent vs haskell-indentation when using autofill on comments
   #932 <https://github.com/haskell/haskell-mode/issues/932>
   - How to use REPL with stack? #953
   <https://github.com/haskell/haskell-mode/issues/953>
   - Wiki documentation out of sync ? #968
   <https://github.com/haskell/haskell-mode/issues/968> ### Pull requests
   merged in October
   - Support where keyword after any expression #897
   <https://github.com/haskell/haskell-mode/pull/897>
   - Support names starting with quotes #903
   <https://github.com/haskell/haskell-mode/pull/903>
   - Fix switching to the presentation buffer #904
   <https://github.com/haskell/haskell-mode/pull/904>
   - Implement QuasiQuotes syntax in indentation #909
   <https://github.com/haskell/haskell-mode/pull/909>
   - Add build notification to #haskell-emacs #912
   <https://github.com/haskell/haskell-mode/pull/912>
   - Mobile friendly README.md #913
   <https://github.com/haskell/haskell-mode/pull/913>
   - Add failing tests for indentation #916
   <https://github.com/haskell/haskell-mode/pull/916>
   - Toplevel indentation bugfixes for data, newtype, instance #919
   <https://github.com/haskell/haskell-mode/pull/919>
   - Document failing indentation #920
   <https://github.com/haskell/haskell-mode/pull/920>
   - Navigate to top level declaration in indenatation #921
   <https://github.com/haskell/haskell-mode/pull/921>
   - Make haskell indentation the default indentation mode #922
   <https://github.com/haskell/haskell-mode/pull/922>
   - Don't change directory when using stack-ghci. #925
   <https://github.com/haskell/haskell-mode/pull/925>
   - Add rather baroque indentation test which cause parse failure #927
   <https://github.com/haskell/haskell-mode/pull/927>
   - Yet another parser failure #928
   <https://github.com/haskell/haskell-mode/pull/928>
   - Reloading: haskell-process-file-loadish needs the current buffer as an
   argument #929 <https://github.com/haskell/haskell-mode/pull/929>
   - Fix nested layout 1 #930
   <https://github.com/haskell/haskell-mode/pull/930>
   - Filter only sections bearing targets - fixes #534 #931
   <https://github.com/haskell/haskell-mode/pull/931>
   - Honour curly braces in target sections #933
   <https://github.com/haskell/haskell-mode/pull/933>
   - Add failing tests for multiline string literals #934
   <https://github.com/haskell/haskell-mode/pull/934>
   - Mark some indentation tests as passing #936
   <https://github.com/haskell/haskell-mode/pull/936>
   - Remove useless debugging functions #937
   <https://github.com/haskell/haskell-mode/pull/937>
   - Write tests properly, mark them as passing #944
   <https://github.com/haskell/haskell-mode/pull/944>
   - Remove auto-fill code from indentation #945
   <https://github.com/haskell/haskell-mode/pull/945>
   - Improve can grab prefix for completions #946
   <https://github.com/haskell/haskell-mode/pull/946>
   - Remove dynamic indentation showing #947
   <https://github.com/haskell/haskell-mode/pull/947>
   - Indentation of guards with commas is working properly #948
   <https://github.com/haskell/haskell-mode/pull/948>
   - Fix indent for do inside a list #956
   <https://github.com/haskell/haskell-mode/pull/956>
   - Recognize top level constructs in indentation #965
   <https://github.com/haskell/haskell-mode/pull/965>
   - Remove indentation safety hack #966
   <https://github.com/haskell/haskell-mode/pull/966>
   - Change 'w.r.t' to 'with regards to' for clarity #967
   <https://github.com/haskell/haskell-mode/pull/967>

<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#contributors-active-in-october>Contributors
active in October

Alexey Khudyakov, Chris Done, Gracjan Polak, Gregor Riegler, Kabelo Moiloa,
Marlo Major, vlatkoB
<https://github.com/haskell/haskell-mode/wiki/Month-in-Haskell-Mode-October-2015#contributing>
Contributing

Haskell Mode needs volunteers like any other open source project. For more
information see:

https://github.com/haskell/haskell-mode/wiki

Also drop by our IRC channel: #haskell-emacs at irc.freenode.net.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151101/25bb1078/attachment-0001.html>

From simon at joyful.com  Sun Nov  1 20:04:14 2015
From: simon at joyful.com (Simon Michael)
Date: Sun, 1 Nov 2015 12:04:14 -0800
Subject: [Haskell-cafe] ANN: hledger-0.27, with more console power
In-Reply-To: <2e123056-eced-4b36-abe5-28464e684732@googlegroups.com>
References: <3219334D-DCCF-4E2C-B64F-120D3D0752F9@joyful.com>
 <2e123056-eced-4b36-abe5-28464e684732@googlegroups.com>
Message-ID: <54F7BD71-815F-44E1-8F6C-589FEAD310E1@joyful.com>

Hi Johannes, 

quite right. I've added a few screenshots to the manual at http://hledger.org/manual#ui <http://hledger.org/manual#ui> .

Some of them use the more realistic example data from the beancount project, thanks to Martin Blais.

Best,
-Simon


> On Nov 1, 2015, at 10:16 AM, johannesjh at gmail.com wrote:
> 
> Hi Simon!
> 
> The availability of a text-based user interface for hledger sounds great. Could you please post some screenshots of what the UI looks like?
> 
> thank you very much,
> Johannes
> 
> 
> 
> On Saturday, October 31, 2015 at 10:38:20 PM UTC+1, Simon Michael (sm) wrote:
> I'm pleased to announce hledger 0.27!
> 
> What is it ?
> hledger is a cross-platform program for tracking money, time, or any
> other commodity, using double-entry accounting and a simple, editable
> file format.  It can also read CSV or timelog files, and export CSV.
> It provides command-line, curses and web interfaces, and aims to be a
> reliable, practical tool for daily use.  It is inspired by and largely
> compatible with ledger(1).
> 
> What's new ?
> This release introduces hledger-ui, a new curses-style interface that
> I'm quite pleased with (not yet available on Windows). Built on vty
> and the new brick library, it lets you review account balances and
> transactions with fewer keystrokes and less effort. Ledger users with 
> compatible journal files may also find this useful.
> 
> hledger can now report current value based on market prices (hurrah);
> wide characters are displayed properly; regular expression account
> aliases are fast; and unix man pages are provided. You can see all
> changes and bugfixes at http://hledger.org/release-notes#hledger-0.27 <http://hledger.org/release-notes#hledger-0.27> .
> 
> Release contributors: 
> Simon Michael,
> Carlos Lopez-Camey.
> 
> How to get it ?
> hledger can be installed with cabal or stack - see
> http://hledger.org/download <http://hledger.org/download> for guidance.
> If you'd like to contribute Windows or Mac binaries, please get in
> touch.
> 
> Happy Hallowe'en!
> -Simon
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "hledger" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hledger+unsubscribe at googlegroups.com <mailto:hledger+unsubscribe at googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151101/f1a180d3/attachment.html>

From ok at cs.otago.ac.nz  Mon Nov  2 00:21:20 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 2 Nov 2015 13:21:20 +1300
Subject: [Haskell-cafe] testing for exceptions
In-Reply-To: <5634B3A4.9060507@home.nl>
References: <563494E6.4070508@home.nl>
 <CA+9vpFcLJkTHbVvown2Q9Be7LZmKsV_KFAKj6WjD6bQoiXPpug@mail.gmail.com>
 <56349BF7.1000604@home.nl>
 <CA+9vpFek1YTONfTjWcFvL2vPbFenSa_sZh3QEaXAJREY30cS3A@mail.gmail.com>
 <CABw4ky7zduT8cS_vpYgrH4WHC41Uovo1=h+oM5rb=R0t8__YWg@mail.gmail.com>
 <5634B3A4.9060507@home.nl>
Message-ID: <013031C5-6B62-436A-B090-41D16646786C@cs.otago.ac.nz>

Simplest hack:

    f2Maybe :: Integer -> Maybe Integer
    f2Maybe n = if n < 0 then Nothing else Just (g n)
      where g 0 = 1
            g n = if odd n then x*2 else x
                  where x = (g (n `div` 2))^2

There is no need to *keep* checking for a negative number in the
recursive code.
> 
> f2Maybe :: Integer -> Maybe Integer 
> f2Maybe n 
>    | n > 0  = Nothing 
>    | n == 0  = Just 1 
>    | even n = Just (f2Maybe ( n `div` 2) ^ 2)
>    | odd n  = Just ((f2Maybe ( n `div` 2) ^ 2) * 2) 

Let's try another tack.
The recursive calls (f2Maybe (n `div` 2))
give you a value of type Maybe Integer.
You want to transform the Integer part.
This is an instance of

 Monad m => m a -> (a -> b) -> m b.

There's something almost like that in Control.Monad:

  liftM :: (a -> b) -> m a -> m b

So what you want is

  liftM (\x -> x^2)   (f2Maybe (n `div` 2))
  liftM (\x -> x^2*2) (f2Maybe (n `div` 2))

So

  f2Maybe n | n < 0 = Nothing
  f2Maybe 0         = Just 1
  f2Maybe n         = liftM (if odd n then (\x -> x^2*2) else (\x -> x^2))
                            (f2Maybe (n `div` 2))

Or you could use 'do' notation:

    f2Maybe n | n < 0 = Nothing
    f2Maybe 0         = Just 1
    f2Maybe n         = do x <- f2Maybe (n `div` 2)
                           return (if odd n then x^2*2 else x^2)

Whatever you do, the key thing is that you HAVE a value
wrapped up in Just and you need to unwrap it, operate on the
value, and rewrap it.

So you could do something like

rewrap _ Nothing  = Nothing
rewrap f (Just x) = Just (f x)

and then

    f2Maybe n | n < 0 = Nothing
    f2Maybe 0         = Just 1
    f2Maybe n         = rewrap (\x -> if odd n then x^2*2 else x^2)
                               (f2Maybe (n `div` 2))

and presto, chango! we've just re-invented liftM under the name
'rewrap'.   




From ok at cs.otago.ac.nz  Mon Nov  2 00:49:23 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 2 Nov 2015 13:49:23 +1300
Subject: [Haskell-cafe] what do I have to do exactlry with this exercises
In-Reply-To: <56330C3E.6040601@home.nl>
References: <56330C3E.6040601@home.nl>
Message-ID: <3FBDD034-E46D-4297-864A-D5640A3BF4E5@cs.otago.ac.nz>


On 30/10/2015, at 7:20 pm, Roelof Wobben <r.wobben at home.nl> wrote:

> Hello,
> 
> Im self studing Haskell with the Craft o ffunctional programmimg of Hutton.
> 
> Now I see two exercises that I do not understand what is really the purpose here.
> 
> The two exercises are :
> 
> 4.21 Given a function f of type Integer -> Integer give a recursive definition of a
> function of type Integer -> Integer which on input n returns the maximum
> of the values f 0, f 1, ..., f n. You might find the max function defined in
> Section 3.4 useful.
> To test this function, add to your script a definition of some values of f thus:
> f 0 = 0
> f 1 = 44
> f 2 = 17
> f _ = 0
> and so on; then test your function at various values.

You are to write a function of type Integer -> Integer.
So it doesn't receive f as a parameter,
f is "given" by being visible.

g :: Integer -> Integer
g n = the maximum of [f 0, ..., f n]

In general you would have two ways to do this:

(1) Roll your own recursion:

    g 0 = the maximum of [f 0] = ???
    g n = the maximum of [f 0, ..., f (n-1), f n]
            = some combination of the maximum of [f 0 ... f (n-1)]
              and f n

    This is a simple 2-line recursion.

(2) Actually make the list [f 0, ..., f n]
    -- there are several ways to do that, a list comprehension
    is readable but `map' could be used --
    and find the maximum from the list (so you are looking for
    a built in function Ord t => [t] -> t)

    This is a one-liner, but it's not recursive (or rather, YOUR
    part of it is not recursive), so this alternative is ruled out.

The purpose here is to get you writing a simple recursion.

> 
> 4.22 Given a function f of type Integer -> Integer give a recursive definition of
> a function of type Integer -> Bool which on input n returns True if one or
> more of the values f 0, f 1, ..., f n is zero and False otherwise.

The purpose here is probably to get you to realise that
4.21 and 4.22 have essentially the same solution (or more
precisely, have solutions which are structurally the same).



From ok at cs.otago.ac.nz  Mon Nov  2 01:16:39 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 2 Nov 2015 14:16:39 +1300
Subject: [Haskell-cafe] Find a point inside (x,y,z) -> Bool
In-Reply-To: <5631E07D.8090705@web.de>
References: <5631E07D.8090705@web.de>
Message-ID: <EEC0C5F5-E300-4388-86B8-BD5F1126DB9A@cs.otago.ac.nz>


On 29/10/2015, at 10:01 pm, martin <martin.drautzburg at web.de> wrote:

> Hello all,
> 
> I hope this is not a too silly question. It goes like this:
> 
> Suppose I have a shape defined as
> 
> (x,y,z) -> Bool
> 
> how can I find a Point inside this shape?


What are x, y, z?

Consider a simplified case:
   (Natural, Natural) -> Bool
You can search
   (0,0)
   (1,0), (0,1)
   (2,0), (1,1), (0,2)
   (3,0), (2,1), (1,2), (0,3)
   ...
and if the shape is not empty you'll find some point in it.

For 3D, consider
   (0,0,0)
   (1,0,0) (0,1,0) (0,0,1)
   (2,0,0) (1,1,0) (1,0,1) (0,2,0) (0,1,1) (0,0,2)
   ...
> Obviously I could iterate through all possible x,y and z, but this appears
> very expensive.

Yes it is, but if that's _all_ you know about a shape ...

What if the shape is empty?


From ok at cs.otago.ac.nz  Mon Nov  2 01:29:10 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 2 Nov 2015 14:29:10 +1300
Subject: [Haskell-cafe] what do I have to do exactlry with this exercises
In-Reply-To: <563313A9.9030102@home.nl>
References: <56330C3E.6040601@home.nl>
 <CACz_ru0ai6vfP__-snzd+2nt7Oxj51Kaq75VOBHYxMLGH1fspg@mail.gmail.com>
 <563310C9.60809@home.nl>
 <CACz_ru1inYSYM0dTsUW9Hh8PBDMoi_a91A=-OtAH8QvcKK8+SA@mail.gmail.com>
 <563313A9.9030102@home.nl>
Message-ID: <8751B60A-13B2-4FD8-8AF9-6417943A7B9A@cs.otago.ac.nz>


On 30/10/2015, at 7:52 pm, Roelof Wobben <r.wobben at home.nl> wrote:
> 
> Let's say f is a recursive function which calculates the fac. 
> 
> So f 0  = 0 
> f1 = 1
> f2 = 2 
> f3 = 6 
> 
> so im my oponion g1 = the answer of f1 which is also the max 

True.  But what if f is *NOT* the factorial?

To quote your own original message,
<quote>
To test this function, add to your script a definition of some values of f thus:
f 0 = 0
f 1 = 44
f 2 = 17
f _ = 0
and so on; then test your function at various values.
</quote>

This f is NOT the factorial function.  For this f,
we expect g n = if n == 0 then 0 else 44, so that
(g n == f n) is false almost always.

Let's consider the general pattern for a primitive recursive
function on the natural numbers:

g 0 otherArgs = b otherArgs
g (n+1) otherArgs = c n (g n otherArgs) otherArgs

where b(ase) and c(ombination) are primitive recursive.
In this case, there are no otherArgs, so

g 0 = <<some expression possibly involving f>>
g n = <<some expression involving n, g (n-1), and f>>

For exercise 4.22, you are given a hint that
<<some expression involving n, g (n-1), and f>>
will also involve a call to max.

There's really not a lot of sensible ways you can put these together.


From ok at cs.otago.ac.nz  Mon Nov  2 01:36:38 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Mon, 2 Nov 2015 14:36:38 +1300
Subject: [Haskell-cafe] what do I have to do exactlry with this exercises
In-Reply-To: <563316B9.5090600@home.nl>
References: <56330C3E.6040601@home.nl>
 <CACz_ru0ai6vfP__-snzd+2nt7Oxj51Kaq75VOBHYxMLGH1fspg@mail.gmail.com>
 <563310C9.60809@home.nl>
 <CACz_ru1inYSYM0dTsUW9Hh8PBDMoi_a91A=-OtAH8QvcKK8+SA@mail.gmail.com>
 <563313A9.9030102@home.nl>
 <CACz_ru1YgJsBxezdAzqz58CXRRK1XFtf8oDopDgiaDZuMuf4bg@mail.gmail.com>
 <563316B9.5090600@home.nl>
Message-ID: <07DF6C07-3AEF-40B8-9522-510CB97354C6@cs.otago.ac.nz>


On 30/10/2015, at 8:05 pm, Roelof Wobben <r.wobben at home.nl> wrote:
> 
> Now I have to think about how to read the values of f 1 .. fn 2 .

You "read the value of f 1" by calling f 1.

> I think I need 2 recursive function . One for g x and one for reading f1

NO.  You were told to write *A* recursive function.
That's ONE recursive function.  That's all you need.

g 0 = the maximum of [f 0] = what?
g n = the maximum of [f 0, f 1, ..., f (n-1), f n]

Now, DO YOU KNOW A FUNCTION THAT YOU CAN CALL TO COMPUTE
   the maximum of [f 0, f 1, ..., f (n-1)]
?
Can you see HOW TO COMBINE that answer with f n to get the
final result you want?  Is there a function MENTIONED IN
THE PROBLEM that could do this last step?



From ky3 at atamo.com  Mon Nov  2 02:38:09 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Mon, 2 Nov 2015 09:38:09 +0700
Subject: [Haskell-cafe] testing for exceptions
In-Reply-To: <CABw4ky7zduT8cS_vpYgrH4WHC41Uovo1=h+oM5rb=R0t8__YWg@mail.gmail.com>
References: <563494E6.4070508@home.nl>
 <CA+9vpFcLJkTHbVvown2Q9Be7LZmKsV_KFAKj6WjD6bQoiXPpug@mail.gmail.com>
 <56349BF7.1000604@home.nl>
 <CA+9vpFek1YTONfTjWcFvL2vPbFenSa_sZh3QEaXAJREY30cS3A@mail.gmail.com>
 <CABw4ky7zduT8cS_vpYgrH4WHC41Uovo1=h+oM5rb=R0t8__YWg@mail.gmail.com>
Message-ID: <CAPY+ZdSdyfUn2mqt-DYF2yWJcvcHxMjHNZj=ptHae0qJy0yL9Q@mail.gmail.com>

On Sat, Oct 31, 2015 at 6:10 PM, Roel van Dijk <vandijk.roel at gmail.com>
wrote:

> Small nitpick, but I would generally put the "exception" or "error" in the
> Left part of an Either and a correct result in the Right part.
>
> This has some advantages.
> 1 - Right is right as opposed to wrong. Easy to remember mnemonic.
> 2 - It fits neatly with the Monad (Either e) instance.
>

I think you're being modest when you call it a "small nitpick." If code
can't get Left and Right right, that code immediately becomes very
suspicious.

Thus, not

  f2 :: Integer -> Either Integer ErrorString

but

  f2 :: Integer -> Either ErrorString Integer
Nice catch.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/5a36e247/attachment.html>

From dedgrant at gmail.com  Mon Nov  2 02:40:20 2015
From: dedgrant at gmail.com (Darren Grant)
Date: Mon, 2 Nov 2015 13:40:20 +1100
Subject: [Haskell-cafe] testing for exceptions
In-Reply-To: <CAPY+ZdSdyfUn2mqt-DYF2yWJcvcHxMjHNZj=ptHae0qJy0yL9Q@mail.gmail.com>
References: <563494E6.4070508@home.nl>
 <CA+9vpFcLJkTHbVvown2Q9Be7LZmKsV_KFAKj6WjD6bQoiXPpug@mail.gmail.com>
 <56349BF7.1000604@home.nl>
 <CA+9vpFek1YTONfTjWcFvL2vPbFenSa_sZh3QEaXAJREY30cS3A@mail.gmail.com>
 <CABw4ky7zduT8cS_vpYgrH4WHC41Uovo1=h+oM5rb=R0t8__YWg@mail.gmail.com>
 <CAPY+ZdSdyfUn2mqt-DYF2yWJcvcHxMjHNZj=ptHae0qJy0yL9Q@mail.gmail.com>
Message-ID: <CA+9vpFd86iOsdz+i8fT8QdRCjg5fJxPnotZWn9Q7PytmEakOeg@mail.gmail.com>

Oops yes! :)
On Nov 2, 2015 13:38, "Kim-Ee Yeoh" <ky3 at atamo.com> wrote:

>
> On Sat, Oct 31, 2015 at 6:10 PM, Roel van Dijk <vandijk.roel at gmail.com>
> wrote:
>
>> Small nitpick, but I would generally put the "exception" or "error" in
>> the Left part of an Either and a correct result in the Right part.
>>
>> This has some advantages.
>> 1 - Right is right as opposed to wrong. Easy to remember mnemonic.
>> 2 - It fits neatly with the Monad (Either e) instance.
>>
>
> I think you're being modest when you call it a "small nitpick." If code
> can't get Left and Right right, that code immediately becomes very
> suspicious.
>
> Thus, not
>
>   f2 :: Integer -> Either Integer ErrorString
>
> but
>
>   f2 :: Integer -> Either ErrorString Integer
> Nice catch.
>
> -- Kim-Ee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/22b3515d/attachment.html>

From michael at snoyman.com  Mon Nov  2 16:10:09 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 2 Nov 2015 08:10:09 -0800
Subject: [Haskell-cafe] process package with compilers besides GHC
Message-ID: <CAKA2JgLjSbCS40J0mHTdL1kqYqykHCSqw5Fp4-6EtPEzRci_zA@mail.gmail.com>

I'm currently in the process* of a cleanup of the process package to reduce
the usage of CPP conditionals in the code. Currently, as Simon PJ pointed
out, it's quite difficult to follow the logic between Windows and POSIX
platforms. During the cleanup, I've noticed that:

1. There's also quite a bit of complication around the __GLASGOW_HASKELL__
conditionals, intended to make the package compilable with other compilers
2. There seems to be no way that - in its current state - the package could
be compilable with a compiler besides GHC

I wanted to reach out and see if anyone is currently using the process
package on a compiler besides GHC, and if so, get information on whether
recent releases also work, and get some kind of automated testing in place
to prevent regressions. If there are no such users, I'm likely to remove
the (presumably non-working) conditionals.

* No pun intend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/106b3077/attachment.html>

From lemming at henning-thielemann.de  Mon Nov  2 17:04:30 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 2 Nov 2015 18:04:30 +0100 (CET)
Subject: [Haskell-cafe] simple library for HTML form generation and
	processing
Message-ID: <alpine.DEB.2.02.1511021802490.7828@sputnik>


I posted the following already to web-devel at haskell.org but it seems to be 
relatively quiet there.

-----

I like to get your advice about a simple library for web form generation and 
processing. So far I tried digestive-functors and reform. Both of them are 
advertised as being good in separating data from view. However, I am interested 
in one-off forms, that is, form data will always be rendered in one way. Thus I 
would like to save the efforts to combine data and view after they have been 
carefully separated.

Formerly I have also used autolib-cgi:
    http://autolat.imn.htwk-leipzig.de/haddock/autolib-cgi-1.2/

It allowed me to generate the form and fetch and validate the data in one 
(monadic) go. The blaze-markup type MarkupM is a monad anyway, thus it seems to 
be straight-forward to use the monadic results for the data entered to the 
form.

Is there a library that supports this style of web form handling?

From jan.bracker at googlemail.com  Mon Nov  2 18:06:43 2015
From: jan.bracker at googlemail.com (Jan Bracker)
Date: Mon, 2 Nov 2015 18:06:43 +0000
Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax
 sometimes requires type signatures?
In-Reply-To: <CANQO64JVMyP+yWj-_TcHeGr2mXRA2aoZn-dcUrAC1jB_6MwrvQ@mail.gmail.com>
References: <CANEwrkTrtf3OquRGCe6+V48=pSGWq-77L8wUSGCDn96hseA4Cw@mail.gmail.com>
 <CANQO64JVMyP+yWj-_TcHeGr2mXRA2aoZn-dcUrAC1jB_6MwrvQ@mail.gmail.com>
Message-ID: <CANEwrkQrjxb9RmAY_bgkaG38JvkCPh=QuyA4NVPWb2-oHgUU4g@mail.gmail.com>

Hi Chris,

thanks for your answer!

I checked both of your solutions and when I apply either I still get errors.

If I add arguments to my local definitions I get the following errors:

Main.hs:27:3:
    Couldn't match kind ?*? with ?[*]?
    When matching types
      m0 :: * -> * -> *
      State :: [*] -> * -> *
    Expected type: m0 f0 Bool
                   -> (Bool -> m0 (E.Unit m0) (Either Tree [Int]))
                   -> State '["flatten" :-> (Bool :! 'R)] (Either Tree
[Int])
      Actual type: m0 f0 Bool
                   -> (Bool -> m0 (E.Unit m0) (Either Tree [Int]))
                   -> m0 (E.Plus m0 f0 (E.Unit m0)) (Either Tree [Int])
    Relevant bindings include
      return :: forall a. a -> m0 (E.Unit m0) a (bound at Main.hs:35:9)
    In a stmt of a 'do' block: flatten <- get (Var :: Var "flatten")
    In the expression:
      do { flatten <- get (Var :: Var "flatten");
           if flatten then return $ Right [i] else return $ Left $ Leaf i }
    In an equation for ?process?:
        process (Leaf i)
          = do { flatten <- get (Var :: Var "flatten");
                 if flatten then return $ Right [...] else return $ Left $
Leaf i }
          where
              (>>=) m f = (E.>>=) m f
              (>>) m n = (E.>>) m n
              return = E.return
              fail = E.fail

Main.hs:35:18:
    No instance for (E.Effect m0) arising from a use of ?E.return?
    In the expression: E.return
    In an equation for ?return?: return = E.return
    In an equation for ?process?:
        process (Leaf i)
          = do { flatten <- get (Var :: Var "flatten");
                 if flatten then return $ Right [...] else return $ Left $
Leaf i }
          where
              (>>=) m f = (E.>>=) m f
              (>>) m n = (E.>>) m n
              return = E.return
              fail = E.fail

Main.hs:47:18:
    No instance for (E.Effect m1) arising from a use of ?E.return?
    In the expression: E.return
    In an equation for ?return?: return = E.return
    In an equation for ?process?:
        process (Branch tl tr)
          = do { eitherL <- process tl;
                 eitherR <- process tr;
                 case (eitherL, eitherR) of {
                   (Left l, Left r) -> return $ Left $ Branch l r
                   (Right l, Right r) -> return $ Right $ l ++ r } }
          where
              (>>=) m f = (E.>>=) m f
              (>>) m n = (E.>>) m n
              return = E.return
              fail = E.fail

Which again I can't explain for myself.

If I add NoMonomorphismRestriction, I get the following errors:

Main.hs:27:3:
    Couldn't match kind ?*? with ?[*]?
    When matching types
      m0 :: * -> * -> *
      State :: [*] -> * -> *
    Expected type: m0 f0 Bool
                   -> (Bool -> m0 (E.Unit m0) (Either Tree [Int]))
                   -> State '["flatten" :-> (Bool :! 'R)] (Either Tree
[Int])
      Actual type: m0 f0 Bool
                   -> (Bool -> m0 (E.Unit m0) (Either Tree [Int]))
                   -> m0 (E.Plus m0 f0 (E.Unit m0)) (Either Tree [Int])
    In a stmt of a 'do' block: flatten <- get (Var :: Var "flatten")
    In the expression:
      do { flatten <- get (Var :: Var "flatten");
           if flatten then return $ Right [i] else return $ Left $ Leaf i }
    In an equation for ?process?:
        process (Leaf i)
          = do { flatten <- get (Var :: Var "flatten");
                 if flatten then return $ Right [...] else return $ Left $
Leaf i }
          where
              (>>=) = (E.>>=)
              (>>) = (E.>>)
              return = E.return
              fail = E.fail

This seems as if data kinds is not able to infer the proper kinds for the
involved types without type signatures.

So adding NoMonomorphismRestriction does seem to solve some problems, but
adding parameters does not seem to be a solution to the problems related to
the monomorphism restriction.

Any advice?

Best,
Jan

2015-10-28 2:31 GMT+00:00 Chris Wong <lambda.fairy at gmail.com>:

> Hi Jan,
>
> Looks like the monomorphism restriction to me. This article [1] is a
> great explanation of this quirk.
>
> [1]
> http://lambda.jstolarek.com/2012/05/towards-understanding-haskells-monomorphism-restriction/
>
> There are two solutions:
>
> 1. Add {-# LANGUAGE NoMonomorphismRestriction #-} to your code.
>
> 2. Give each binding explicit arguments:
>
>         process = ...  -- as before
>           where
>             m >>= k = m E.>>= k
>             m >> n = m E.>> n
>             return x = E.return x
>
>    Since the monomorphism restriction doesn't apply to declarations
> with arguments, this change should make the bindings polymorphic
> again.
>
> Hope this helps.
>
> On Wed, Oct 28, 2015 at 3:14 AM, Jan Bracker <jan.bracker at googlemail.com>
> wrote:
> > Hello,
> >
> > I am currently playing around with RebindableSyntax and having several
> > bind/return/sequence functions in scope at the same time. I thought that
> it
> > would be enough to just pick the right one to use in each do-block by
> using
> > a "where" or a "let".
> > Surprisingly, I get some type related issues I can only fix by adding in
> > some type signatures, but I don't understand why these signatures are
> > actually necessary.
> >
> > Here is my example program:
> >
> > {-# LANGUAGE RebindableSyntax #-}
> > {-# LANGUAGE DataKinds #-}
> > {-# LANGUAGE TypeOperators #-}
> >
> > import Prelude
> > import qualified Prelude as P
> > import qualified Control.Effect as E
> > import Control.Effect.State
> >
> > ifThenElse :: Bool -> a -> a -> a
> > ifThenElse True  t e = t
> > ifThenElse False t e = e
> >
> > main :: IO ()
> > main = do
> >   return ()
> >   where
> >     return = P.return
> >
> > data Tree = Leaf Int
> >           | Branch Tree Tree
> >
> > process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree
> [Int])
> > process (Leaf i) = do
> >   flatten <- get (Var :: (Var "flatten"))
> >   if flatten
> >     then return $ Right [i]
> >     else return $ Left $ Leaf i
> >   where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) ->
> > State (E.Plus State f g) b
> >         (>>=) = (E.>>=)
> >         (>>) :: (E.Inv State f g) => State f a -> State g b -> State
> (E.Plus
> > State f g) b
> >         (>>) = (E.>>)
> >         return = E.return
> >         fail = E.fail
> > process (Branch tl tr) = do
> >   eitherL <- process tl
> >   eitherR <- process tr
> >   case (eitherL, eitherR) of
> >     (Left  l, Left  r) -> return $ Left  $ Branch l r
> >     (Right l, Right r) -> return $ Right $ l ++ r
> >   where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) ->
> State
> > (E.Plus State f g) b
> >         (>>=) = (E.>>=)
> >         (>>) :: (E.Inv State f g) => State f a -> State g b -> State
> (E.Plus
> > State f g) b
> >         (>>) = (E.>>)
> >         return = E.return
> >         fail = E.fail
> >
> > The program uses the "effect-monad" package in version 0.6.1.
> >
> > 1) The type signatures in the "where" following each do-block of the
> > "process" function are required. If I remove the type signature of the
> > sequence functions I get a type error of the following nature:
> >
> > examples/effect/Test.hs:33:16:
> >     Could not deduce (E.Inv m0 f0 g0) arising from a use of ?E.>>?
> >     Relevant bindings include
> >       (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b
> >         (bound at examples/effect/Test.hs:33:9)
> >     In the expression: (E.>>)
> >     In an equation for ?>>?: (>>) = (E.>>)
> >     In an equation for ?process?:
> >         process (Leaf i)
> >           = do { flatten <- get (Var :: Var "flatten");
> >                  if flatten then return $ Right [...] else return $ Left
> $
> > Leaf i }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) = (E.>>)
> >               return = E.return
> >               fail = E.fail
> >
> > examples/effect/Test.hs:33:16:
> >     No instance for (E.Effect m0) arising from a use of ?E.>>?
> >     In the expression: (E.>>)
> >     In an equation for ?>>?: (>>) = (E.>>)
> >     In an equation for ?process?:
> >         process (Leaf i)
> >           = do { flatten <- get (Var :: Var "flatten");
> >                  if flatten then return $ Right [...] else return $ Left
> $
> > Leaf i }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) = (E.>>)
> >               return = E.return
> >               fail = E.fail
> >
> > Which I interpret as the inability to infer the "E.Effect" and "E.Inv"
> > constraints that are implied by the use of "E.>>". But why can't those
> > constraints be inferred correctly? Shouldn't a definition like "(>>) =
> > (E.>>)" just propagate the type signature and specialize it as needed?
> >
> > 2) If I remove the type signature for the bind operation, I get the
> > following type error:
> >
> > examples/effect/Test.hs:38:3:
> >     Couldn't match type ?'["flatten" :-> (Bool :! 'R)]? with ?'[]?
> >     Expected type: State
> >                      '["flatten" :-> (Bool :! 'R)] (Either Tree [Int])
> >                    -> (Either Tree [Int] -> State '[] (Either Tree
> [Int]))
> >                    -> State '[] (Either Tree [Int])
> >       Actual type: State
> >                      '["flatten" :-> (Bool :! 'R)] (Either Tree [Int])
> >                    -> (Either Tree [Int] -> State '[] (Either Tree
> [Int]))
> >                    -> State
> >                         (E.Plus State '["flatten" :-> (Bool :! 'R)] '[])
> >                         (Either Tree [Int])
> >     In a stmt of a 'do' block: eitherR <- process tr
> >     In the expression:
> >       do { eitherL <- process tl;
> >            eitherR <- process tr;
> >            case (eitherL, eitherR) of {
> >              (Left l, Left r) -> return $ Left $ Branch l r
> >              (Right l, Right r) -> return $ Right $ l ++ r } }
> >     In an equation for ?process?:
> >         process (Branch tl tr)
> >           = do { eitherL <- process tl;
> >                  eitherR <- process tr;
> >                  case (eitherL, eitherR) of {
> >                    (Left l, Left r) -> return $ Left $ Branch l r
> >                    (Right l, Right r) -> return $ Right $ l ++ r } }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) ::
> >                 (E.Inv State f g) =>
> >                 State f a -> State g b -> State (E.Plus State f g) b
> >               (>>) = (E.>>)
> >               return = E.return
> >
> > Which tells me that GHC is expecting the wrong type, but inferring the
> > correct type. Again I don't see why this wrong type is expected and the
> > right type is ignored.
> >
> > In either case, why does adding or removing the type signature for the
> local
> > definitions make a difference at all? I suspect the issue has to do with
> the
> > language extensions I enabled or the type-level computations that are
> done
> > by the "effect-monad" package, but I cannot find a satisfying answer.
> Does
> > anybody have a good explanation?
> >
> > I am working with GHC 7.10.2.
> >
> > Best,
> > Jan
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Chris Wong (https://lambda.xyz)
>
> "I fear that Haskell is doomed to succeed."
>     -- Tony Hoare
>


2015-10-28 2:31 GMT+00:00 Chris Wong <lambda.fairy at gmail.com>:

> Hi Jan,
>
> Looks like the monomorphism restriction to me. This article [1] is a
> great explanation of this quirk.
>
> [1]
> http://lambda.jstolarek.com/2012/05/towards-understanding-haskells-monomorphism-restriction/
>
> There are two solutions:
>
> 1. Add {-# LANGUAGE NoMonomorphismRestriction #-} to your code.
>
> 2. Give each binding explicit arguments:
>
>         process = ...  -- as before
>           where
>             m >>= k = m E.>>= k
>             m >> n = m E.>> n
>             return x = E.return x
>
>    Since the monomorphism restriction doesn't apply to declarations
> with arguments, this change should make the bindings polymorphic
> again.
>
> Hope this helps.
>
> On Wed, Oct 28, 2015 at 3:14 AM, Jan Bracker <jan.bracker at googlemail.com>
> wrote:
> > Hello,
> >
> > I am currently playing around with RebindableSyntax and having several
> > bind/return/sequence functions in scope at the same time. I thought that
> it
> > would be enough to just pick the right one to use in each do-block by
> using
> > a "where" or a "let".
> > Surprisingly, I get some type related issues I can only fix by adding in
> > some type signatures, but I don't understand why these signatures are
> > actually necessary.
> >
> > Here is my example program:
> >
> > {-# LANGUAGE RebindableSyntax #-}
> > {-# LANGUAGE DataKinds #-}
> > {-# LANGUAGE TypeOperators #-}
> >
> > import Prelude
> > import qualified Prelude as P
> > import qualified Control.Effect as E
> > import Control.Effect.State
> >
> > ifThenElse :: Bool -> a -> a -> a
> > ifThenElse True  t e = t
> > ifThenElse False t e = e
> >
> > main :: IO ()
> > main = do
> >   return ()
> >   where
> >     return = P.return
> >
> > data Tree = Leaf Int
> >           | Branch Tree Tree
> >
> > process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree
> [Int])
> > process (Leaf i) = do
> >   flatten <- get (Var :: (Var "flatten"))
> >   if flatten
> >     then return $ Right [i]
> >     else return $ Left $ Leaf i
> >   where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) ->
> > State (E.Plus State f g) b
> >         (>>=) = (E.>>=)
> >         (>>) :: (E.Inv State f g) => State f a -> State g b -> State
> (E.Plus
> > State f g) b
> >         (>>) = (E.>>)
> >         return = E.return
> >         fail = E.fail
> > process (Branch tl tr) = do
> >   eitherL <- process tl
> >   eitherR <- process tr
> >   case (eitherL, eitherR) of
> >     (Left  l, Left  r) -> return $ Left  $ Branch l r
> >     (Right l, Right r) -> return $ Right $ l ++ r
> >   where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) ->
> State
> > (E.Plus State f g) b
> >         (>>=) = (E.>>=)
> >         (>>) :: (E.Inv State f g) => State f a -> State g b -> State
> (E.Plus
> > State f g) b
> >         (>>) = (E.>>)
> >         return = E.return
> >         fail = E.fail
> >
> > The program uses the "effect-monad" package in version 0.6.1.
> >
> > 1) The type signatures in the "where" following each do-block of the
> > "process" function are required. If I remove the type signature of the
> > sequence functions I get a type error of the following nature:
> >
> > examples/effect/Test.hs:33:16:
> >     Could not deduce (E.Inv m0 f0 g0) arising from a use of ?E.>>?
> >     Relevant bindings include
> >       (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b
> >         (bound at examples/effect/Test.hs:33:9)
> >     In the expression: (E.>>)
> >     In an equation for ?>>?: (>>) = (E.>>)
> >     In an equation for ?process?:
> >         process (Leaf i)
> >           = do { flatten <- get (Var :: Var "flatten");
> >                  if flatten then return $ Right [...] else return $ Left
> $
> > Leaf i }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) = (E.>>)
> >               return = E.return
> >               fail = E.fail
> >
> > examples/effect/Test.hs:33:16:
> >     No instance for (E.Effect m0) arising from a use of ?E.>>?
> >     In the expression: (E.>>)
> >     In an equation for ?>>?: (>>) = (E.>>)
> >     In an equation for ?process?:
> >         process (Leaf i)
> >           = do { flatten <- get (Var :: Var "flatten");
> >                  if flatten then return $ Right [...] else return $ Left
> $
> > Leaf i }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) = (E.>>)
> >               return = E.return
> >               fail = E.fail
> >
> > Which I interpret as the inability to infer the "E.Effect" and "E.Inv"
> > constraints that are implied by the use of "E.>>". But why can't those
> > constraints be inferred correctly? Shouldn't a definition like "(>>) =
> > (E.>>)" just propagate the type signature and specialize it as needed?
> >
> > 2) If I remove the type signature for the bind operation, I get the
> > following type error:
> >
> > examples/effect/Test.hs:38:3:
> >     Couldn't match type ?'["flatten" :-> (Bool :! 'R)]? with ?'[]?
> >     Expected type: State
> >                      '["flatten" :-> (Bool :! 'R)] (Either Tree [Int])
> >                    -> (Either Tree [Int] -> State '[] (Either Tree
> [Int]))
> >                    -> State '[] (Either Tree [Int])
> >       Actual type: State
> >                      '["flatten" :-> (Bool :! 'R)] (Either Tree [Int])
> >                    -> (Either Tree [Int] -> State '[] (Either Tree
> [Int]))
> >                    -> State
> >                         (E.Plus State '["flatten" :-> (Bool :! 'R)] '[])
> >                         (Either Tree [Int])
> >     In a stmt of a 'do' block: eitherR <- process tr
> >     In the expression:
> >       do { eitherL <- process tl;
> >            eitherR <- process tr;
> >            case (eitherL, eitherR) of {
> >              (Left l, Left r) -> return $ Left $ Branch l r
> >              (Right l, Right r) -> return $ Right $ l ++ r } }
> >     In an equation for ?process?:
> >         process (Branch tl tr)
> >           = do { eitherL <- process tl;
> >                  eitherR <- process tr;
> >                  case (eitherL, eitherR) of {
> >                    (Left l, Left r) -> return $ Left $ Branch l r
> >                    (Right l, Right r) -> return $ Right $ l ++ r } }
> >           where
> >               (>>=) = (E.>>=)
> >               (>>) ::
> >                 (E.Inv State f g) =>
> >                 State f a -> State g b -> State (E.Plus State f g) b
> >               (>>) = (E.>>)
> >               return = E.return
> >
> > Which tells me that GHC is expecting the wrong type, but inferring the
> > correct type. Again I don't see why this wrong type is expected and the
> > right type is ignored.
> >
> > In either case, why does adding or removing the type signature for the
> local
> > definitions make a difference at all? I suspect the issue has to do with
> the
> > language extensions I enabled or the type-level computations that are
> done
> > by the "effect-monad" package, but I cannot find a satisfying answer.
> Does
> > anybody have a good explanation?
> >
> > I am working with GHC 7.10.2.
> >
> > Best,
> > Jan
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Chris Wong (https://lambda.xyz)
>
> "I fear that Haskell is doomed to succeed."
>     -- Tony Hoare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/c81882e0/attachment.html>

From ekmett at gmail.com  Mon Nov  2 18:13:06 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 2 Nov 2015 13:13:06 -0500
Subject: [Haskell-cafe] process package with compilers besides GHC
In-Reply-To: <CAKA2JgLjSbCS40J0mHTdL1kqYqykHCSqw5Fp4-6EtPEzRci_zA@mail.gmail.com>
References: <CAKA2JgLjSbCS40J0mHTdL1kqYqykHCSqw5Fp4-6EtPEzRci_zA@mail.gmail.com>
Message-ID: <A9898B29-9295-46FD-B821-3F2985A12479@gmail.com>

I'd be (pleasantly) surprised to find any other compiler building with it. A couple of years back folks took an axe to similar untested and untestable legacy code paths in base.

-Edward

> On Nov 2, 2015, at 11:10 AM, Michael Snoyman <michael at snoyman.com> wrote:
> 
> I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that:
> 
> 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers
> 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC
> 
> I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals.
> 
> * No pun intend
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From lemming at henning-thielemann.de  Mon Nov  2 18:20:25 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 2 Nov 2015 19:20:25 +0100 (CET)
Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax
 sometimes requires type signatures?
In-Reply-To: <CANEwrkQrjxb9RmAY_bgkaG38JvkCPh=QuyA4NVPWb2-oHgUU4g@mail.gmail.com>
References: <CANEwrkTrtf3OquRGCe6+V48=pSGWq-77L8wUSGCDn96hseA4Cw@mail.gmail.com>
 <CANQO64JVMyP+yWj-_TcHeGr2mXRA2aoZn-dcUrAC1jB_6MwrvQ@mail.gmail.com>
 <CANEwrkQrjxb9RmAY_bgkaG38JvkCPh=QuyA4NVPWb2-oHgUU4g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1511021919040.7828@sputnik>


On Mon, 2 Nov 2015, Jan Bracker wrote:

> If I add arguments to my local definitions I get the following errors:
> 
> Main.hs:27:3:
> ? ? Couldn't match kind ?*? with ?[*]?
> ? ? When matching types
> ? ? ? m0 :: * -> * -> *
> ? ? ? State :: [*] -> * -> *


That sounds like a serious type mismatch that cannot simply be avoided by 
adding type signatures or type extensions.

From jan.bracker at googlemail.com  Mon Nov  2 18:23:14 2015
From: jan.bracker at googlemail.com (Jan Bracker)
Date: Mon, 2 Nov 2015 18:23:14 +0000
Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax
 sometimes requires type signatures?
In-Reply-To: <alpine.DEB.2.02.1511021919040.7828@sputnik>
References: <CANEwrkTrtf3OquRGCe6+V48=pSGWq-77L8wUSGCDn96hseA4Cw@mail.gmail.com>
 <CANQO64JVMyP+yWj-_TcHeGr2mXRA2aoZn-dcUrAC1jB_6MwrvQ@mail.gmail.com>
 <CANEwrkQrjxb9RmAY_bgkaG38JvkCPh=QuyA4NVPWb2-oHgUU4g@mail.gmail.com>
 <alpine.DEB.2.02.1511021919040.7828@sputnik>
Message-ID: <CANEwrkSz7DGXeFBKug-kTbYSJgbbCprNVO-xwNHZsEXVBfMf7g@mail.gmail.com>

Hi Henning,

but with type signatures the errors do not occure.

My best guess for that one is that inferring the correct kinds for lifted
data types is not done properly.

Best,
Jan

2015-11-02 18:20 GMT+00:00 Henning Thielemann <lemming at henning-thielemann.de
>:

>
> On Mon, 2 Nov 2015, Jan Bracker wrote:
>
> If I add arguments to my local definitions I get the following errors:
>>
>> Main.hs:27:3:
>>     Couldn't match kind ?*? with ?[*]?
>>     When matching types
>>       m0 :: * -> * -> *
>>       State :: [*] -> * -> *
>>
>
>
> That sounds like a serious type mismatch that cannot simply be avoided by
> adding type signatures or type extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/67fc73ef/attachment.html>

From lemming at henning-thielemann.de  Mon Nov  2 18:33:03 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 2 Nov 2015 19:33:03 +0100 (CET)
Subject: [Haskell-cafe] Why does disambiguation in RebindableSyntax
 sometimes requires type signatures?
In-Reply-To: <CANEwrkSz7DGXeFBKug-kTbYSJgbbCprNVO-xwNHZsEXVBfMf7g@mail.gmail.com>
References: <CANEwrkTrtf3OquRGCe6+V48=pSGWq-77L8wUSGCDn96hseA4Cw@mail.gmail.com>
 <CANQO64JVMyP+yWj-_TcHeGr2mXRA2aoZn-dcUrAC1jB_6MwrvQ@mail.gmail.com>
 <CANEwrkQrjxb9RmAY_bgkaG38JvkCPh=QuyA4NVPWb2-oHgUU4g@mail.gmail.com>
 <alpine.DEB.2.02.1511021919040.7828@sputnik>
 <CANEwrkSz7DGXeFBKug-kTbYSJgbbCprNVO-xwNHZsEXVBfMf7g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1511021928020.7828@sputnik>


On Mon, 2 Nov 2015, Jan Bracker wrote:

> Hi Henning,
> but with type signatures the errors do not occure.
> 
> My best guess for that one is that inferring the correct kinds for lifted data types is not done properly.

I have not followed the previous conversation. A general problem is that 
if a top-level function misses a type signature then GHC might choose a 
type that is too special, such that it fits one call site but mismatches 
another one. It is always a good idea to add type-signatures to top-level 
functions. If your problem occurs with local functions and you can solve 
it with a type signature then I think this is the way to go.

From douglas.mcclean at gmail.com  Mon Nov  2 19:38:50 2015
From: douglas.mcclean at gmail.com (Douglas McClean)
Date: Mon, 2 Nov 2015 14:38:50 -0500
Subject: [Haskell-cafe] ANN: dimensional-1.0 for statically checked physical
	dimensions
Message-ID: <CACruqwTAm4kVPBfRYGHnDxFb7kBos26yHwXGTko8QQztUQGJ5A@mail.gmail.com>

Hello Haskellers,
Bj?rn Buckwalter and I are pleased to announce the release to Hackage of
version 1.0 of the dimensional library, which statically tracks physical
dimensions in Haskell code, as in the example below, preventing dimensional
mistakes and requiring explicit documentation of units where raw values are
exchanged with external systems.

{-# LANGUAGE NoImplicitPrelude #-}
module Example where

import Numeric.Units.Dimensional.Prelude
import Numeric.Units.Dimensional.NonSI

-- a function that computes with dimensional values
escapeVelocity :: (Floating a) => Mass a -> Length a -> Velocity a
escapeVelocity m r = sqrt (two * g * m / r)
  where
      two = 2 *~ one
      g = 6.6720e-11 *~ (newton * meter ^ pos2 / kilo gram ^ pos2)

>>> let re = 6372.792 *~ kilo meter
>>> let me = 5.9742e24 *~ kilo gram
>>> let ve = escapeVelocity me re
>>> ve -- Show defaults to SI base units
11184.537332296259 m s^-1
>>> showIn (mile / hour) ve -- but we can show in other units
"25019.09746845083 mi / h"
>>> let vekph = ve /~ (kilo meter / hour) -- and extract raw values when
needed
40264.33439626653

This version is a major upgrade, consolidating features from the classic
dimensional package and the dimensional-tf package. It takes advantage of
the DataKinds and ClosedTypeFamilies extensions in GHC 7.8 to offer even
safer types with a nearly identical interface.

Also included:

   - Units carry names which can be combined by multiplication, division,
   and (only where appropriate) application of metric prefixes. You can use
   expressions like: showIn (milli meter / second) timeTravelSpeed to get
   "39339.52 mm / s"
   - Exact conversion factors between units are available, even when those
   conversion factors involve multiples of pi, thanks to the exact-pi library
   - The dimensionally-polymorphic siUnit term represents the coherent SI
   base unit of any dimension, which can be convenient for wrapping and
   unwrapping quantities in some contexts.
   - Storable and Unbox instances for Quantity types are available thanks
   to the efforts of Alberto Valverde Gonz?lez.
   - The Numeric.Units.Dimensional.Dynamic module offers types for safely
   manipulating quantities and units whose dimensions are not known
   statically. Also available is a term-level representation for dimensions.
   - Several other missing instances have been provided, including Bounded,
   Data, and Typeable instances.
   - New commonly used US customary units have been added, including US
   fluid measures and the knot.

We have several other development efforts underway, including a
type-checker plugin inspired by Adam Gundry's work, and on which he has
provided valuable advice, which we hope will lead to a clean library for
dimensionally typed linear algebra.

Comments and contributions are welcome at
http://github.com/bjornbm/dimensional-dk. (The repository name is a
carryover from the name we were using while developing this version.)

One particularly welcome contribution would be assistance with developing a
patch for GHC issue 10391 <https://ghc.haskell.org/trac/ghc/ticket/10391>.

Cheers,
Doug McClean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/8c276343/attachment.html>

From lemming at henning-thielemann.de  Mon Nov  2 19:49:09 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Mon, 2 Nov 2015 20:49:09 +0100 (CET)
Subject: [Haskell-cafe] exact-pi (Was: ANN: dimensional-1.0 for statically
 checked physical dimensions)
In-Reply-To: <CACruqwTAm4kVPBfRYGHnDxFb7kBos26yHwXGTko8QQztUQGJ5A@mail.gmail.com>
References: <CACruqwTAm4kVPBfRYGHnDxFb7kBos26yHwXGTko8QQztUQGJ5A@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1511022047090.7828@sputnik>


On Mon, 2 Nov 2015, Douglas McClean wrote:

>  *  Exact conversion factors between units are available, even when those conversion factors involve multiples of pi,
>     thanks to the exact-pi library


Since pi is transcendental with respect to the rational numbers, I can use 
exact-pi for any other transcendental number, can't I?

From douglas.mcclean at gmail.com  Mon Nov  2 19:56:57 2015
From: douglas.mcclean at gmail.com (Douglas McClean)
Date: Mon, 2 Nov 2015 14:56:57 -0500
Subject: [Haskell-cafe] exact-pi (Was: ANN: dimensional-1.0 for
 statically checked physical dimensions)
In-Reply-To: <alpine.DEB.2.02.1511022047090.7828@sputnik>
References: <CACruqwTAm4kVPBfRYGHnDxFb7kBos26yHwXGTko8QQztUQGJ5A@mail.gmail.com>
 <alpine.DEB.2.02.1511022047090.7828@sputnik>
Message-ID: <CACruqwR-sayBtu2UpD-yp8Teuef0VaNEB=EuORzPoKk2dAzRHQ@mail.gmail.com>

Henning,

Yes, if you wish. However you might run into surprises because the Floating
class defines pi polymorphically, and the Floating instance for ExactPi
uses exactly pi. We are also considering adding exact evaluation of
trignonmetric functions at those points in the domain that can be exactly
represented. As long as you are aware of this issue you can use it for any
other transcendental function you might be more interested in.

You could also consider copying the entire thing but changing the:

instance Floating ExactPi where
  pi = Exact 1 1

bit to:

instance Floating ExactSomethingElse where
  pi = Approximate pi

If this related type would be useful to you and you have a suggested name
for it, I can add it to the library?

-Doug

On Mon, Nov 2, 2015 at 2:49 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Mon, 2 Nov 2015, Douglas McClean wrote:
>
>  *  Exact conversion factors between units are available, even when those
>> conversion factors involve multiples of pi,
>>     thanks to the exact-pi library
>>
>
>
> Since pi is transcendental with respect to the rational numbers, I can use
> exact-pi for any other transcendental number, can't I?
>



-- 
J. Douglas McClean

(781) 561-5540 (cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/987043de/attachment.html>

From charles at voleon.com  Mon Nov  2 20:08:12 2015
From: charles at voleon.com (Charles Weitzer)
Date: Mon, 2 Nov 2015 20:08:12 +0000
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning Group
Message-ID: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>

Voleon Capital Management LP is a quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible.
Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well.
Here is our formal job description:
**********************************************************
* Senior Software Engineer *
Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems.
The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages.
We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus.
We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential.
Required experience:
- strong experience developing in a functional programming environment (Haskell, Erlang, others).
- developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness.
- working in TCP/IP networking, multi-threading, and server development.
- working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.).
- architecting and designing highly available systems.
- architecting and designing large-scale data management infrastructure.
- working in large codebases and building modular, manageable code.
Preferred experience.:
- debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc.
- working with build and test automation tools.
- working with well-defined change management processes.
- diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc.
- working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems.
Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring.
Benefits and compensation are highly competitive.
**********************************************************
The above job description is just a starting point in terms of possible duties and seniority.  We can be very flexible for the right person.
If you are interested please apply on our website: http://voleon.com/apply/.
If you have any questions or  if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details.
Thank you,

Charles Weitzer
Senior Recruiter
Voleon Capital Management LP
Office: 510.704.9870 x 7012
Mobile: (510) 558-9182
www.Voleon.com<http://www.voleon.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/9da0c472/attachment-0001.html>

From ratzes at gmail.com  Mon Nov  2 20:12:08 2015
From: ratzes at gmail.com (Charles Durham)
Date: Mon, 2 Nov 2015 15:12:08 -0500
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
Message-ID: <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>

Nothing in the description (aside from the subject line) says that the
engineer would be developing in Haskell. The C/C++/Python/Go to me
indicates this has no business being posted here. Am I wrong?

Charles Durham

On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com> wrote:

> Voleon Capital Management LP is a quantitative hedge fund located in
> Berkeley, California. We would like to hire a senior software engineer with
> strong functional programming experience as soon as possible.
>
> Voleon?s founders previously worked together at one of the most successful
> quantitative hedge funds in the world. Our CEO has a PhD in Computer
> Science from Stanford and has been CEO and founder of a successful Internet
> infrastructure startup. Our Chief Investment Officer has a PhD in
> Statistics from Berkeley. Voleon?s team includes PhD's from leading
> departments in statistics, computer science, and mathematics. We have made
> several unpublished advances in the field of machine learning and in other
> areas as well.
>
> Here is our formal job description:
>
> **********************************************************
>
> * Senior Software Engineer *
>
> Technology-driven investment firm employing cutting-edge
> statistical machine learning techniques seeks an exceptionally capable
> software engineer. You will architect and implement new production trading
> systems, machine learning infrastructure, data integration pipelines,
> and large-scale storage systems.
>
> The firm researches and deploys systematic trading strategies designed
> to generate attractive returns without being dependent on the performance
> of the overall market. Join a team of under 30 people that includes a
> Berkeley statistics professor as well as over ten PhD's from Berkeley,
> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
> CEO of a successful Internet infrastructure technology firm. The firm?s
> offices are walking distance from BART and the UC Berkeley campus in
> downtown Berkeley, California. We have a casual and collegial office
> environment, catered lunches, and competitive benefits packages.
>
> We seek candidates with a proven track record of writing
> correct, well-designed software, solving hard problems, and delivering
> complex projects on time. You should preferably have experience designing
> and implementing fault-tolerant distributed systems. Experience with
> building large-scale data infrastructure, stream processing systems,
> or latency-sensitive programs is a bonus.
>
> We are growing rapidly. Willingness to take initiative and a
> gritty determination to productize are essential.
>
> Required experience:
>
> - strong experience developing in a functional programming environment
> (Haskell, Erlang, others).
>
> - developing with C/C++/Python/Go in a Linux environment with a focus
> on performance, concurrency, and correctness.
> - working in TCP/IP networking, multi-threading, and server development.
> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
> SNMP, etc.).
> - architecting and designing highly available systems.
> - architecting and designing large-scale data management infrastructure.
> - working in large codebases and building modular, manageable code.
>
> Preferred experience.:
>
> - debugging and performance profiling, including the use of tools such
> as strace, valgrind, gdb, tcpdump, etc.
> - working with build and test automation tools.
> - working with well-defined change management processes.
> - diagnosing RDBMS performance problems, exploiting indexing, using
> EXPLAIN PLAN, optimizing at the code layer, etc.
> - working with messaging queues (RabbitMQ, Redis, etc.) as well
> as distributed caching systems.
>
> Interest in financial applications is essential, but experience in
> finance is not a primary factor in our hiring.
>
> Benefits and compensation are highly competitive.
>
> **********************************************************
>
> The above job description is just a starting point in terms of possible
> duties and seniority.  We can be very flexible for the right person.
>
> If you are interested please apply on our website:
> http://voleon.com/apply/.
>
> If you have any questions or  if you know of anyone who might be
> interested, let us know the best way to get in touch and we can discuss
> details.
>
> Thank you,
>
>
>
> Charles Weitzer
>
> Senior Recruiter
>
> Voleon Capital Management LP
> Office: 510.704.9870 x 7012
>
> Mobile: (510) 558-9182
>
> www.Voleon.com <http://www.voleon.com/>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/58655233/attachment.html>

From cma at bitemyapp.com  Mon Nov  2 20:15:01 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Nov 2015 14:15:01 -0600
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
Message-ID: <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>

To your point,

>- strong experience developing in a functional programming environment
(Haskell, Erlang, others).

is usually a dog-whistle for "we want better than average programmers but
we're going to make them use tools that'll make them less effective and
less happy"


On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:

> Nothing in the description (aside from the subject line) says that the
> engineer would be developing in Haskell. The C/C++/Python/Go to me
> indicates this has no business being posted here. Am I wrong?
>
> Charles Durham
>
> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
> wrote:
>
>> Voleon Capital Management LP is a quantitative hedge fund located in
>> Berkeley, California. We would like to hire a senior software engineer with
>> strong functional programming experience as soon as possible.
>>
>> Voleon?s founders previously worked together at one of the most
>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>> Computer Science from Stanford and has been CEO and founder of a successful
>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>> departments in statistics, computer science, and mathematics. We have made
>> several unpublished advances in the field of machine learning and in other
>> areas as well.
>>
>> Here is our formal job description:
>>
>> **********************************************************
>>
>> * Senior Software Engineer *
>>
>> Technology-driven investment firm employing cutting-edge
>> statistical machine learning techniques seeks an exceptionally capable
>> software engineer. You will architect and implement new production trading
>> systems, machine learning infrastructure, data integration pipelines,
>> and large-scale storage systems.
>>
>> The firm researches and deploys systematic trading strategies designed
>> to generate attractive returns without being dependent on the performance
>> of the overall market. Join a team of under 30 people that includes a
>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>> CEO of a successful Internet infrastructure technology firm. The firm?s
>> offices are walking distance from BART and the UC Berkeley campus in
>> downtown Berkeley, California. We have a casual and collegial office
>> environment, catered lunches, and competitive benefits packages.
>>
>> We seek candidates with a proven track record of writing
>> correct, well-designed software, solving hard problems, and delivering
>> complex projects on time. You should preferably have experience designing
>> and implementing fault-tolerant distributed systems. Experience with
>> building large-scale data infrastructure, stream processing systems,
>> or latency-sensitive programs is a bonus.
>>
>> We are growing rapidly. Willingness to take initiative and a
>> gritty determination to productize are essential.
>>
>> Required experience:
>>
>> - strong experience developing in a functional programming environment
>> (Haskell, Erlang, others).
>>
>> - developing with C/C++/Python/Go in a Linux environment with a focus
>> on performance, concurrency, and correctness.
>> - working in TCP/IP networking, multi-threading, and server development.
>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>> SNMP, etc.).
>> - architecting and designing highly available systems.
>> - architecting and designing large-scale data management infrastructure.
>> - working in large codebases and building modular, manageable code.
>>
>> Preferred experience.:
>>
>> - debugging and performance profiling, including the use of tools such
>> as strace, valgrind, gdb, tcpdump, etc.
>> - working with build and test automation tools.
>> - working with well-defined change management processes.
>> - diagnosing RDBMS performance problems, exploiting indexing, using
>> EXPLAIN PLAN, optimizing at the code layer, etc.
>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>> as distributed caching systems.
>>
>> Interest in financial applications is essential, but experience in
>> finance is not a primary factor in our hiring.
>>
>> Benefits and compensation are highly competitive.
>>
>> **********************************************************
>>
>> The above job description is just a starting point in terms of possible
>> duties and seniority.  We can be very flexible for the right person.
>>
>> If you are interested please apply on our website:
>> http://voleon.com/apply/.
>>
>> If you have any questions or  if you know of anyone who might be
>> interested, let us know the best way to get in touch and we can discuss
>> details.
>>
>> Thank you,
>>
>>
>>
>> Charles Weitzer
>>
>> Senior Recruiter
>>
>> Voleon Capital Management LP
>> Office: 510.704.9870 x 7012
>>
>> Mobile: (510) 558-9182
>>
>> www.Voleon.com <http://www.voleon.com/>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/22307e10/attachment.html>

From ratzes at gmail.com  Mon Nov  2 20:25:29 2015
From: ratzes at gmail.com (Charles Durham)
Date: Mon, 2 Nov 2015 15:25:29 -0500
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
Message-ID: <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>

Yeah, that's what I was thinking, not a bad recruiting strategy though

On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com> wrote:

> To your point,
>
> >- strong experience developing in a functional programming environment
> (Haskell, Erlang, others).
>
> is usually a dog-whistle for "we want better than average programmers but
> we're going to make them use tools that'll make them less effective and
> less happy"
>
>
> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>
>> Nothing in the description (aside from the subject line) says that the
>> engineer would be developing in Haskell. The C/C++/Python/Go to me
>> indicates this has no business being posted here. Am I wrong?
>>
>> Charles Durham
>>
>> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
>> wrote:
>>
>>> Voleon Capital Management LP is a quantitative hedge fund located in
>>> Berkeley, California. We would like to hire a senior software engineer with
>>> strong functional programming experience as soon as possible.
>>>
>>> Voleon?s founders previously worked together at one of the most
>>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>>> Computer Science from Stanford and has been CEO and founder of a successful
>>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>>> departments in statistics, computer science, and mathematics. We have made
>>> several unpublished advances in the field of machine learning and in other
>>> areas as well.
>>>
>>> Here is our formal job description:
>>>
>>> **********************************************************
>>>
>>> * Senior Software Engineer *
>>>
>>> Technology-driven investment firm employing cutting-edge
>>> statistical machine learning techniques seeks an exceptionally capable
>>> software engineer. You will architect and implement new production trading
>>> systems, machine learning infrastructure, data integration pipelines,
>>> and large-scale storage systems.
>>>
>>> The firm researches and deploys systematic trading strategies designed
>>> to generate attractive returns without being dependent on the performance
>>> of the overall market. Join a team of under 30 people that includes a
>>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>>> CEO of a successful Internet infrastructure technology firm. The firm?s
>>> offices are walking distance from BART and the UC Berkeley campus in
>>> downtown Berkeley, California. We have a casual and collegial office
>>> environment, catered lunches, and competitive benefits packages.
>>>
>>> We seek candidates with a proven track record of writing
>>> correct, well-designed software, solving hard problems, and delivering
>>> complex projects on time. You should preferably have experience designing
>>> and implementing fault-tolerant distributed systems. Experience with
>>> building large-scale data infrastructure, stream processing systems,
>>> or latency-sensitive programs is a bonus.
>>>
>>> We are growing rapidly. Willingness to take initiative and a
>>> gritty determination to productize are essential.
>>>
>>> Required experience:
>>>
>>> - strong experience developing in a functional programming environment
>>> (Haskell, Erlang, others).
>>>
>>> - developing with C/C++/Python/Go in a Linux environment with a focus
>>> on performance, concurrency, and correctness.
>>> - working in TCP/IP networking, multi-threading, and server development.
>>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>>> SNMP, etc.).
>>> - architecting and designing highly available systems.
>>> - architecting and designing large-scale data management infrastructure.
>>> - working in large codebases and building modular, manageable code.
>>>
>>> Preferred experience.:
>>>
>>> - debugging and performance profiling, including the use of tools such
>>> as strace, valgrind, gdb, tcpdump, etc.
>>> - working with build and test automation tools.
>>> - working with well-defined change management processes.
>>> - diagnosing RDBMS performance problems, exploiting indexing, using
>>> EXPLAIN PLAN, optimizing at the code layer, etc.
>>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>>> as distributed caching systems.
>>>
>>> Interest in financial applications is essential, but experience in
>>> finance is not a primary factor in our hiring.
>>>
>>> Benefits and compensation are highly competitive.
>>>
>>> **********************************************************
>>>
>>> The above job description is just a starting point in terms of possible
>>> duties and seniority.  We can be very flexible for the right person.
>>>
>>> If you are interested please apply on our website:
>>> http://voleon.com/apply/.
>>>
>>> If you have any questions or  if you know of anyone who might be
>>> interested, let us know the best way to get in touch and we can discuss
>>> details.
>>>
>>> Thank you,
>>>
>>>
>>>
>>> Charles Weitzer
>>>
>>> Senior Recruiter
>>>
>>> Voleon Capital Management LP
>>> Office: 510.704.9870 x 7012
>>>
>>> Mobile: (510) 558-9182
>>>
>>> www.Voleon.com <http://www.voleon.com/>
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/1e6840d6/attachment.html>

From cma at bitemyapp.com  Mon Nov  2 20:45:48 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Nov 2015 14:45:48 -0600
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
Message-ID: <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>

They've done this before (see attachment). If they don't give a straight
answer on whether or not they're actually using Haskell, can they be
blocked from posting to the ML for spam?

On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com> wrote:

> Yeah, that's what I was thinking, not a bad recruiting strategy though
>
> On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
>
>> To your point,
>>
>> >- strong experience developing in a functional programming environment
>> (Haskell, Erlang, others).
>>
>> is usually a dog-whistle for "we want better than average programmers but
>> we're going to make them use tools that'll make them less effective and
>> less happy"
>>
>>
>> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>>
>>> Nothing in the description (aside from the subject line) says that the
>>> engineer would be developing in Haskell. The C/C++/Python/Go to me
>>> indicates this has no business being posted here. Am I wrong?
>>>
>>> Charles Durham
>>>
>>> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
>>> wrote:
>>>
>>>> Voleon Capital Management LP is a quantitative hedge fund located in
>>>> Berkeley, California. We would like to hire a senior software engineer with
>>>> strong functional programming experience as soon as possible.
>>>>
>>>> Voleon?s founders previously worked together at one of the most
>>>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>>>> Computer Science from Stanford and has been CEO and founder of a successful
>>>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>>>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>>>> departments in statistics, computer science, and mathematics. We have made
>>>> several unpublished advances in the field of machine learning and in other
>>>> areas as well.
>>>>
>>>> Here is our formal job description:
>>>>
>>>> **********************************************************
>>>>
>>>> * Senior Software Engineer *
>>>>
>>>> Technology-driven investment firm employing cutting-edge
>>>> statistical machine learning techniques seeks an exceptionally capable
>>>> software engineer. You will architect and implement new production trading
>>>> systems, machine learning infrastructure, data integration pipelines,
>>>> and large-scale storage systems.
>>>>
>>>> The firm researches and deploys systematic trading strategies designed
>>>> to generate attractive returns without being dependent on the performance
>>>> of the overall market. Join a team of under 30 people that includes a
>>>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>>>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>>>> CEO of a successful Internet infrastructure technology firm. The firm?s
>>>> offices are walking distance from BART and the UC Berkeley campus in
>>>> downtown Berkeley, California. We have a casual and collegial office
>>>> environment, catered lunches, and competitive benefits packages.
>>>>
>>>> We seek candidates with a proven track record of writing
>>>> correct, well-designed software, solving hard problems, and delivering
>>>> complex projects on time. You should preferably have experience designing
>>>> and implementing fault-tolerant distributed systems. Experience with
>>>> building large-scale data infrastructure, stream processing systems,
>>>> or latency-sensitive programs is a bonus.
>>>>
>>>> We are growing rapidly. Willingness to take initiative and a
>>>> gritty determination to productize are essential.
>>>>
>>>> Required experience:
>>>>
>>>> - strong experience developing in a functional programming environment
>>>> (Haskell, Erlang, others).
>>>>
>>>> - developing with C/C++/Python/Go in a Linux environment with a focus
>>>> on performance, concurrency, and correctness.
>>>> - working in TCP/IP networking, multi-threading, and server development.
>>>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>>>> SNMP, etc.).
>>>> - architecting and designing highly available systems.
>>>> - architecting and designing large-scale data management infrastructure.
>>>> - working in large codebases and building modular, manageable code.
>>>>
>>>> Preferred experience.:
>>>>
>>>> - debugging and performance profiling, including the use of tools such
>>>> as strace, valgrind, gdb, tcpdump, etc.
>>>> - working with build and test automation tools.
>>>> - working with well-defined change management processes.
>>>> - diagnosing RDBMS performance problems, exploiting indexing, using
>>>> EXPLAIN PLAN, optimizing at the code layer, etc.
>>>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>>>> as distributed caching systems.
>>>>
>>>> Interest in financial applications is essential, but experience in
>>>> finance is not a primary factor in our hiring.
>>>>
>>>> Benefits and compensation are highly competitive.
>>>>
>>>> **********************************************************
>>>>
>>>> The above job description is just a starting point in terms of possible
>>>> duties and seniority.  We can be very flexible for the right person.
>>>>
>>>> If you are interested please apply on our website:
>>>> http://voleon.com/apply/.
>>>>
>>>> If you have any questions or  if you know of anyone who might be
>>>> interested, let us know the best way to get in touch and we can discuss
>>>> details.
>>>>
>>>> Thank you,
>>>>
>>>>
>>>>
>>>> Charles Weitzer
>>>>
>>>> Senior Recruiter
>>>>
>>>> Voleon Capital Management LP
>>>> Office: 510.704.9870 x 7012
>>>>
>>>> Mobile: (510) 558-9182
>>>>
>>>> www.Voleon.com <http://www.voleon.com/>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>>
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/8697ffbd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-11-02 14:45:01.png
Type: image/png
Size: 136639 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/8697ffbd/attachment-0001.png>

From cma at bitemyapp.com  Mon Nov  2 20:48:25 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Nov 2015 14:48:25 -0600
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
Message-ID: <CADnndOq7cvOCTHB=iFGGqtQTnqNXXU1Td+URDv+2-EVEUKbGXQ@mail.gmail.com>

Point in favor at least some Haskell use occurring is that there is at
least one very active Haskeller at Voleon.

On Mon, Nov 2, 2015 at 2:45 PM, Christopher Allen <cma at bitemyapp.com> wrote:

> They've done this before (see attachment). If they don't give a straight
> answer on whether or not they're actually using Haskell, can they be
> blocked from posting to the ML for spam?
>
> On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com> wrote:
>
>> Yeah, that's what I was thinking, not a bad recruiting strategy though
>>
>> On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com>
>> wrote:
>>
>>> To your point,
>>>
>>> >- strong experience developing in a functional programming environment
>>> (Haskell, Erlang, others).
>>>
>>> is usually a dog-whistle for "we want better than average programmers
>>> but we're going to make them use tools that'll make them less effective and
>>> less happy"
>>>
>>>
>>> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>>>
>>>> Nothing in the description (aside from the subject line) says that the
>>>> engineer would be developing in Haskell. The C/C++/Python/Go to me
>>>> indicates this has no business being posted here. Am I wrong?
>>>>
>>>> Charles Durham
>>>>
>>>> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
>>>> wrote:
>>>>
>>>>> Voleon Capital Management LP is a quantitative hedge fund located in
>>>>> Berkeley, California. We would like to hire a senior software engineer with
>>>>> strong functional programming experience as soon as possible.
>>>>>
>>>>> Voleon?s founders previously worked together at one of the most
>>>>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>>>>> Computer Science from Stanford and has been CEO and founder of a successful
>>>>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>>>>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>>>>> departments in statistics, computer science, and mathematics. We have made
>>>>> several unpublished advances in the field of machine learning and in other
>>>>> areas as well.
>>>>>
>>>>> Here is our formal job description:
>>>>>
>>>>> **********************************************************
>>>>>
>>>>> * Senior Software Engineer *
>>>>>
>>>>> Technology-driven investment firm employing cutting-edge
>>>>> statistical machine learning techniques seeks an exceptionally capable
>>>>> software engineer. You will architect and implement new production trading
>>>>> systems, machine learning infrastructure, data integration pipelines,
>>>>> and large-scale storage systems.
>>>>>
>>>>> The firm researches and deploys systematic trading strategies designed
>>>>> to generate attractive returns without being dependent on the performance
>>>>> of the overall market. Join a team of under 30 people that includes a
>>>>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>>>>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>>>>> CEO of a successful Internet infrastructure technology firm. The firm?s
>>>>> offices are walking distance from BART and the UC Berkeley campus in
>>>>> downtown Berkeley, California. We have a casual and collegial office
>>>>> environment, catered lunches, and competitive benefits packages.
>>>>>
>>>>> We seek candidates with a proven track record of writing
>>>>> correct, well-designed software, solving hard problems, and delivering
>>>>> complex projects on time. You should preferably have experience designing
>>>>> and implementing fault-tolerant distributed systems. Experience with
>>>>> building large-scale data infrastructure, stream processing systems,
>>>>> or latency-sensitive programs is a bonus.
>>>>>
>>>>> We are growing rapidly. Willingness to take initiative and a
>>>>> gritty determination to productize are essential.
>>>>>
>>>>> Required experience:
>>>>>
>>>>> - strong experience developing in a functional programming environment
>>>>> (Haskell, Erlang, others).
>>>>>
>>>>> - developing with C/C++/Python/Go in a Linux environment with a focus
>>>>> on performance, concurrency, and correctness.
>>>>> - working in TCP/IP networking, multi-threading, and server
>>>>> development.
>>>>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>>>>> SNMP, etc.).
>>>>> - architecting and designing highly available systems.
>>>>> - architecting and designing large-scale data management
>>>>> infrastructure.
>>>>> - working in large codebases and building modular, manageable code.
>>>>>
>>>>> Preferred experience.:
>>>>>
>>>>> - debugging and performance profiling, including the use of tools such
>>>>> as strace, valgrind, gdb, tcpdump, etc.
>>>>> - working with build and test automation tools.
>>>>> - working with well-defined change management processes.
>>>>> - diagnosing RDBMS performance problems, exploiting indexing, using
>>>>> EXPLAIN PLAN, optimizing at the code layer, etc.
>>>>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>>>>> as distributed caching systems.
>>>>>
>>>>> Interest in financial applications is essential, but experience in
>>>>> finance is not a primary factor in our hiring.
>>>>>
>>>>> Benefits and compensation are highly competitive.
>>>>>
>>>>> **********************************************************
>>>>>
>>>>> The above job description is just a starting point in terms of
>>>>> possible duties and seniority.  We can be very flexible for the right
>>>>> person.
>>>>>
>>>>> If you are interested please apply on our website:
>>>>> http://voleon.com/apply/.
>>>>>
>>>>> If you have any questions or  if you know of anyone who might be
>>>>> interested, let us know the best way to get in touch and we can discuss
>>>>> details.
>>>>>
>>>>> Thank you,
>>>>>
>>>>>
>>>>>
>>>>> Charles Weitzer
>>>>>
>>>>> Senior Recruiter
>>>>>
>>>>> Voleon Capital Management LP
>>>>> Office: 510.704.9870 x 7012
>>>>>
>>>>> Mobile: (510) 558-9182
>>>>>
>>>>> www.Voleon.com <http://www.voleon.com/>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskell-Cafe at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>>
>>> --
>>> Chris Allen
>>> Currently working on http://haskellbook.com
>>>
>>
>>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/c5deb612/attachment.html>

From charles at voleon.com  Mon Nov  2 21:55:14 2015
From: charles at voleon.com (Charles Weitzer)
Date: Mon, 2 Nov 2015 21:55:14 +0000
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
Message-ID: <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>

What are you talking about?  We have in the past and continue to post to this ML.  We have interviewed people from this list and have flown them in from around the world to interview onsite.  We have one of the top contributors to the Haskell language onsite working for us fulltime.  Please stop guessing about our motives.  We are one of the top machine learning groups in the world.  We need great people, both researchers and programmers, to come help us grow our company.  We have found that people with extensive experience and expertise in Haskell tend to be very good at doing what we need done.


Charles Weitzer

Senior Recruiter
Voleon Capital Management LP
Charles at Voleon.com<mailto:Charles at Voleon.com>
Office: 510.704.9870 x 7012
Mobile: (510) 558-9182
www.Voleon.com<http://www.Voleon.com>



Confidential: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any comments or statements made herein do not necessarily reflect those of The Voleon Group, Voleon Funds LP, Voleon Capital Management LP, and their subsidiaries or affiliates. Please note that this e-mail has been created with the knowledge that Internet e-mail is not a 100% secure communications medium. We advise that you understand and observe this lack of security when sending and/or receiving email communications between Voleon Funds LP, Voleon Capital Management LP, and any of their subsidiaries/affiliates and yourself.

Privacy: Voleon Funds LP, Voleon Capital Management LP, and their subsidiaries and affiliates archive incoming and outgoing emails and accordingly, may, at their discretion, monitor and review the content of all e-mail communications.


From: Christopher Allen [mailto:cma at bitemyapp.com]
Sent: Monday, November 02, 2015 12:46 PM
To: Charles Durham <ratzes at gmail.com>
Cc: Charles Weitzer <charles at voleon.com>; Haskell Cafe <haskell-cafe at haskell.org>
Subject: Re: [Haskell-cafe] Haskell Engineer Needed for Machine Learning Group

They've done this before (see attachment). If they don't give a straight answer on whether or not they're actually using Haskell, can they be blocked from posting to the ML for spam?

On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com<mailto:ratzes at gmail.com>> wrote:
Yeah, that's what I was thinking, not a bad recruiting strategy though

On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com<mailto:cma at bitemyapp.com>> wrote:
To your point,

>- strong experience developing in a functional programming environment (Haskell, Erlang, others).

is usually a dog-whistle for "we want better than average programmers but we're going to make them use tools that'll make them less effective and less happy"


On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com<mailto:ratzes at gmail.com>> wrote:
Nothing in the description (aside from the subject line) says that the engineer would be developing in Haskell. The C/C++/Python/Go to me indicates this has no business being posted here. Am I wrong?

Charles Durham

On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com<mailto:charles at voleon.com>> wrote:
Voleon Capital Management LP is a quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible.
Voleon?s founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon?s team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well.
Here is our formal job description:
**********************************************************
* Senior Software Engineer *
Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems.
The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm?s offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages.
We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus.
We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential.
Required experience:
- strong experience developing in a functional programming environment (Haskell, Erlang, others).
- developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness.
- working in TCP/IP networking, multi-threading, and server development.
- working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.).
- architecting and designing highly available systems.
- architecting and designing large-scale data management infrastructure.
- working in large codebases and building modular, manageable code.
Preferred experience.:
- debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc.
- working with build and test automation tools.
- working with well-defined change management processes.
- diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc.
- working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems.
Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring.
Benefits and compensation are highly competitive.
**********************************************************
The above job description is just a starting point in terms of possible duties and seniority.  We can be very flexible for the right person.
If you are interested please apply on our website: http://voleon.com/apply/.
If you have any questions or  if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details.
Thank you,

Charles Weitzer
Senior Recruiter
Voleon Capital Management LP
Office: 510.704.9870 x 7012<tel:510.704.9870%20x%207012>
Mobile: (510) 558-9182<tel:%28510%29%20558-9182>
www.Voleon.com<http://www.voleon.com/>


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



--
Chris Allen
Currently working on http://haskellbook.com




--
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/bf80bd68/attachment.html>

From cma at bitemyapp.com  Mon Nov  2 22:08:17 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Nov 2015 16:08:17 -0600
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
Message-ID: <CADnndOpULPAs0-Y2oWcta9sWVL+U5DBMxN4C2KPUmgjZtc1W3Q@mail.gmail.com>

Yes I noted you have contributors to the community working for you in an
earlier email, the question is whether the job will involve using Haskell
or not. Does the position entail using Haskell? If yes, what percentage of
the work approximately will be in Haskell? If no, are there any plans to
start evaluating Haskell internally? If there are such plans, will this
position likely involve being a part of that?

>We have one of the top contributors to the Haskell language onsite working
for us fulltime.

Does the company allocate them time to work on open source? If so, how much
and how often? For example, Guido van Rossum had arrangements in the past
where his time was split 50/50 between managing Python and company
projects. Does Voleon sponsor Haskell.org or any open source projects in
Haskell? Summer of code? Is the position for a team where there are other
Haskellers?


On Mon, Nov 2, 2015 at 3:55 PM, Charles Weitzer <charles at voleon.com> wrote:

> What are you talking about?  We have in the past and continue to post to
> this ML.  We have interviewed people from this list and have flown them in
> from around the world to interview onsite.  We have one of the top
> contributors to the Haskell language onsite working for us fulltime.
> Please stop guessing about our motives.  We are one of the top machine
> learning groups in the world.  We need great people, both researchers and
> programmers, to come help us grow our company.  We have found that people
> with extensive experience and expertise in Haskell tend to be very good at
> doing what we need done.
>
>
>
>
>
> Charles Weitzer
>
>
>
> Senior Recruiter
>
> Voleon Capital Management LP
>
> *Charles at Voleon.com <Charles at Voleon.com>*
> Office: 510.704.9870 x 7012
>
> Mobile: (510) 558-9182
>
> www.Voleon.com
>
>
>
> Confidential: This e-mail may contain confidential and/or privileged
> information. If you are not the intended recipient (or have received this
> e-mail in error) please notify the sender immediately and destroy this
> e-mail. Any unauthorized copying, disclosure or distribution of
> the material in this e-mail is strictly forbidden. Any comments or
> statements made herein do not necessarily reflect those of The Voleon
> Group, Voleon Funds LP, Voleon Capital Management LP, and their
> subsidiaries or affiliates. Please note that this e-mail has been created
> with the knowledge that Internet e-mail is not a 100% secure communications
> medium. We advise that you understand and observe this lack of security
> when sending and/or receiving email communications between Voleon Funds LP,
> Voleon Capital Management LP, and any of their subsidiaries/affiliates and
> yourself.
>
> Privacy: Voleon Funds LP, Voleon Capital Management LP, and their
> subsidiaries and affiliates archive incoming and outgoing emails and
> accordingly, may, at their discretion, monitor and review the content of
> all e-mail communications.
>
>
>
>
>
> *From:* Christopher Allen [mailto:cma at bitemyapp.com]
> *Sent:* Monday, November 02, 2015 12:46 PM
> *To:* Charles Durham <ratzes at gmail.com>
> *Cc:* Charles Weitzer <charles at voleon.com>; Haskell Cafe <
> haskell-cafe at haskell.org>
> *Subject:* Re: [Haskell-cafe] Haskell Engineer Needed for Machine
> Learning Group
>
>
>
> They've done this before (see attachment). If they don't give a straight
> answer on whether or not they're actually using Haskell, can they be
> blocked from posting to the ML for spam?
>
>
>
> On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com> wrote:
>
> Yeah, that's what I was thinking, not a bad recruiting strategy though
>
>
>
> On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
>
> To your point,
>
>
>
> >- strong experience developing in a functional programming environment
> (Haskell, Erlang, others).
>
>
>
> is usually a dog-whistle for "we want better than average programmers but
> we're going to make them use tools that'll make them less effective and
> less happy"
>
>
>
>
>
> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>
> Nothing in the description (aside from the subject line) says that the
> engineer would be developing in Haskell. The C/C++/Python/Go to me
> indicates this has no business being posted here. Am I wrong?
>
>
>
> Charles Durham
>
>
>
> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
> wrote:
>
> Voleon Capital Management LP is a quantitative hedge fund located in
> Berkeley, California. We would like to hire a senior software engineer with
> strong functional programming experience as soon as possible.
>
> Voleon?s founders previously worked together at one of the most successful
> quantitative hedge funds in the world. Our CEO has a PhD in Computer
> Science from Stanford and has been CEO and founder of a successful Internet
> infrastructure startup. Our Chief Investment Officer has a PhD in
> Statistics from Berkeley. Voleon?s team includes PhD's from leading
> departments in statistics, computer science, and mathematics. We have made
> several unpublished advances in the field of machine learning and in other
> areas as well.
>
> Here is our formal job description:
>
> **********************************************************
>
> * Senior Software Engineer *
>
> Technology-driven investment firm employing cutting-edge
> statistical machine learning techniques seeks an exceptionally capable
> software engineer. You will architect and implement new production trading
> systems, machine learning infrastructure, data integration pipelines,
> and large-scale storage systems.
>
> The firm researches and deploys systematic trading strategies designed
> to generate attractive returns without being dependent on the performance
> of the overall market. Join a team of under 30 people that includes a
> Berkeley statistics professor as well as over ten PhD's from Berkeley,
> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
> CEO of a successful Internet infrastructure technology firm. The firm?s
> offices are walking distance from BART and the UC Berkeley campus in
> downtown Berkeley, California. We have a casual and collegial office
> environment, catered lunches, and competitive benefits packages.
>
> We seek candidates with a proven track record of writing
> correct, well-designed software, solving hard problems, and delivering
> complex projects on time. You should preferably have experience designing
> and implementing fault-tolerant distributed systems. Experience with
> building large-scale data infrastructure, stream processing systems,
> or latency-sensitive programs is a bonus.
>
> We are growing rapidly. Willingness to take initiative and a
> gritty determination to productize are essential.
>
> Required experience:
>
> - strong experience developing in a functional programming environment
> (Haskell, Erlang, others).
>
> - developing with C/C++/Python/Go in a Linux environment with a focus
> on performance, concurrency, and correctness.
> - working in TCP/IP networking, multi-threading, and server development.
> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
> SNMP, etc.).
> - architecting and designing highly available systems.
> - architecting and designing large-scale data management infrastructure.
> - working in large codebases and building modular, manageable code.
>
> Preferred experience.:
>
> - debugging and performance profiling, including the use of tools such
> as strace, valgrind, gdb, tcpdump, etc.
> - working with build and test automation tools.
> - working with well-defined change management processes.
> - diagnosing RDBMS performance problems, exploiting indexing, using
> EXPLAIN PLAN, optimizing at the code layer, etc.
> - working with messaging queues (RabbitMQ, Redis, etc.) as well
> as distributed caching systems.
>
> Interest in financial applications is essential, but experience in
> finance is not a primary factor in our hiring.
>
> Benefits and compensation are highly competitive.
>
> **********************************************************
>
> The above job description is just a starting point in terms of possible
> duties and seniority.  We can be very flexible for the right person.
>
> If you are interested please apply on our website:
> http://voleon.com/apply/.
>
> If you have any questions or  if you know of anyone who might be
> interested, let us know the best way to get in touch and we can discuss
> details.
>
> Thank you,
>
>
>
> Charles Weitzer
>
> Senior Recruiter
>
> Voleon Capital Management LP
> Office: 510.704.9870 x 7012
>
> Mobile: (510) 558-9182
>
> www.Voleon.com <http://www.voleon.com/>
>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
>
>
>
> --
>
> Chris Allen
>
> Currently working on http://haskellbook.com
>
>
>
>
>
>
>
> --
>
> Chris Allen
>
> Currently working on http://haskellbook.com
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/f905c875/attachment-0001.html>

From ian at skybluetrades.net  Mon Nov  2 22:11:35 2015
From: ian at skybluetrades.net (Ian Ross)
Date: Mon, 2 Nov 2015 23:11:35 +0100
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CADnndOpULPAs0-Y2oWcta9sWVL+U5DBMxN4C2KPUmgjZtc1W3Q@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CADnndOpULPAs0-Y2oWcta9sWVL+U5DBMxN4C2KPUmgjZtc1W3Q@mail.gmail.com>
Message-ID: <CA+adx7s7jeCnGe4+JSRLY5fHfkVOdvjp93d8fEK=L0LEvz7j3g@mail.gmail.com>

It doesn't appear to be a Haskell job.  The job announcement on their
website is here: https://voleon.simplicant.com/jobs/18439/detail -- they
only add the line about "strong experience developing in a functional
programming environment (Haskell, Erlang, others)" when they're spamming
Erlang and Haskell mailing lists.  If it's not a Haskell job, it doesn't
belong here.  Unless people want to open the list up to everyone who thinks
they have an "interesting" job, of course.


On 2 November 2015 at 23:08, Christopher Allen <cma at bitemyapp.com> wrote:

> Yes I noted you have contributors to the community working for you in an
> earlier email, the question is whether the job will involve using Haskell
> or not. Does the position entail using Haskell? If yes, what percentage of
> the work approximately will be in Haskell? If no, are there any plans to
> start evaluating Haskell internally? If there are such plans, will this
> position likely involve being a part of that?
>
> >We have one of the top contributors to the Haskell language onsite
> working for us fulltime.
>
> Does the company allocate them time to work on open source? If so, how
> much and how often? For example, Guido van Rossum had arrangements in the
> past where his time was split 50/50 between managing Python and company
> projects. Does Voleon sponsor Haskell.org or any open source projects in
> Haskell? Summer of code? Is the position for a team where there are other
> Haskellers?
>
>
> On Mon, Nov 2, 2015 at 3:55 PM, Charles Weitzer <charles at voleon.com>
> wrote:
>
>> What are you talking about?  We have in the past and continue to post to
>> this ML.  We have interviewed people from this list and have flown them in
>> from around the world to interview onsite.  We have one of the top
>> contributors to the Haskell language onsite working for us fulltime.
>> Please stop guessing about our motives.  We are one of the top machine
>> learning groups in the world.  We need great people, both researchers and
>> programmers, to come help us grow our company.  We have found that people
>> with extensive experience and expertise in Haskell tend to be very good at
>> doing what we need done.
>>
>>
>>
>>
>>
>> Charles Weitzer
>>
>>
>>
>> Senior Recruiter
>>
>> Voleon Capital Management LP
>>
>> *Charles at Voleon.com <Charles at Voleon.com>*
>> Office: 510.704.9870 x 7012
>>
>> Mobile: (510) 558-9182
>>
>> www.Voleon.com
>>
>>
>>
>> Confidential: This e-mail may contain confidential and/or privileged
>> information. If you are not the intended recipient (or have received this
>> e-mail in error) please notify the sender immediately and destroy this
>> e-mail. Any unauthorized copying, disclosure or distribution of
>> the material in this e-mail is strictly forbidden. Any comments or
>> statements made herein do not necessarily reflect those of The Voleon
>> Group, Voleon Funds LP, Voleon Capital Management LP, and their
>> subsidiaries or affiliates. Please note that this e-mail has been created
>> with the knowledge that Internet e-mail is not a 100% secure communications
>> medium. We advise that you understand and observe this lack of security
>> when sending and/or receiving email communications between Voleon Funds LP,
>> Voleon Capital Management LP, and any of their subsidiaries/affiliates and
>> yourself.
>>
>> Privacy: Voleon Funds LP, Voleon Capital Management LP, and their
>> subsidiaries and affiliates archive incoming and outgoing emails and
>> accordingly, may, at their discretion, monitor and review the content of
>> all e-mail communications.
>>
>>
>>
>>
>>
>> *From:* Christopher Allen [mailto:cma at bitemyapp.com]
>> *Sent:* Monday, November 02, 2015 12:46 PM
>> *To:* Charles Durham <ratzes at gmail.com>
>> *Cc:* Charles Weitzer <charles at voleon.com>; Haskell Cafe <
>> haskell-cafe at haskell.org>
>> *Subject:* Re: [Haskell-cafe] Haskell Engineer Needed for Machine
>> Learning Group
>>
>>
>>
>> They've done this before (see attachment). If they don't give a straight
>> answer on whether or not they're actually using Haskell, can they be
>> blocked from posting to the ML for spam?
>>
>>
>>
>> On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com> wrote:
>>
>> Yeah, that's what I was thinking, not a bad recruiting strategy though
>>
>>
>>
>> On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com>
>> wrote:
>>
>> To your point,
>>
>>
>>
>> >- strong experience developing in a functional programming environment
>> (Haskell, Erlang, others).
>>
>>
>>
>> is usually a dog-whistle for "we want better than average programmers but
>> we're going to make them use tools that'll make them less effective and
>> less happy"
>>
>>
>>
>>
>>
>> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>>
>> Nothing in the description (aside from the subject line) says that the
>> engineer would be developing in Haskell. The C/C++/Python/Go to me
>> indicates this has no business being posted here. Am I wrong?
>>
>>
>>
>> Charles Durham
>>
>>
>>
>> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
>> wrote:
>>
>> Voleon Capital Management LP is a quantitative hedge fund located in
>> Berkeley, California. We would like to hire a senior software engineer with
>> strong functional programming experience as soon as possible.
>>
>> Voleon?s founders previously worked together at one of the most
>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>> Computer Science from Stanford and has been CEO and founder of a successful
>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>> departments in statistics, computer science, and mathematics. We have made
>> several unpublished advances in the field of machine learning and in other
>> areas as well.
>>
>> Here is our formal job description:
>>
>> **********************************************************
>>
>> * Senior Software Engineer *
>>
>> Technology-driven investment firm employing cutting-edge
>> statistical machine learning techniques seeks an exceptionally capable
>> software engineer. You will architect and implement new production trading
>> systems, machine learning infrastructure, data integration pipelines,
>> and large-scale storage systems.
>>
>> The firm researches and deploys systematic trading strategies designed
>> to generate attractive returns without being dependent on the performance
>> of the overall market. Join a team of under 30 people that includes a
>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>> CEO of a successful Internet infrastructure technology firm. The firm?s
>> offices are walking distance from BART and the UC Berkeley campus in
>> downtown Berkeley, California. We have a casual and collegial office
>> environment, catered lunches, and competitive benefits packages.
>>
>> We seek candidates with a proven track record of writing
>> correct, well-designed software, solving hard problems, and delivering
>> complex projects on time. You should preferably have experience designing
>> and implementing fault-tolerant distributed systems. Experience with
>> building large-scale data infrastructure, stream processing systems,
>> or latency-sensitive programs is a bonus.
>>
>> We are growing rapidly. Willingness to take initiative and a
>> gritty determination to productize are essential.
>>
>> Required experience:
>>
>> - strong experience developing in a functional programming environment
>> (Haskell, Erlang, others).
>>
>> - developing with C/C++/Python/Go in a Linux environment with a focus
>> on performance, concurrency, and correctness.
>> - working in TCP/IP networking, multi-threading, and server development.
>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>> SNMP, etc.).
>> - architecting and designing highly available systems.
>> - architecting and designing large-scale data management infrastructure.
>> - working in large codebases and building modular, manageable code.
>>
>> Preferred experience.:
>>
>> - debugging and performance profiling, including the use of tools such
>> as strace, valgrind, gdb, tcpdump, etc.
>> - working with build and test automation tools.
>> - working with well-defined change management processes.
>> - diagnosing RDBMS performance problems, exploiting indexing, using
>> EXPLAIN PLAN, optimizing at the code layer, etc.
>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>> as distributed caching systems.
>>
>> Interest in financial applications is essential, but experience in
>> finance is not a primary factor in our hiring.
>>
>> Benefits and compensation are highly competitive.
>>
>> **********************************************************
>>
>> The above job description is just a starting point in terms of possible
>> duties and seniority.  We can be very flexible for the right person.
>>
>> If you are interested please apply on our website:
>> http://voleon.com/apply/.
>>
>> If you have any questions or  if you know of anyone who might be
>> interested, let us know the best way to get in touch and we can discuss
>> details.
>>
>> Thank you,
>>
>>
>>
>> Charles Weitzer
>>
>> Senior Recruiter
>>
>> Voleon Capital Management LP
>> Office: 510.704.9870 x 7012
>>
>> Mobile: (510) 558-9182
>>
>> www.Voleon.com <http://www.voleon.com/>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>>
>>
>> --
>>
>> Chris Allen
>>
>> Currently working on http://haskellbook.com
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Chris Allen
>>
>> Currently working on http://haskellbook.com
>>
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Ian Ross   Tel: +43(0)6804451378   ian at skybluetrades.net
www.skybluetrades.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/6c8f586d/attachment.html>

From rtorruellas at gmail.com  Mon Nov  2 22:14:57 2015
From: rtorruellas at gmail.com (Richard Torruellas III)
Date: Mon, 2 Nov 2015 15:14:57 -0700
Subject: [Haskell-cafe] remove account
Message-ID: <5637E061.6070309@gmail.com>

Can you remove the account associated with this email address. I did not 
realize passwords were stored in plain text before sending (I missed the 
small print on the page)

Thanks

From cma at bitemyapp.com  Mon Nov  2 22:16:43 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Mon, 2 Nov 2015 16:16:43 -0600
Subject: [Haskell-cafe] remove account
In-Reply-To: <5637E061.6070309@gmail.com>
References: <5637E061.6070309@gmail.com>
Message-ID: <CADnndOrTCKO7j4UF0DPUcRyp4v0nrNfC=rwkOPO52KOffGE6Cg@mail.gmail.com>

You'll want to resets any accounts that use the same password and consider
using a password manager in future. Sadly, I can't recommend one because
everyone seems to hate them all.

Sorry for the convenience :(

On Mon, Nov 2, 2015 at 4:14 PM, Richard Torruellas III <
rtorruellas at gmail.com> wrote:

> Can you remove the account associated with this email address. I did not
> realize passwords were stored in plain text before sending (I missed the
> small print on the page)
>
> Thanks
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/d13c8044/attachment.html>

From michael at schmong.org  Mon Nov  2 22:38:32 2015
From: michael at schmong.org (Michael Litchard)
Date: Mon, 2 Nov 2015 14:38:32 -0800
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CA+adx7s7jeCnGe4+JSRLY5fHfkVOdvjp93d8fEK=L0LEvz7j3g@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CADnndOpULPAs0-Y2oWcta9sWVL+U5DBMxN4C2KPUmgjZtc1W3Q@mail.gmail.com>
 <CA+adx7s7jeCnGe4+JSRLY5fHfkVOdvjp93d8fEK=L0LEvz7j3g@mail.gmail.com>
Message-ID: <CAEzeKYq8pUCSngxE+3g6Mvf2nzwsJsGMuMDS4Gc2QvU6zUWunQ@mail.gmail.com>

Thanks to the thread for taking the time to suss out a bogus job
advertisement.

On Mon, Nov 2, 2015 at 2:11 PM, Ian Ross <ian at skybluetrades.net> wrote:

> It doesn't appear to be a Haskell job.  The job announcement on their
> website is here: https://voleon.simplicant.com/jobs/18439/detail -- they
> only add the line about "strong experience developing in a functional
> programming environment (Haskell, Erlang, others)" when they're spamming
> Erlang and Haskell mailing lists.  If it's not a Haskell job, it doesn't
> belong here.  Unless people want to open the list up to everyone who thinks
> they have an "interesting" job, of course.
>
>
> On 2 November 2015 at 23:08, Christopher Allen <cma at bitemyapp.com> wrote:
>
>> Yes I noted you have contributors to the community working for you in an
>> earlier email, the question is whether the job will involve using Haskell
>> or not. Does the position entail using Haskell? If yes, what percentage of
>> the work approximately will be in Haskell? If no, are there any plans to
>> start evaluating Haskell internally? If there are such plans, will this
>> position likely involve being a part of that?
>>
>> >We have one of the top contributors to the Haskell language onsite
>> working for us fulltime.
>>
>> Does the company allocate them time to work on open source? If so, how
>> much and how often? For example, Guido van Rossum had arrangements in the
>> past where his time was split 50/50 between managing Python and company
>> projects. Does Voleon sponsor Haskell.org or any open source projects in
>> Haskell? Summer of code? Is the position for a team where there are other
>> Haskellers?
>>
>>
>> On Mon, Nov 2, 2015 at 3:55 PM, Charles Weitzer <charles at voleon.com>
>> wrote:
>>
>>> What are you talking about?  We have in the past and continue to post to
>>> this ML.  We have interviewed people from this list and have flown them in
>>> from around the world to interview onsite.  We have one of the top
>>> contributors to the Haskell language onsite working for us fulltime.
>>> Please stop guessing about our motives.  We are one of the top machine
>>> learning groups in the world.  We need great people, both researchers and
>>> programmers, to come help us grow our company.  We have found that people
>>> with extensive experience and expertise in Haskell tend to be very good at
>>> doing what we need done.
>>>
>>>
>>>
>>>
>>>
>>> Charles Weitzer
>>>
>>>
>>>
>>> Senior Recruiter
>>>
>>> Voleon Capital Management LP
>>>
>>> *Charles at Voleon.com <Charles at Voleon.com>*
>>> Office: 510.704.9870 x 7012
>>>
>>> Mobile: (510) 558-9182
>>>
>>> www.Voleon.com
>>>
>>>
>>>
>>> Confidential: This e-mail may contain confidential and/or privileged
>>> information. If you are not the intended recipient (or have received this
>>> e-mail in error) please notify the sender immediately and destroy this
>>> e-mail. Any unauthorized copying, disclosure or distribution of
>>> the material in this e-mail is strictly forbidden. Any comments or
>>> statements made herein do not necessarily reflect those of The Voleon
>>> Group, Voleon Funds LP, Voleon Capital Management LP, and their
>>> subsidiaries or affiliates. Please note that this e-mail has been created
>>> with the knowledge that Internet e-mail is not a 100% secure communications
>>> medium. We advise that you understand and observe this lack of security
>>> when sending and/or receiving email communications between Voleon Funds LP,
>>> Voleon Capital Management LP, and any of their subsidiaries/affiliates and
>>> yourself.
>>>
>>> Privacy: Voleon Funds LP, Voleon Capital Management LP, and their
>>> subsidiaries and affiliates archive incoming and outgoing emails and
>>> accordingly, may, at their discretion, monitor and review the content of
>>> all e-mail communications.
>>>
>>>
>>>
>>>
>>>
>>> *From:* Christopher Allen [mailto:cma at bitemyapp.com]
>>> *Sent:* Monday, November 02, 2015 12:46 PM
>>> *To:* Charles Durham <ratzes at gmail.com>
>>> *Cc:* Charles Weitzer <charles at voleon.com>; Haskell Cafe <
>>> haskell-cafe at haskell.org>
>>> *Subject:* Re: [Haskell-cafe] Haskell Engineer Needed for Machine
>>> Learning Group
>>>
>>>
>>>
>>> They've done this before (see attachment). If they don't give a straight
>>> answer on whether or not they're actually using Haskell, can they be
>>> blocked from posting to the ML for spam?
>>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 2:25 PM, Charles Durham <ratzes at gmail.com> wrote:
>>>
>>> Yeah, that's what I was thinking, not a bad recruiting strategy though
>>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 3:15 PM, Christopher Allen <cma at bitemyapp.com>
>>> wrote:
>>>
>>> To your point,
>>>
>>>
>>>
>>> >- strong experience developing in a functional programming environment
>>> (Haskell, Erlang, others).
>>>
>>>
>>>
>>> is usually a dog-whistle for "we want better than average programmers
>>> but we're going to make them use tools that'll make them less effective and
>>> less happy"
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 2:12 PM, Charles Durham <ratzes at gmail.com> wrote:
>>>
>>> Nothing in the description (aside from the subject line) says that the
>>> engineer would be developing in Haskell. The C/C++/Python/Go to me
>>> indicates this has no business being posted here. Am I wrong?
>>>
>>>
>>>
>>> Charles Durham
>>>
>>>
>>>
>>> On Mon, Nov 2, 2015 at 3:08 PM, Charles Weitzer <charles at voleon.com>
>>> wrote:
>>>
>>> Voleon Capital Management LP is a quantitative hedge fund located in
>>> Berkeley, California. We would like to hire a senior software engineer with
>>> strong functional programming experience as soon as possible.
>>>
>>> Voleon?s founders previously worked together at one of the most
>>> successful quantitative hedge funds in the world. Our CEO has a PhD in
>>> Computer Science from Stanford and has been CEO and founder of a successful
>>> Internet infrastructure startup. Our Chief Investment Officer has a PhD in
>>> Statistics from Berkeley. Voleon?s team includes PhD's from leading
>>> departments in statistics, computer science, and mathematics. We have made
>>> several unpublished advances in the field of machine learning and in other
>>> areas as well.
>>>
>>> Here is our formal job description:
>>>
>>> **********************************************************
>>>
>>> * Senior Software Engineer *
>>>
>>> Technology-driven investment firm employing cutting-edge
>>> statistical machine learning techniques seeks an exceptionally capable
>>> software engineer. You will architect and implement new production trading
>>> systems, machine learning infrastructure, data integration pipelines,
>>> and large-scale storage systems.
>>>
>>> The firm researches and deploys systematic trading strategies designed
>>> to generate attractive returns without being dependent on the performance
>>> of the overall market. Join a team of under 30 people that includes a
>>> Berkeley statistics professor as well as over ten PhD's from Berkeley,
>>> Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and
>>> CEO of a successful Internet infrastructure technology firm. The firm?s
>>> offices are walking distance from BART and the UC Berkeley campus in
>>> downtown Berkeley, California. We have a casual and collegial office
>>> environment, catered lunches, and competitive benefits packages.
>>>
>>> We seek candidates with a proven track record of writing
>>> correct, well-designed software, solving hard problems, and delivering
>>> complex projects on time. You should preferably have experience designing
>>> and implementing fault-tolerant distributed systems. Experience with
>>> building large-scale data infrastructure, stream processing systems,
>>> or latency-sensitive programs is a bonus.
>>>
>>> We are growing rapidly. Willingness to take initiative and a
>>> gritty determination to productize are essential.
>>>
>>> Required experience:
>>>
>>> - strong experience developing in a functional programming environment
>>> (Haskell, Erlang, others).
>>>
>>> - developing with C/C++/Python/Go in a Linux environment with a focus
>>> on performance, concurrency, and correctness.
>>> - working in TCP/IP networking, multi-threading, and server development.
>>> - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP,
>>> SNMP, etc.).
>>> - architecting and designing highly available systems.
>>> - architecting and designing large-scale data management infrastructure.
>>> - working in large codebases and building modular, manageable code.
>>>
>>> Preferred experience.:
>>>
>>> - debugging and performance profiling, including the use of tools such
>>> as strace, valgrind, gdb, tcpdump, etc.
>>> - working with build and test automation tools.
>>> - working with well-defined change management processes.
>>> - diagnosing RDBMS performance problems, exploiting indexing, using
>>> EXPLAIN PLAN, optimizing at the code layer, etc.
>>> - working with messaging queues (RabbitMQ, Redis, etc.) as well
>>> as distributed caching systems.
>>>
>>> Interest in financial applications is essential, but experience in
>>> finance is not a primary factor in our hiring.
>>>
>>> Benefits and compensation are highly competitive.
>>>
>>> **********************************************************
>>>
>>> The above job description is just a starting point in terms of possible
>>> duties and seniority.  We can be very flexible for the right person.
>>>
>>> If you are interested please apply on our website:
>>> http://voleon.com/apply/.
>>>
>>> If you have any questions or  if you know of anyone who might be
>>> interested, let us know the best way to get in touch and we can discuss
>>> details.
>>>
>>> Thank you,
>>>
>>>
>>>
>>> Charles Weitzer
>>>
>>> Senior Recruiter
>>>
>>> Voleon Capital Management LP
>>> Office: 510.704.9870 x 7012
>>>
>>> Mobile: (510) 558-9182
>>>
>>> www.Voleon.com <http://www.voleon.com/>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Chris Allen
>>>
>>> Currently working on http://haskellbook.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Chris Allen
>>>
>>> Currently working on http://haskellbook.com
>>>
>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> Ian Ross   Tel: +43(0)6804451378   ian at skybluetrades.net
> www.skybluetrades.net
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151102/a4e1af0e/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Nov  2 22:42:08 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 2 Nov 2015 22:42:08 +0000
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
Message-ID: <20151102224208.GD6914@weber>

On Mon, Nov 02, 2015 at 09:55:14PM +0000, Charles Weitzer wrote:
> What are you talking about?  We have in the past and continue to post to
> this ML.  We have interviewed people from this list and have flown them in
> from around the world to interview onsite.  We have one of the top
> contributors to the Haskell language onsite working for us fulltime. 

I think it would demonstrate fair play on your part if you made it explicit
in the posts whether the job does or does not involve programming in
Haskell.  That seems it should be the minimum required to post a job advert
to the list.

Tom

From michael at orlitzky.com  Tue Nov  3 00:37:28 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Mon, 2 Nov 2015 19:37:28 -0500
Subject: [Haskell-cafe] remove account
In-Reply-To: <CADnndOrTCKO7j4UF0DPUcRyp4v0nrNfC=rwkOPO52KOffGE6Cg@mail.gmail.com>
References: <5637E061.6070309@gmail.com>
 <CADnndOrTCKO7j4UF0DPUcRyp4v0nrNfC=rwkOPO52KOffGE6Cg@mail.gmail.com>
Message-ID: <563801C8.7040107@orlitzky.com>

On 11/02/2015 05:16 PM, Christopher Allen wrote:
> consider using a password manager in future. Sadly, I can't recommend
> one because everyone seems to hate them all.

"gpg -c" and "gpg -d" do a fine job.


From ky3 at atamo.com  Tue Nov  3 00:55:38 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 3 Nov 2015 07:55:38 +0700
Subject: [Haskell-cafe] 'Associative' order of calling
In-Reply-To: <CAGkFuyD7djwjp5kOL+ikLx587cgVPSHaekVVVOppTHW3=WcfFw@mail.gmail.com>
References: <CAEXAPH4Jes9jnKpKk9B7LqAN2KLyiE8zrRvbbTYHFAhtfo_YKw@mail.gmail.com>
 <20151023152157.GA25220@casa.casa>
 <CAEXAPH7LoybD2cgxdwPDvC5GsxkUnRXErxABvvasj+rC+TYEKw@mail.gmail.com>
 <20151023154903.GF16020@weber>
 <CAEXAPH7xxDt0t4-78bZ2bfqdfLRj9nKGEZtbUhWzFSrj8wPOjg@mail.gmail.com>
 <CAHtRy3wFJhh=idr5jaqj3SAeMa0kGEwDjEUM=sEnLQH9Vq__7Q@mail.gmail.com>
 <CAGkFuyBhFt939C6tryO2S6ceAXmrhS7tK2-6o7SGHfss7gQsbQ@mail.gmail.com>
 <CAHtRy3xqhwZCCtNpDDXTpDgKu7y_hhnGrsZfG9rKAiUjmp-O0g@mail.gmail.com>
 <CAPY+ZdQRnAaFvJCqkW3RvGZMeH3t7U6dkp3xSo4SfuxmY5cdEQ@mail.gmail.com>
 <CAGkFuyC6+Vb77sO64DWV3=vPqZfJkQrPV19mDzCbiBOoLdzzsg@mail.gmail.com>
 <CAPY+ZdRfQtgkNHon7MCEhX6UyKE22q_-Zp9xiXUAW2e2S3CGkw@mail.gmail.com>
 <CAGkFuyDzxqLaWJ4kZ8AY-sR4XRectkHrEi6F=x8OPdko2+wCqQ@mail.gmail.com>
 <CAPY+ZdSZLQAHLM6zDYB4KHK8JJgkrSoxMh5djJCd2PEQGt8Lig@mail.gmail.com>
 <CAGkFuyDLSjV6suX9Lg9F0y-C99ydtTvG9=Da=DyBTqOHM-=MHw@mail.gmail.com>
 <CAPY+ZdQNUTHFjt+1T7XKRYMB0ytCxA-JpO5vGK79fjGBb2qU_w@mail.gmail.com>
 <CAGkFuyD7djwjp5kOL+ikLx587cgVPSHaekVVVOppTHW3=WcfFw@mail.gmail.com>
Message-ID: <CAPY+ZdQAn6VTjxOF14NQj6j8+Pg0fWKF8POG7zdgbBt4zbsdkw@mail.gmail.com>

On Thu, Oct 29, 2015 at 1:27 PM, Janis Voigtl?nder <
janis.voigtlaender at gmail.com> wrote:

> Are you sure you have read and respected all the forall-quantifiers in
> there?
>
> The statement "for all associative f and all lists xs, it holds that h f
> xs = foldl1 f xs" is *not* equivalent to the statement "for all f and all
> lists xs, it holds that h f xs = foldl1 f xs". The latter statement is
> equivalent (via eta-contractions) to "h = foldl", but the former isn't.
>
> Do I have to give a specific h to make this clearer? One which satisfies
> the first statement but is not equivalent to foldl or foldr. Actually, one
> was given already earlier in the conversation, to exactly the purpose of
> illuminating this whole point.


So you're saying:

"The property of the fold in question is that it's equivalent to a fold
(left or right, it's all one) __on the space of associative binary
operators.__"

That's not too far off is it?

I deliberately abbreviated for three reasons.

The first is that restriction to associative binary operators is inherent
in the original question. Recall: "Is there a name for a fold that promises
to call a function such that only an associative function will always
return the same result."

The second reason is that it summarizes the result into an easy take-away.

Lastly, the fuller answer can be worked out once we throw a glance at the
obviousness that foldl and foldr cannot be equal on the space of
non-associative binary operators.


-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/9ece2e03/attachment.html>

From rf at rufflewind.com  Tue Nov  3 02:54:22 2015
From: rf at rufflewind.com (Phil Ruffwind)
Date: Tue, 3 Nov 2015 10:54:22 +0800
Subject: [Haskell-cafe] process package with compilers besides GHC
In-Reply-To: <A9898B29-9295-46FD-B821-3F2985A12479@gmail.com>
References: <CAKA2JgLjSbCS40J0mHTdL1kqYqykHCSqw5Fp4-6EtPEzRci_zA@mail.gmail.com>
 <A9898B29-9295-46FD-B821-3F2985A12479@gmail.com>
Message-ID: <CADb8sTOCH6d+iFB892Tq1OQnzKjzdo6aHPdHBioT1DjAWNTVtw@mail.gmail.com>

I too have wondered whether all the #ifdefs for hugs are necessary in
'directory'.

From janis.voigtlaender at gmail.com  Tue Nov  3 07:26:15 2015
From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=)
Date: Tue, 3 Nov 2015 08:26:15 +0100
Subject: [Haskell-cafe] 'Associative' order of calling
In-Reply-To: <CAPY+ZdQAn6VTjxOF14NQj6j8+Pg0fWKF8POG7zdgbBt4zbsdkw@mail.gmail.com>
References: <CAEXAPH4Jes9jnKpKk9B7LqAN2KLyiE8zrRvbbTYHFAhtfo_YKw@mail.gmail.com>
 <20151023152157.GA25220@casa.casa>
 <CAEXAPH7LoybD2cgxdwPDvC5GsxkUnRXErxABvvasj+rC+TYEKw@mail.gmail.com>
 <20151023154903.GF16020@weber>
 <CAEXAPH7xxDt0t4-78bZ2bfqdfLRj9nKGEZtbUhWzFSrj8wPOjg@mail.gmail.com>
 <CAHtRy3wFJhh=idr5jaqj3SAeMa0kGEwDjEUM=sEnLQH9Vq__7Q@mail.gmail.com>
 <CAGkFuyBhFt939C6tryO2S6ceAXmrhS7tK2-6o7SGHfss7gQsbQ@mail.gmail.com>
 <CAHtRy3xqhwZCCtNpDDXTpDgKu7y_hhnGrsZfG9rKAiUjmp-O0g@mail.gmail.com>
 <CAPY+ZdQRnAaFvJCqkW3RvGZMeH3t7U6dkp3xSo4SfuxmY5cdEQ@mail.gmail.com>
 <CAGkFuyC6+Vb77sO64DWV3=vPqZfJkQrPV19mDzCbiBOoLdzzsg@mail.gmail.com>
 <CAPY+ZdRfQtgkNHon7MCEhX6UyKE22q_-Zp9xiXUAW2e2S3CGkw@mail.gmail.com>
 <CAGkFuyDzxqLaWJ4kZ8AY-sR4XRectkHrEi6F=x8OPdko2+wCqQ@mail.gmail.com>
 <CAPY+ZdSZLQAHLM6zDYB4KHK8JJgkrSoxMh5djJCd2PEQGt8Lig@mail.gmail.com>
 <CAGkFuyDLSjV6suX9Lg9F0y-C99ydtTvG9=Da=DyBTqOHM-=MHw@mail.gmail.com>
 <CAPY+ZdQNUTHFjt+1T7XKRYMB0ytCxA-JpO5vGK79fjGBb2qU_w@mail.gmail.com>
 <CAGkFuyD7djwjp5kOL+ikLx587cgVPSHaekVVVOppTHW3=WcfFw@mail.gmail.com>
 <CAPY+ZdQAn6VTjxOF14NQj6j8+Pg0fWKF8POG7zdgbBt4zbsdkw@mail.gmail.com>
Message-ID: <CAGkFuyA=7mDt7caRHbEjsKMKNUiO5jTMsoBB6TMpiEToHY=foA@mail.gmail.com>

2015-11-03 1:55 GMT+01:00 Kim-Ee Yeoh <ky3 at atamo.com>:

>
> On Thu, Oct 29, 2015 at 1:27 PM, Janis Voigtl?nder <
> janis.voigtlaender at gmail.com> wrote:
>
>> Are you sure you have read and respected all the forall-quantifiers in
>> there?
>>
>> The statement "for all associative f and all lists xs, it holds that h f
>> xs = foldl1 f xs" is *not* equivalent to the statement "for all f and
>> all lists xs, it holds that h f xs = foldl1 f xs". The latter statement is
>> equivalent (via eta-contractions) to "h = foldl", but the former isn't.
>>
>> Do I have to give a specific h to make this clearer? One which satisfies
>> the first statement but is not equivalent to foldl or foldr. Actually, one
>> was given already earlier in the conversation, to exactly the purpose of
>> illuminating this whole point.
>
>
> So you're saying:
>
> "The property of the fold in question is that it's equivalent to a fold
> (left or right, it's all one) __on the space of associative binary
> operators.__"
>
> That's not too far off is it?
>

It is what was meant, yes. With that part in "__ ... __".


> I deliberately abbreviated for three reasons.
>
> The first is that restriction to associative binary operators is inherent
> in the original question. Recall: "Is there a name for a fold that promises
> to call a function such that only an associative function will always
> return the same result."
>

I don't actually see how that question has an inherent restriction of the
kind you read into it, that we will never have to even think about what the
function does if called with a non-associative operator. On the contrary.
Saying that, paraphrasing, "*only* when you call the function with an
associative operator, something specific holds", does for sure imply that
to work out the condition we have to *also* consider what happens for
non-associative operators. Otherwise the "only" is pointless.

And in particular in the early messages of the thread, there was discussion
and confusion about whether what is sought here is a property of f or of h
or of both. So silently making assumptions about one of them seems not a
good idea to me. And even later in the thread we have again seen criticism
like "but this can't be expressed at all, because Haskell's type system is
not strong enough to capture associativity of operators". That criticism
does apply when sweeping "on the space of associative binary operators"
under the rug as if we could really say "extensional equality of functions"
and mean "the functions must give equal results when called on associative
operators". (If, but only if, we could express associativity in types, we
could write down a function type whose meaning of extensionality agrees
with what is claimed.)

The second reason is that it summarizes the result into an easy take-away.
>

Well, "easy" can often be "subtly wrong or at least confusing if glossing
over the full meaning".


> Lastly, the fuller answer can be worked out once we throw a glance at the
> obviousness that foldl and foldr cannot be equal on the space of
> non-associative binary operators.
>

Yes, the correct answer can be worked out with some thinking.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/c3256b38/attachment-0001.html>

From post at lukasepple.de  Tue Nov  3 08:55:01 2015
From: post at lukasepple.de (Lukas Epple)
Date: Tue, 3 Nov 2015 09:55:01 +0100
Subject: [Haskell-cafe] remove account
In-Reply-To: <563801C8.7040107@orlitzky.com>
References: <5637E061.6070309@gmail.com>
 <CADnndOrTCKO7j4UF0DPUcRyp4v0nrNfC=rwkOPO52KOffGE6Cg@mail.gmail.com>
 <563801C8.7040107@orlitzky.com>
Message-ID: <20151103085501.GB1389@schlepptopp.fritz.box>

On Mon, Nov 02, 2015 at 07:37:28PM -0500, Michael Orlitzky wrote:
> On 11/02/2015 05:16 PM, Christopher Allen wrote:
> > consider using a password manager in future. Sadly, I can't recommend
> > one because everyone seems to hate them all.
> 
> "gpg -c" and "gpg -d" do a fine job.

pass is a nice wrapper around that :)

http://www.passwordstore.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/806ffe32/attachment.sig>

From roma at ro-che.info  Tue Nov  3 10:19:06 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 3 Nov 2015 04:19:06 -0600
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
Message-ID: <56388A1A.1040201@ro-che.info>

On 11/02/2015 03:55 PM, Charles Weitzer wrote:
> What are you talking about?  We have in the past and continue to post to
> this ML.  We have interviewed people from this list and have flown them
> in from around the world to interview onsite.  We have one of the top
> contributors to the Haskell language onsite working for us fulltime. 
> Please stop guessing about our motives.  We are one of the top machine
> learning groups in the world.  We need great people, both researchers
> and programmers, to come help us grow our company.  We have found that
> people with extensive experience and expertise in Haskell tend to be
> very good at doing what we need done.

You ask to stop guessing about your motives, and at the same time you
indirectly confirm that the guess was 100% correct.

People generally expect job ads posted here be about Haskell jobs, not
about unrelated jobs for which you find Haskell a good selection criterion.

So either make your ads open and honest about how the job relates to
Haskell, or stop posting here. Your response quoted above (amounting to
"this works for *us*, and we don't care what *you* think") is not a
great way to build a relationship with the community.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/e0fb128d/attachment.sig>

From atzeus at gmail.com  Tue Nov  3 10:54:27 2015
From: atzeus at gmail.com (Atze van der Ploeg)
Date: Tue, 3 Nov 2015 11:54:27 +0100
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <56388A1A.1040201@ro-che.info>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <56388A1A.1040201@ro-che.info>
Message-ID: <CAGigdofEWyXGp3kz2tNMQb4pF1wSwTMyq1Onese7mjx4YLZSyA@mail.gmail.com>

I don't see the problem. They have a job, they want members from this
community. People in this community also need jobs.

2015-11-03 11:19 GMT+01:00 Roman Cheplyaka <roma at ro-che.info>:

> On 11/02/2015 03:55 PM, Charles Weitzer wrote:
> > What are you talking about?  We have in the past and continue to post to
> > this ML.  We have interviewed people from this list and have flown them
> > in from around the world to interview onsite.  We have one of the top
> > contributors to the Haskell language onsite working for us fulltime.
> > Please stop guessing about our motives.  We are one of the top machine
> > learning groups in the world.  We need great people, both researchers
> > and programmers, to come help us grow our company.  We have found that
> > people with extensive experience and expertise in Haskell tend to be
> > very good at doing what we need done.
>
> You ask to stop guessing about your motives, and at the same time you
> indirectly confirm that the guess was 100% correct.
>
> People generally expect job ads posted here be about Haskell jobs, not
> about unrelated jobs for which you find Haskell a good selection criterion.
>
> So either make your ads open and honest about how the job relates to
> Haskell, or stop posting here. Your response quoted above (amounting to
> "this works for *us*, and we don't care what *you* think") is not a
> great way to build a relationship with the community.
>
> Roman
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/97c5b60b/attachment.html>

From malcolm.wallace at me.com  Tue Nov  3 10:55:51 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 03 Nov 2015 10:55:51 +0000
Subject: [Haskell-cafe] process package with compilers besides GHC
In-Reply-To: <CAKA2JgL7b7nXeXqET38DovYuC7fY0xxmJq4vLwA5SFzDvWSv-A@mail.gmail.com>
References: <CAKA2JgLjSbCS40J0mHTdL1kqYqykHCSqw5Fp4-6EtPEzRci_zA@mail.gmail.com>
 <CAKA2JgL7b7nXeXqET38DovYuC7fY0xxmJq4vLwA5SFzDvWSv-A@mail.gmail.com>
Message-ID: <60D3E7AA-B977-4F36-8568-1E3ACE6F9767@me.com>

Clean-up is generally good.  I have not maintained any Haskell compiler for about 5 years now, so I think it is safe to say you can go ahead.  nhc98 did indeed build the 'process' package as part of its library set, but most recently at version 1.0.1.4.

Regards,
    Malcolm

On 2 Nov 2015, at 16:21, Michael Snoyman wrote:

> Forwarding directly to you, in case you're not reading the mailing lists.
> 
> ---------- Forwarded message ----------
> From: Michael Snoyman <michael at snoyman.com>
> Date: Mon, Nov 2, 2015 at 8:10 AM
> Subject: process package with compilers besides GHC
> To: Haskell Cafe <haskell-cafe at haskell.org>, libraries <libraries at haskell.org>
> 
> 
> I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that:
> 
> 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers
> 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC
> 
> I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals.
> 
> * No pun intend
> 


From ky3 at atamo.com  Tue Nov  3 11:18:44 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 3 Nov 2015 18:18:44 +0700
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CAGigdofEWyXGp3kz2tNMQb4pF1wSwTMyq1Onese7mjx4YLZSyA@mail.gmail.com>
References: <DM3PR1201MB099187E2DBE2A76F1CE54A4AC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <CAEXAPH6B92pHMFnjU7r8PomxrYP+b=wtuAhjvWaX7gbRY92OWw@mail.gmail.com>
 <CADnndOpXWMrXBJh60swJwUO3UE8Bt7jGCqWAjMt2YrpUD+N0Kg@mail.gmail.com>
 <CAEXAPH45hSn7oOdjf5kqOvnTUOjrXO30JhUX4RRzJZvj7OGGvw@mail.gmail.com>
 <CADnndOppvxO7gFaJoaHyhVpv5=+EhZ-k-_S_GBa_HX2dpPt-NQ@mail.gmail.com>
 <DM3PR1201MB0991F67C9E4B3A90B021F05DC62C0@DM3PR1201MB0991.namprd12.prod.outlook.com>
 <56388A1A.1040201@ro-che.info>
 <CAGigdofEWyXGp3kz2tNMQb4pF1wSwTMyq1Onese7mjx4YLZSyA@mail.gmail.com>
Message-ID: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>

On Tue, Nov 3, 2015 at 5:54 PM, Atze van der Ploeg <atzeus at gmail.com> wrote:

> I don't see the problem. They have a job, they want members from this
> community. People in this community also need jobs.


The problem is bait-and-switch.

Suppose you saw a job ad requiring strong experience in academic research.

You answered the call and got the job.

The first day of work they get you to mine coal for them 2 km below the
surface.

Would you have a problem?


-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/978e9c3b/attachment.html>

From adam at bergmark.nl  Tue Nov  3 11:24:41 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 03 Nov 2015 03:24:41 -0800 (PST)
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
 Group
In-Reply-To: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
Message-ID: <1446549881070.51f5acb2@Nodemailer>

There are plenty of other places where people who don't want to work with haskell can look for employment.




- Adam

On Tue, Nov 3, 2015 at 12:19 PM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

> On Tue, Nov 3, 2015 at 5:54 PM, Atze van der Ploeg <atzeus at gmail.com> wrote:
>> I don't see the problem. They have a job, they want members from this
>> community. People in this community also need jobs.
> The problem is bait-and-switch.
> Suppose you saw a job ad requiring strong experience in academic research.
> You answered the call and got the job.
> The first day of work they get you to mine coal for them 2 km below the
> surface.
> Would you have a problem?
> -- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/52436b49/attachment.html>

From ky3 at atamo.com  Tue Nov  3 11:40:01 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 3 Nov 2015 18:40:01 +0700
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <1446549881070.51f5acb2@Nodemailer>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
 <1446549881070.51f5acb2@Nodemailer>
Message-ID: <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>

On Tue, Nov 3, 2015 at 6:24 PM, Adam Bergmark <adam at bergmark.nl> wrote:

> There are plenty of other places where people who don't want to work with
> haskell can look for employment.


You've lost me. Haskell-cafe is where people gather who want to work with
haskell.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/3047ad36/attachment.html>

From carter.schonwald at gmail.com  Tue Nov  3 15:19:12 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 3 Nov 2015 10:19:12 -0500
Subject: [Haskell-cafe] Who's hiring,
 HS cafe edition Re: Haskell Engineer Needed for Machine Learning
 Group
Message-ID: <CAHYVw0x521NzfMUUniXynLU-n=3Sjy1-_h9a3j6ur_8usYCOzg@mail.gmail.com>

My team at "megacorp " is hiring.  Our main project right now is a domain
specific sibling to Agda / idris that runs on top of strongly consistent
replicated db that we're also in the process of iterating on.

A colleague and I will be at Hac Phi this weekend, and we're also helping
sponsor some of the catering costs.  Talk to us if you're there!

On Tuesday, November 3, 2015, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>
> On Tue, Nov 3, 2015 at 6:24 PM, Adam Bergmark <adam at bergmark.nl
> <javascript:_e(%7B%7D,'cvml','adam at bergmark.nl');>> wrote:
>
>> There are plenty of other places where people who don't want to work with
>> haskell can look for employment.
>
>
> You've lost me. Haskell-cafe is where people gather who want to work with
> haskell.
>
> -- Kim-Ee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/16973b5a/attachment.html>

From carter.schonwald at gmail.com  Tue Nov  3 15:55:37 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 3 Nov 2015 10:55:37 -0500
Subject: [Haskell-cafe] Who's hiring,
 HS cafe edition Re: Haskell Engineer Needed for Machine Learning
 Group
In-Reply-To: <CAHYVw0x521NzfMUUniXynLU-n=3Sjy1-_h9a3j6ur_8usYCOzg@mail.gmail.com>
References: <CAHYVw0x521NzfMUUniXynLU-n=3Sjy1-_h9a3j6ur_8usYCOzg@mail.gmail.com>
Message-ID: <CAHYVw0z008SnOFcdVb5GUnCxFOKoeBLPUzYvzPpcU97JY01UvQ@mail.gmail.com>

Oh and the code base is all Haskell. Of course :)
On Nov 3, 2015 10:19 AM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> My team at "megacorp " is hiring.  Our main project right now is a domain
> specific sibling to Agda / idris that runs on top of strongly consistent
> replicated db that we're also in the process of iterating on.
>
> A colleague and I will be at Hac Phi this weekend, and we're also helping
> sponsor some of the catering costs.  Talk to us if you're there!
>
> On Tuesday, November 3, 2015, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>
>>
>> On Tue, Nov 3, 2015 at 6:24 PM, Adam Bergmark <adam at bergmark.nl> wrote:
>>
>>> There are plenty of other places where people who don't want to work
>>> with haskell can look for employment.
>>
>>
>> You've lost me. Haskell-cafe is where people gather who want to work with
>> haskell.
>>
>> -- Kim-Ee
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/498db32a/attachment.html>

From chaddai.fouche at gmail.com  Tue Nov  3 16:19:42 2015
From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=)
Date: Tue, 03 Nov 2015 16:19:42 +0000
Subject: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
In-Reply-To: <560593B9.4020705@gmail.com>
References: <560446C3.1040404@gmail.com> <5604ECE3.8000703@ro-che.info>
 <560593B9.4020705@gmail.com>
Message-ID: <CANfjZRb1usFP9JnQ0f05ZtmjRODcAMA3aUp6mmgLSNp4mtM2yg@mail.gmail.com>

My question would be : what happen if I try to insert a Relation that
shares a side with a Relation already in the Polymap ? That seems a vital
information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/e421a19d/attachment.html>

From adam at bergmark.nl  Tue Nov  3 16:26:23 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Tue, 3 Nov 2015 17:26:23 +0100
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
 <1446549881070.51f5acb2@Nodemailer>
 <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>
Message-ID: <CACnqJZaTY+Mr3cY9vDJjmnn2Xn+bg8n2jL==BJYLZ+f3Y7kpdQ@mail.gmail.com>

And you have lost me Kim. To me we seem to agree.

On Tue, Nov 3, 2015 at 12:40 PM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>
> On Tue, Nov 3, 2015 at 6:24 PM, Adam Bergmark <adam at bergmark.nl> wrote:
>
>> There are plenty of other places where people who don't want to work with
>> haskell can look for employment.
>
>
> You've lost me. Haskell-cafe is where people gather who want to work with
> haskell.
>
> -- Kim-Ee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/1504f5a1/attachment.html>

From mblazevic at stilo.com  Tue Nov  3 16:44:59 2015
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Tue, 3 Nov 2015 11:44:59 -0500
Subject: [Haskell-cafe] Who's hiring, HS cafe edition
In-Reply-To: <CAHYVw0x521NzfMUUniXynLU-n=3Sjy1-_h9a3j6ur_8usYCOzg@mail.gmail.com>
References: <CAHYVw0x521NzfMUUniXynLU-n=3Sjy1-_h9a3j6ur_8usYCOzg@mail.gmail.com>
Message-ID: <5638E48B.5050700@stilo.com>

	For another entry point, my company is hiring.

http://www.stilo.com/wp-content/uploads/Full-Stack-Developer-October-2015.pdf

	While the job description only mentions Haskell under skills, we do 
have Haskell code to develop and maintain. That would probably be a 
minor part of the initial work, though, mostly because the Haskell parts 
of the project appear to be the most robust so far.

	I hope this kind of job ad would be on-topic for Haskell Caf?? In small 
shops like ours, there's just not enough maintenance work to justify a 
full Haskell-only developer job.


On 15-11-03 10:19 AM, Carter Schonwald wrote:
> My team at "megacorp " is hiring.  Our main project right now is a
> domain specific sibling to Agda / idris that runs on top of strongly
> consistent replicated db that we're also in the process of iterating on.
>
> A colleague and I will be at Hac Phi this weekend, and we're also
> helping sponsor some of the catering costs.  Talk to us if you're there!
>
> On Tuesday, November 3, 2015, Kim-Ee Yeoh <ky3 at atamo.com
> <mailto:ky3 at atamo.com>> wrote:
>


From qdunkan at gmail.com  Tue Nov  3 17:47:56 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 3 Nov 2015 09:47:56 -0800
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
Message-ID: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most
compilers have an equivalent ]

I really like -fwarn-unused-binds because it frequently finds bugs
where I forgot to call something or use some value.  If I put an
export list on, it can find dead functions I forgot to delete.
However, there's one case where it frequently gives false positives,
and that's unused record field names.  The problem is that I sometimes
use record field names as documentation, but the record itself is
internal and small, so I'm comfortable using positional pattern
matching to open it (and in fact that can be safer, since then
warn-unused-binds will make sure I used all the fields).  But GHC sees
these as unused functions, so it warns about them.  I can work around
by putting underscores on field names I haven't used yet, but it's a
hassle to go edit them when I want to use them.  The warning can be
useful if it indicates an unused field, but since fields can also be
extracted via the positional syntax it's not reliable.  The other use
of the warning for dead code or functions you forgot to use doesn't
apply to record accessors because they're trivial and compiler
generated.

So, would it be reasonable to exclude record field accessors from
-fwarn-unused-binds?  Or is there another way to work around it?  I
guess GHC doesn't have a "suppress warning" pragma like Java does, but
even if we did it wouldn't be much better than changing the name, and
more likely to get stale.

From thomasmiedema at gmail.com  Tue Nov  3 18:42:51 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 3 Nov 2015 19:42:51 +0100
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
In-Reply-To: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
Message-ID: <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>

Through a patch
<https://git.haskell.org/ghc.git/commitdiff/aead01902e1c41e85b758dbafd15e60d08956374>
by Oleg Grenrus (phadej), GHC 8 will have the following new flags:
 -fwarn-unused-top-binds
 -fwarn-unused-local-binds
 -fwarn-unused-pattern-binds

So you'll be able to pick and choose.


On Tue, Nov 3, 2015 at 6:47 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> [ ccing haskell-cafe since while it's a ghc flag, I'll bet most
> compilers have an equivalent ]
>
> I really like -fwarn-unused-binds because it frequently finds bugs
> where I forgot to call something or use some value.  If I put an
> export list on, it can find dead functions I forgot to delete.
> However, there's one case where it frequently gives false positives,
> and that's unused record field names.  The problem is that I sometimes
> use record field names as documentation, but the record itself is
> internal and small, so I'm comfortable using positional pattern
> matching to open it (and in fact that can be safer, since then
> warn-unused-binds will make sure I used all the fields).  But GHC sees
> these as unused functions, so it warns about them.  I can work around
> by putting underscores on field names I haven't used yet, but it's a
> hassle to go edit them when I want to use them.  The warning can be
> useful if it indicates an unused field, but since fields can also be
> extracted via the positional syntax it's not reliable.  The other use
> of the warning for dead code or functions you forgot to use doesn't
> apply to record accessors because they're trivial and compiler
> generated.
>
> So, would it be reasonable to exclude record field accessors from
> -fwarn-unused-binds?  Or is there another way to work around it?  I
> guess GHC doesn't have a "suppress warning" pragma like Java does, but
> even if we did it wouldn't be much better than changing the name, and
> more likely to get stale.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151103/089ffa95/attachment.html>

From jules at jellybean.co.uk  Wed Nov  4 08:29:07 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Wed, 4 Nov 2015 08:29:07 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
Message-ID: <04EBF782-B48B-4A43-B059-46BD11C67E1E@jellybean.co.uk>

Conduits seem like a popular and useful way to compose operations
which consume and produce streams at various speeds. I hadn't used
them before, so apologies for any obvious mistakes below.

Conduits have lots of power in terms of how you can interleave monadic
effects with the streaming; but I found that I had a stream with no
effects at all and I wanted to convert it back into haskells more
simplistic representation, lazy lists.

This is probably a well-known trick, but I couldn't find how to do this
from googling, so here is the solution I found in case it helps
someone else:

> {-# LANGUAGE DeriveDataTypeable, FlexibleContexts  #-}
> module Main where 
>
> import Data.Conduit
> import Control.Monad.Catch
> import Control.Monad.Trans.Resource
> import Control.Monad.Writer
> import Control.Monad.Identity
> import qualified Data.Conduit.List as CL
> import Data.Typeable
> 
> source123Error :: Monad m => Source m Int
> source123Error = do
>   yield 1
>   yield 2
>   yield 3
>   error "error"

A source which produces some data and then hangs, to test lazy production. 

One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens:

*Main> :t runIdentity (source123Error $$ CL.consume)
runIdentity (source123Error $$ CL.consume) :: [Int]
*Main> runIdentity (source123Error $$ CL.consume)
*** Exception: error

But what we can do instead is push the data out via the Writer monad:

> tellEverything :: MonadWriter [a] m => Sink a m ()
> tellEverything = awaitForever (\x -> tell [x])

*Main> :t source123Error $$ tellEverything
source123Error $$ tellEverything :: MonadWriter [Int] m => m ()
*Main> snd $ runWriter (source123Error $$ tellEverything)
[1,2,3*** Exception: error

Success! A lazily produced list.

If your output is of any size - and depending on the compositions
pattern in your code - it may be much faster to use this version:

> tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m ()
> tellEveryEndo = awaitForever (\x -> tell (Endo (x:)))

*Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne)
[1,2,3*** Exception: error

I found a further case where the Conduit I was trying to run was pure
but had a 'MonadThrow' constraint. You can use the same approach here,
using the ExceptionT transformer to satisfy the MonadThrow constraint.

> data MyError = MyError deriving (Show,Typeable)
> instance Exception MyError
>
> source123Throw :: MonadThrow m => Source m Int
> source123Throw = do
>  yield 1
>  yield 2
>  yield 3
>  throwM MyError

*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything)
[1,2,3*** Exception: error
*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything)
[1,2,3]

An aside: I tried to measure the speed difference between the
list-mappend and Endo-mappend approaches with the following
code. count2N uses a binary-tree shaped recursion so it should be
fairly bad for list-mappend with lots of long lists on the left.

> count2N :: Monad m => Int -> Source m Int
> count2N 0 = yield 0
> count2N n = count2N (n-1) >> count2N (n-1)

> speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything)
> speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo)

With -O or -O2 I measure no speed difference between these, they both
take a bit over 2 seconds. With no optimisation flag, speedTest2 is
slower, 17 seconds vs 11 seconds. 

I'm quite surprised the Endo version isn't faster, it seems like
something is rewriting those list appends?

Cheers,

Jules


From jules at jellybean.co.uk  Wed Nov  4 08:59:48 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Wed, 4 Nov 2015 08:59:48 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
Message-ID: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>

Conduits seem like a popular and useful way to compose operations
which consume and produce streams at various speeds. I hadn't used
them before, so apologies for any obvious mistakes below.

Conduits have lots of power in terms of how you can interleave monadic
effects with the streaming; but I found that I had a stream with no
effects at all and I wanted to convert it back into haskells more
simplistic representation, lazy lists.

This is probably a well-known trick, but I couldn't find how to do this
from googling, so here is the solution I found in case it helps
someone else:

> {-# LANGUAGE DeriveDataTypeable, FlexibleContexts  #-}
> module Main where 
> 
> import Data.Conduit
> import Control.Monad.Catch
> import Control.Monad.Trans.Resource
> import Control.Monad.Writer
> import Control.Monad.Identity
> import qualified Data.Conduit.List as CL
> import Data.Typeable
> 
> source123Error :: Monad m => Source m Int
> source123Error = do
>  yield 1
>  yield 2
>  yield 3
>  error "error"

A source which produces some data and then hangs, to test lazy production. 

One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens:

*Main> :t runIdentity (source123Error $$ CL.consume)
runIdentity (source123Error $$ CL.consume) :: [Int]
*Main> runIdentity (source123Error $$ CL.consume)
*** Exception: error

But what we can do instead is push the data out via the Writer monad:

> tellEverything :: MonadWriter [a] m => Sink a m ()
> tellEverything = awaitForever (\x -> tell [x])

*Main> :t source123Error $$ tellEverything
source123Error $$ tellEverything :: MonadWriter [Int] m => m ()
*Main> snd $ runWriter (source123Error $$ tellEverything)
[1,2,3*** Exception: error

Success! A lazily produced list.

If your output is of any size - and depending on the compositions
pattern in your code - it may be much faster to use this version:

> tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m ()
> tellEveryEndo = awaitForever (\x -> tell (Endo (x:)))

*Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne)
[1,2,3*** Exception: error

I found a further case where the Conduit I was trying to run was pure
but had a 'MonadThrow' constraint. You can use the same approach here,
using the ExceptionT transformer to satisfy the MonadThrow constraint.

> data MyError = MyError deriving (Show,Typeable)
> instance Exception MyError
> 
> source123Throw :: MonadThrow m => Source m Int
> source123Throw = do
> yield 1
> yield 2
> yield 3
> throwM MyError

*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything)
[1,2,3*** Exception: error
*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything)
[1,2,3]

An aside: I tried to measure the speed difference between the
list-mappend and Endo-mappend approaches with the following
code. count2N uses a binary-tree shaped recursion so it should be
fairly bad for list-mappend with lots of long lists on the left.

> count2N :: Monad m => Int -> Source m Int
> count2N 0 = yield 0
> count2N n = count2N (n-1) >> count2N (n-1)

> speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything)
> speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo)

With -O or -O2 I measure no speed difference between these, they both
take a bit over 2 seconds. With no optimisation flag, speedTest2 is
slower, 17 seconds vs 11 seconds. 

I'm quite surprised the Endo version isn't faster, it seems like
something is rewriting those list appends?

Cheers,

Jules


From michael at snoyman.com  Wed Nov  4 12:43:56 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 4 Nov 2015 04:43:56 -0800
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
Message-ID: <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>

conduit isn't designed to be used in this way, though in theory such a lazy
function would be possible. To get the same effect, you can (ab)use the
Data.Conduit.Lazy module, which provides a lazy I/O escape hatch. In this
case:

> lazyConsume source123Error >>= print

On Wed, Nov 4, 2015 at 12:59 AM, Jules Bean <jules at jellybean.co.uk> wrote:

> Conduits seem like a popular and useful way to compose operations
> which consume and produce streams at various speeds. I hadn't used
> them before, so apologies for any obvious mistakes below.
>
> Conduits have lots of power in terms of how you can interleave monadic
> effects with the streaming; but I found that I had a stream with no
> effects at all and I wanted to convert it back into haskells more
> simplistic representation, lazy lists.
>
> This is probably a well-known trick, but I couldn't find how to do this
> from googling, so here is the solution I found in case it helps
> someone else:
>
> > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts  #-}
> > module Main where
> >
> > import Data.Conduit
> > import Control.Monad.Catch
> > import Control.Monad.Trans.Resource
> > import Control.Monad.Writer
> > import Control.Monad.Identity
> > import qualified Data.Conduit.List as CL
> > import Data.Typeable
> >
> > source123Error :: Monad m => Source m Int
> > source123Error = do
> >  yield 1
> >  yield 2
> >  yield 3
> >  error "error"
>
> A source which produces some data and then hangs, to test lazy production.
>
> One solution which doesn't work is CL.consume (as its own docs say) - and
> instead this happens:
>
> *Main> :t runIdentity (source123Error $$ CL.consume)
> runIdentity (source123Error $$ CL.consume) :: [Int]
> *Main> runIdentity (source123Error $$ CL.consume)
> *** Exception: error
>
> But what we can do instead is push the data out via the Writer monad:
>
> > tellEverything :: MonadWriter [a] m => Sink a m ()
> > tellEverything = awaitForever (\x -> tell [x])
>
> *Main> :t source123Error $$ tellEverything
> source123Error $$ tellEverything :: MonadWriter [Int] m => m ()
> *Main> snd $ runWriter (source123Error $$ tellEverything)
> [1,2,3*** Exception: error
>
> Success! A lazily produced list.
>
> If your output is of any size - and depending on the compositions
> pattern in your code - it may be much faster to use this version:
>
> > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m ()
> > tellEveryEndo = awaitForever (\x -> tell (Endo (x:)))
>
> *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne)
> [1,2,3*** Exception: error
>
> I found a further case where the Conduit I was trying to run was pure
> but had a 'MonadThrow' constraint. You can use the same approach here,
> using the ExceptionT transformer to satisfy the MonadThrow constraint.
>
> > data MyError = MyError deriving (Show,Typeable)
> > instance Exception MyError
> >
> > source123Throw :: MonadThrow m => Source m Int
> > source123Throw = do
> > yield 1
> > yield 2
> > yield 3
> > throwM MyError
>
> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter .
> runExceptionT $ (source123Error $$ tellEverything)
> [1,2,3*** Exception: error
> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter .
> runExceptionT $ (source123Throw $$ tellEverything)
> [1,2,3]
>
> An aside: I tried to measure the speed difference between the
> list-mappend and Endo-mappend approaches with the following
> code. count2N uses a binary-tree shaped recursion so it should be
> fairly bad for list-mappend with lots of long lists on the left.
>
> > count2N :: Monad m => Int -> Source m Int
> > count2N 0 = yield 0
> > count2N n = count2N (n-1) >> count2N (n-1)
>
> > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$
> tellEverything)
> > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $
> (count2N 24 $$ tellEveryEndo)
>
> With -O or -O2 I measure no speed difference between these, they both
> take a bit over 2 seconds. With no optimisation flag, speedTest2 is
> slower, 17 seconds vs 11 seconds.
>
> I'm quite surprised the Endo version isn't faster, it seems like
> something is rewriting those list appends?
>
> Cheers,
>
> Jules
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/6ce2edc3/attachment.html>

From michael at snoyman.com  Wed Nov  4 13:04:40 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 4 Nov 2015 05:04:40 -0800
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
Message-ID: <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>

This got me curious, so I just added a `sourceToList` function to master:

https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a

On Wed, Nov 4, 2015 at 4:43 AM, Michael Snoyman <michael at snoyman.com> wrote:

> conduit isn't designed to be used in this way, though in theory such a
> lazy function would be possible. To get the same effect, you can (ab)use
> the Data.Conduit.Lazy module, which provides a lazy I/O escape hatch. In
> this case:
>
> > lazyConsume source123Error >>= print
>
> On Wed, Nov 4, 2015 at 12:59 AM, Jules Bean <jules at jellybean.co.uk> wrote:
>
>> Conduits seem like a popular and useful way to compose operations
>> which consume and produce streams at various speeds. I hadn't used
>> them before, so apologies for any obvious mistakes below.
>>
>> Conduits have lots of power in terms of how you can interleave monadic
>> effects with the streaming; but I found that I had a stream with no
>> effects at all and I wanted to convert it back into haskells more
>> simplistic representation, lazy lists.
>>
>> This is probably a well-known trick, but I couldn't find how to do this
>> from googling, so here is the solution I found in case it helps
>> someone else:
>>
>> > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts  #-}
>> > module Main where
>> >
>> > import Data.Conduit
>> > import Control.Monad.Catch
>> > import Control.Monad.Trans.Resource
>> > import Control.Monad.Writer
>> > import Control.Monad.Identity
>> > import qualified Data.Conduit.List as CL
>> > import Data.Typeable
>> >
>> > source123Error :: Monad m => Source m Int
>> > source123Error = do
>> >  yield 1
>> >  yield 2
>> >  yield 3
>> >  error "error"
>>
>> A source which produces some data and then hangs, to test lazy production.
>>
>> One solution which doesn't work is CL.consume (as its own docs say) - and
>> instead this happens:
>>
>> *Main> :t runIdentity (source123Error $$ CL.consume)
>> runIdentity (source123Error $$ CL.consume) :: [Int]
>> *Main> runIdentity (source123Error $$ CL.consume)
>> *** Exception: error
>>
>> But what we can do instead is push the data out via the Writer monad:
>>
>> > tellEverything :: MonadWriter [a] m => Sink a m ()
>> > tellEverything = awaitForever (\x -> tell [x])
>>
>> *Main> :t source123Error $$ tellEverything
>> source123Error $$ tellEverything :: MonadWriter [Int] m => m ()
>> *Main> snd $ runWriter (source123Error $$ tellEverything)
>> [1,2,3*** Exception: error
>>
>> Success! A lazily produced list.
>>
>> If your output is of any size - and depending on the compositions
>> pattern in your code - it may be much faster to use this version:
>>
>> > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m ()
>> > tellEveryEndo = awaitForever (\x -> tell (Endo (x:)))
>>
>> *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne)
>> [1,2,3*** Exception: error
>>
>> I found a further case where the Conduit I was trying to run was pure
>> but had a 'MonadThrow' constraint. You can use the same approach here,
>> using the ExceptionT transformer to satisfy the MonadThrow constraint.
>>
>> > data MyError = MyError deriving (Show,Typeable)
>> > instance Exception MyError
>> >
>> > source123Throw :: MonadThrow m => Source m Int
>> > source123Throw = do
>> > yield 1
>> > yield 2
>> > yield 3
>> > throwM MyError
>>
>> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter
>> . runExceptionT $ (source123Error $$ tellEverything)
>> [1,2,3*** Exception: error
>> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter
>> . runExceptionT $ (source123Throw $$ tellEverything)
>> [1,2,3]
>>
>> An aside: I tried to measure the speed difference between the
>> list-mappend and Endo-mappend approaches with the following
>> code. count2N uses a binary-tree shaped recursion so it should be
>> fairly bad for list-mappend with lots of long lists on the left.
>>
>> > count2N :: Monad m => Int -> Source m Int
>> > count2N 0 = yield 0
>> > count2N n = count2N (n-1) >> count2N (n-1)
>>
>> > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$
>> tellEverything)
>> > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $
>> (count2N 24 $$ tellEveryEndo)
>>
>> With -O or -O2 I measure no speed difference between these, they both
>> take a bit over 2 seconds. With no optimisation flag, speedTest2 is
>> slower, 17 seconds vs 11 seconds.
>>
>> I'm quite surprised the Endo version isn't faster, it seems like
>> something is rewriting those list appends?
>>
>> Cheers,
>>
>> Jules
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/7d02d6a6/attachment.html>

From ky3 at atamo.com  Wed Nov  4 13:13:41 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 4 Nov 2015 20:13:41 +0700
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CACnqJZaTY+Mr3cY9vDJjmnn2Xn+bg8n2jL==BJYLZ+f3Y7kpdQ@mail.gmail.com>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
 <1446549881070.51f5acb2@Nodemailer>
 <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>
 <CACnqJZaTY+Mr3cY9vDJjmnn2Xn+bg8n2jL==BJYLZ+f3Y7kpdQ@mail.gmail.com>
Message-ID: <CAPY+ZdRrE8=FKuhQ8GQQ8UMP1XagMU2Mzfiy=DDT0S31ea-qbw@mail.gmail.com>

On Tue, Nov 3, 2015 at 11:26 PM, Adam Bergmark <adam at bergmark.nl> wrote:

> And you have lost me Kim. To me we seem to agree.


I'm glad we agree :)

But my brain is too small to discern the logic by which we got there.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/2afce81f/attachment.html>

From jules at jellybean.co.uk  Wed Nov  4 13:14:09 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Wed, 4 Nov 2015 13:14:09 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
 <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
Message-ID: <BB459727-20C9-403E-AF41-95CFB693CFF2@jellybean.co.uk>

Yay! That?s great.

The point of course is that you shouldn?t need to do a lazyIO trick when there is no IO going on.

My actual application of this was in Text.XML.Stream.Parse which certainly can produce output lazily without doing IO.

Jules

On 4 Nov 2015, at 13:04, Michael Snoyman <michael at snoyman.com> wrote:

> This got me curious, so I just added a `sourceToList` function to master:
> 
> https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a
> 
> On Wed, Nov 4, 2015 at 4:43 AM, Michael Snoyman <michael at snoyman.com> wrote:
> conduit isn't designed to be used in this way, though in theory such a lazy function would be possible. To get the same effect, you can (ab)use the Data.Conduit.Lazy module, which provides a lazy I/O escape hatch. In this case:
> 
> > lazyConsume source123Error >>= print
> 
> On Wed, Nov 4, 2015 at 12:59 AM, Jules Bean <jules at jellybean.co.uk> wrote:
> Conduits seem like a popular and useful way to compose operations
> which consume and produce streams at various speeds. I hadn't used
> them before, so apologies for any obvious mistakes below.
> 
> Conduits have lots of power in terms of how you can interleave monadic
> effects with the streaming; but I found that I had a stream with no
> effects at all and I wanted to convert it back into haskells more
> simplistic representation, lazy lists.
> 
> This is probably a well-known trick, but I couldn't find how to do this
> from googling, so here is the solution I found in case it helps
> someone else:
> 
> > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts  #-}
> > module Main where
> >
> > import Data.Conduit
> > import Control.Monad.Catch
> > import Control.Monad.Trans.Resource
> > import Control.Monad.Writer
> > import Control.Monad.Identity
> > import qualified Data.Conduit.List as CL
> > import Data.Typeable
> >
> > source123Error :: Monad m => Source m Int
> > source123Error = do
> >  yield 1
> >  yield 2
> >  yield 3
> >  error "error"
> 
> A source which produces some data and then hangs, to test lazy production.
> 
> One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens:
> 
> *Main> :t runIdentity (source123Error $$ CL.consume)
> runIdentity (source123Error $$ CL.consume) :: [Int]
> *Main> runIdentity (source123Error $$ CL.consume)
> *** Exception: error
> 
> But what we can do instead is push the data out via the Writer monad:
> 
> > tellEverything :: MonadWriter [a] m => Sink a m ()
> > tellEverything = awaitForever (\x -> tell [x])
> 
> *Main> :t source123Error $$ tellEverything
> source123Error $$ tellEverything :: MonadWriter [Int] m => m ()
> *Main> snd $ runWriter (source123Error $$ tellEverything)
> [1,2,3*** Exception: error
> 
> Success! A lazily produced list.
> 
> If your output is of any size - and depending on the compositions
> pattern in your code - it may be much faster to use this version:
> 
> > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m ()
> > tellEveryEndo = awaitForever (\x -> tell (Endo (x:)))
> 
> *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne)
> [1,2,3*** Exception: error
> 
> I found a further case where the Conduit I was trying to run was pure
> but had a 'MonadThrow' constraint. You can use the same approach here,
> using the ExceptionT transformer to satisfy the MonadThrow constraint.
> 
> > data MyError = MyError deriving (Show,Typeable)
> > instance Exception MyError
> >
> > source123Throw :: MonadThrow m => Source m Int
> > source123Throw = do
> > yield 1
> > yield 2
> > yield 3
> > throwM MyError
> 
> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything)
> [1,2,3*** Exception: error
> *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything)
> [1,2,3]
> 
> An aside: I tried to measure the speed difference between the
> list-mappend and Endo-mappend approaches with the following
> code. count2N uses a binary-tree shaped recursion so it should be
> fairly bad for list-mappend with lots of long lists on the left.
> 
> > count2N :: Monad m => Int -> Source m Int
> > count2N 0 = yield 0
> > count2N n = count2N (n-1) >> count2N (n-1)
> 
> > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything)
> > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo)
> 
> With -O or -O2 I measure no speed difference between these, they both
> take a bit over 2 seconds. With no optimisation flag, speedTest2 is
> slower, 17 seconds vs 11 seconds.
> 
> I'm quite surprised the Endo version isn't faster, it seems like
> something is rewriting those list appends?
> 
> Cheers,
> 
> Jules
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/c3123068/attachment.html>

From steve at fenestra.com  Wed Nov  4 13:20:53 2015
From: steve at fenestra.com (Steve Schafer)
Date: Wed, 04 Nov 2015 08:20:53 -0500
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <CAPY+ZdRrE8=FKuhQ8GQQ8UMP1XagMU2Mzfiy=DDT0S31ea-qbw@mail.gmail.com>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
 <1446549881070.51f5acb2@Nodemailer>
 <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>
 <CACnqJZaTY+Mr3cY9vDJjmnn2Xn+bg8n2jL==BJYLZ+f3Y7kpdQ@mail.gmail.com>
 <CAPY+ZdRrE8=FKuhQ8GQQ8UMP1XagMU2Mzfiy=DDT0S31ea-qbw@mail.gmail.com>
Message-ID: <o81k3bpp27fv5j18t1dssumfen0ulsamru@4ax.com>

On Wed, 4 Nov 2015 20:13:41 +0700, you wrote:

>I'm glad we agree :)
>
>But my brain is too small to discern the logic by which we got there.

As an outside observer to the conversation, I think what happened is
that Adam's original response to you was actually intended for the one
to which that post was a response. An off-by-one error, of sorts.

-Steve Schafer

From ky3 at atamo.com  Wed Nov  4 13:23:47 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Wed, 4 Nov 2015 20:23:47 +0700
Subject: [Haskell-cafe] Haskell Engineer Needed for Machine Learning
	Group
In-Reply-To: <o81k3bpp27fv5j18t1dssumfen0ulsamru@4ax.com>
References: <CAPY+ZdSoAnDR2=TQNHVujDg6p0Vt3Y-FnmQ_N2xaYxqvK0FHcw@mail.gmail.com>
 <1446549881070.51f5acb2@Nodemailer>
 <CAPY+ZdRiZrdJcDHLeKddOJd8WOvSwPpB7S5xp+jP8FSjdP5HMQ@mail.gmail.com>
 <CACnqJZaTY+Mr3cY9vDJjmnn2Xn+bg8n2jL==BJYLZ+f3Y7kpdQ@mail.gmail.com>
 <CAPY+ZdRrE8=FKuhQ8GQQ8UMP1XagMU2Mzfiy=DDT0S31ea-qbw@mail.gmail.com>
 <o81k3bpp27fv5j18t1dssumfen0ulsamru@4ax.com>
Message-ID: <CAPY+ZdR_F4=RABfi1CEMGH4P+=8bOpeYwcuZ=v=5m5HEQ2j6MQ@mail.gmail.com>

On Wed, Nov 4, 2015 at 8:20 PM, Steve Schafer <steve at fenestra.com> wrote:

> As an outside observer to the conversation, I think what happened is
> that Adam's original response to you was actually intended for the one
> to which that post was a response. An off-by-one error, of sorts.


Oh, thank you Steve. Much obliged.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/3222cf3a/attachment.html>

From lemming at henning-thielemann.de  Wed Nov  4 14:56:08 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 4 Nov 2015 15:56:08 +0100 (CET)
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
In-Reply-To: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1511041554080.10949@sputnik>


On Tue, 3 Nov 2015, Evan Laforge wrote:

> I can work around by putting underscores on field names I haven't used 
> yet, but it's a hassle to go edit them when I want to use them.

I do it this way and I do not consider it a work-around. The underscore is 
just the shortest way to say that a record field name is not used. It's 
shorter than any pragma could be.

From meditans at gmail.com  Wed Nov  4 14:59:04 2015
From: meditans at gmail.com (Carlo Nucera)
Date: Wed, 4 Nov 2015 15:59:04 +0100
Subject: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
In-Reply-To: <CANfjZRb1usFP9JnQ0f05ZtmjRODcAMA3aUp6mmgLSNp4mtM2yg@mail.gmail.com>
References: <560446C3.1040404@gmail.com> <5604ECE3.8000703@ro-che.info>
 <560593B9.4020705@gmail.com>
 <CANfjZRb1usFP9JnQ0f05ZtmjRODcAMA3aUp6mmgLSNp4mtM2yg@mail.gmail.com>
Message-ID: <CALaN21O=Sh9vCXecxtm2CgQ4EV1o1KbQJ87cfKRCuhG1s3hU3g@mail.gmail.com>

>From reading the code, it depends on what structures are used for
`Storage`. For example, using `[ ]`, in the moral equivalent of the
map [("foo",1), ("bar",1)], you cannot get "bar" when querying for 1.

In fact, I think the most important information to add are examples on
how to obtain different behaviors with different `Storage` types.

2015-11-03 17:19 GMT+01:00 Chadda? Fouch? <chaddai.fouche at gmail.com>:
> My question would be : what happen if I try to insert a Relation that shares
> a side with a Relation already in the Polymap ? That seems a vital
> information.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From michael at orlitzky.com  Wed Nov  4 15:08:32 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Wed, 4 Nov 2015 10:08:32 -0500
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
In-Reply-To: <alpine.DEB.2.02.1511041554080.10949@sputnik>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
 <alpine.DEB.2.02.1511041554080.10949@sputnik>
Message-ID: <563A1F70.9090200@orlitzky.com>

On 11/04/2015 09:56 AM, Henning Thielemann wrote:
> 
> On Tue, 3 Nov 2015, Evan Laforge wrote:
> 
>> I can work around by putting underscores on field names I haven't used 
>> yet, but it's a hassle to go edit them when I want to use them.
> 
> I do it this way and I do not consider it a work-around. The underscore is 
> just the shortest way to say that a record field name is not used. It's 
> shorter than any pragma could be.


There are libraries that do magic based on the field name (Groundhog
comes to mind). In those cases you have to name the field appropriately
even if you're not going to use it, so the ability to shutup the warning
will be appreciated.



From skosyrev at ptsecurity.com  Wed Nov  4 15:42:29 2015
From: skosyrev at ptsecurity.com (Kosyrev Serge)
Date: Wed, 4 Nov 2015 18:42:29 +0300
Subject: [Haskell-cafe] Haskell positions in Moscow, Positive Technologies
In-Reply-To: <982E32E1-4CF7-44B4-BD10-72A71537A977@ptsecurity.com> (Alexander
 Anisimov's message of "Wed, 4 Nov 2015 03:20:04 -1200")
References: <87y4edg9vf.fsf@ptsecurity.com>
 <F6899369-0DBF-46E4-BD12-7AA64EEB68A3@ptsecurity.com>
 <87r3k5g6p5.fsf@ptsecurity.com>
 <982E32E1-4CF7-44B4-BD10-72A71537A977@ptsecurity.com>
Message-ID: <87h9l1g49m.fsf_-_@ptsecurity.com>

Good day!

The Moscow office of Positive Technologies (http://ptsecurity.com)
seeks Haskell developers with strong C background, as part of an effort
to develop a next-generation (of course!) democratic security platform.

Think widely available, easy-to-use, dramatically enhanced security.

If this kind of thing feels motivating, please send your resume
to career at ptsecurity.com and CC skosyrev at ptsecurity.com.


Position:
 Senior Software Engineer

Vague description:
 - bare-metal, kernel, userland development

Required experience:
 - C programming
 - experience of applying GHC in FFI-heavy context
 - experience with kernel development (some of Linux, Windows, Darwin)
 - experience writing resource-efficient Haskell code
 - experience with parallelism
 - taming laziness
 - taming the GC (desirable)
 - experience with the Intel system platform (desirable)
 - some knowledge of GHC runtime internals (desirable)

--
respectfully,
Kosyrev Serge
http://www.ptsecurity.com/
Habr: http://habr.ru/company/pt
Twitter: @ptsecurity https://twitter.com/ptsecurity

From qdunkan at gmail.com  Wed Nov  4 17:20:17 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 4 Nov 2015 09:20:17 -0800
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
In-Reply-To: <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
 <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>
Message-ID: <CACbaDy4rakc1F9ie6xT8kxP-+SkbORE1+6TuGtHz8=vkW_RvVQ@mail.gmail.com>

On Tue, Nov 3, 2015 at 10:42 AM, Thomas Miedema <thomasmiedema at gmail.com> wrote:
> Through a patch by Oleg Grenrus (phadej), GHC 8 will have the following new
> flags:
>  -fwarn-unused-top-binds
>  -fwarn-unused-local-binds
>  -fwarn-unused-pattern-binds
>
> So you'll be able to pick and choose.

I suppose a record accessor would be considered a top bind?  I still
kind of like getting warnings about those, just not the ones from
records...

On Wed, Nov 4, 2015 at 6:56 AM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
> I do it this way and I do not consider it a work-around. The underscore is
> just the shortest way to say that a record field name is not used. It's
> shorter than any pragma could be.

I agree, that's what I meant by "not much better than changing the name".

I guess it would have to be yet another flag like
-fwarn-unused-record-accessors... not sure if it would be worth it
though, considering it's a relatively minor issue.

From meditans at gmail.com  Wed Nov  4 17:53:59 2015
From: meditans at gmail.com (Carlo Nucera)
Date: Wed, 4 Nov 2015 18:53:59 +0100
Subject: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
In-Reply-To: <CALaN21O=Sh9vCXecxtm2CgQ4EV1o1KbQJ87cfKRCuhG1s3hU3g@mail.gmail.com>
References: <560446C3.1040404@gmail.com> <5604ECE3.8000703@ro-che.info>
 <560593B9.4020705@gmail.com>
 <CANfjZRb1usFP9JnQ0f05ZtmjRODcAMA3aUp6mmgLSNp4mtM2yg@mail.gmail.com>
 <CALaN21O=Sh9vCXecxtm2CgQ4EV1o1KbQJ87cfKRCuhG1s3hU3g@mail.gmail.com>
Message-ID: <CALaN21OQCTN_K2uYNts+HWYpkoJfY0n=4mSGkYFs4EgP9Hf5DQ@mail.gmail.com>

I had the time to take another glance at this library: the behavior I
was referring to is caused by functions like `findIndex` which have
return type `Maybe Int`. So basically it seems that partially
overlappable edges are not possible in this version.

If you want partially overlappable edges, you may turn the `findIndex`
functions in `findIndexes` functions, which
 return `[Int]`, as I did in this fork: https://github.com/meditans/hs-polymap

Now, I'll go ahead and add a `Data.IntMap` instance for `Storage`, to
better the asymptotics of the search.

2015-11-04 15:59 GMT+01:00 Carlo Nucera <meditans at gmail.com>:
> From reading the code, it depends on what structures are used for
> `Storage`. For example, using `[ ]`, in the moral equivalent of the
> map [("foo",1), ("bar",1)], you cannot get "bar" when querying for 1.
>
> In fact, I think the most important information to add are examples on
> how to obtain different behaviors with different `Storage` types.
>
> 2015-11-03 17:19 GMT+01:00 Chadda? Fouch? <chaddai.fouche at gmail.com>:
>> My question would be : what happen if I try to insert a Relation that shares
>> a side with a Relation already in the Polymap ? That seems a vital
>> information.
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>

From jules at jellybean.co.uk  Wed Nov  4 17:28:21 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Wed, 4 Nov 2015 17:28:21 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
 <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
Message-ID: <2775EC12-0298-45CE-ACC3-04C5FB7125C9@jellybean.co.uk>


On 4 Nov 2015, at 13:04, Michael Snoyman <michael at snoyman.com> wrote:

> This got me curious, so I just added a `sourceToList` function to master:
> 
> https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a

Having spent a day thinking this over?

Nothing with the type `Source m a -> m [a]` can work for my second example - the one where I use runExceptionT to discharge the MonadThrow constraint. This is because once you use runExceptionT you have pushed yourself into the situation where in case of error there is no ?return value?. 

It?s not that I care about that per se - if there is an error then the return value is no use to me - but unfortunately that has knock-on implications on laziness.

The Writer monad solution pushes out the return value incrementally by a ?side-channel? rather than using the return value and it?s that property which lets it work even in the presence of runExceptionT.

Another approach which would work though is to provide a newtyped Identity monad which handles MonadThrow by _|_, which would allow you to regain laziness (?)

Jules

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/e3585531/attachment.html>

From michael at snoyman.com  Wed Nov  4 19:41:29 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 4 Nov 2015 11:41:29 -0800
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <2775EC12-0298-45CE-ACC3-04C5FB7125C9@jellybean.co.uk>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
 <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
 <2775EC12-0298-45CE-ACC3-04C5FB7125C9@jellybean.co.uk>
Message-ID: <CAKA2JgKiqz90-PajfWh8YQ=e2qSX9AZvQdr3BWyj7pLcuBXfLA@mail.gmail.com>

On Wed, Nov 4, 2015 at 9:28 AM, Jules Bean <jules at jellybean.co.uk> wrote:

>
> On 4 Nov 2015, at 13:04, Michael Snoyman <michael at snoyman.com> wrote:
>
> This got me curious, so I just added a `sourceToList` function to master:
>
>
> https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a
>
>
> Having spent a day thinking this over?
>
> Nothing with the type `Source m a -> m [a]` can work for my second example
> - the one where I use runExceptionT to discharge the MonadThrow constraint.
> This is because once you use runExceptionT you have pushed yourself into
> the situation where in case of error there is no ?return value?.
>
> It?s not that I care about that per se - if there is an error then the
> return value is no use to me - but unfortunately that has knock-on
> implications on laziness.
>
> The Writer monad solution pushes out the return value incrementally by a
> ?side-channel? rather than using the return value and it?s that property
> which lets it work even in the presence of runExceptionT.
>
> Another approach which would work though is to provide a newtyped Identity
> monad which handles MonadThrow by _|_, which would allow you to regain
> laziness (?)
>
> Jules
>
>

I don't think that the Writer example above is demonstrating what you're
saying, since you're using imprecise exceptions (`error`) instead of
MonadThrow. You could do the same thing with sourceToList and get that
result.

You're also correct that some kind of a Identity monad with a MonadThrow
instance based on `throw` would allow this to work.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/1d4686f2/attachment.html>

From edzhavoronkov at gmail.com  Wed Nov  4 22:22:09 2015
From: edzhavoronkov at gmail.com (=?UTF-8?B?0K3QtNCz0LDRgCDQltCw0LLQvtGA0L7QvdC60L7Qsg==?=)
Date: Thu, 5 Nov 2015 01:22:09 +0300
Subject: [Haskell-cafe] Warnings suppression and examples
Message-ID: <CAEvjXHS=ec1jFhw_m8=gi-HhrKp8eiDMbMTYddP7zHhkyYRObg@mail.gmail.com>

Hello everyone!

This may be a strange question, but nevertheless. I am interested in
examples of warnings, thrown by GHC, that you, Haskell programmers, want to
suppress.

To be more precise, i am interested, what kind of warnings you would like
to suppress in:

1. Functions
2. Imports
3. Typeclasses
4. Instances

Thank you!

P.S. I want to implement possibility of warning suppression with single
pragma, that's why i am asking my question here
---
? ?????????,
?????????? ?????

Best regards,
Edgar A. Zhavoronkov
---
? ?????????,
?????????? ?????

Best regards,
Edgar A. Zhavoronkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151105/ec7296a6/attachment.html>

From joehillen at gmail.com  Thu Nov  5 00:17:36 2015
From: joehillen at gmail.com (Joe Hillenbrand)
Date: Wed, 4 Nov 2015 16:17:36 -0800
Subject: [Haskell-cafe] Warnings suppression and examples
In-Reply-To: <CAEvjXHS=ec1jFhw_m8=gi-HhrKp8eiDMbMTYddP7zHhkyYRObg@mail.gmail.com>
References: <CAEvjXHS=ec1jFhw_m8=gi-HhrKp8eiDMbMTYddP7zHhkyYRObg@mail.gmail.com>
Message-ID: <CANJQ5C7kd0inzqRxgsDZW2sE_+c_peHequR9g2i2o0HYAROxyw@mail.gmail.com>

I don't have examples, but something I'd like to ask is for the
warnings that are suppressed to be specific and explicit.

I've had linters in other languages hide bugs because they have a
universal warning suppression flag that suppressed more than the
intended warning.

For example, in Python a #noqa flag that suppressed a long line
warning also hid a warning about an undefined variable.

Here's an example of an alternative approach for Python
https://pypi.python.org/pypi/ebb-lint

On Wed, Nov 4, 2015 at 2:22 PM, ????? ??????????
<edzhavoronkov at gmail.com> wrote:
> Hello everyone!
>
> This may be a strange question, but nevertheless. I am interested in
> examples of warnings, thrown by GHC, that you, Haskell programmers, want to
> suppress.
>
> To be more precise, i am interested, what kind of warnings you would like to
> suppress in:
>
> 1. Functions
> 2. Imports
> 3. Typeclasses
> 4. Instances
>
> Thank you!
>
> P.S. I want to implement possibility of warning suppression with single
> pragma, that's why i am asking my question here
>
> ---
> ? ?????????,
> ?????????? ?????
>
> Best regards,
> Edgar A. Zhavoronkov
> ---
> ? ?????????,
> ?????????? ?????
>
> Best regards,
> Edgar A. Zhavoronkov
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From johnw at newartisans.com  Thu Nov  5 00:53:48 2015
From: johnw at newartisans.com (John Wiegley)
Date: Wed, 04 Nov 2015 19:53:48 -0500
Subject: [Haskell-cafe] Looking for a new maintainer: Bindings-DSL, c2hsc
Message-ID: <m2fv0l5krn.fsf@newartisans.com>

Hello,

The Bindings-DSL libraries, and the c2hsc tool that parses C headers into .hsc
files, both on Hackage, are looking for new maintainers. People are using
these libraries to get real work done, and I no longer wish to be a stumbling
block due to lack of time.

If you're interested, please drop me a line. Anyone with experience at C
parsing would be great, but those with a desire to learn it are good too. I'd
be available to help with questions indefinitely, I just lack the time to stay
on top of every bug.

Thank you,
  John Wiegley

From meditans at gmail.com  Thu Nov  5 01:57:49 2015
From: meditans at gmail.com (Carlo Nucera)
Date: Thu, 5 Nov 2015 02:57:49 +0100
Subject: [Haskell-cafe] Looking for a new maintainer: Bindings-DSL, c2hsc
In-Reply-To: <m2fv0l5krn.fsf@newartisans.com>
References: <m2fv0l5krn.fsf@newartisans.com>
Message-ID: <CALaN21P43B5--Xs3P9QaS4kY+TAr=5bwLhiw849z+zy+q4QEpg@mail.gmail.com>

Hi John,
thanks for the maintenance work you've done on these libraries. I'd
like to learn how they work, so I'd be happy to start co-mantaining
c2hsc (I'll ask a lot of questions, though).

Carlo Nucera

2015-11-05 1:53 GMT+01:00 John Wiegley <johnw at newartisans.com>:
> Hello,
>
> The Bindings-DSL libraries, and the c2hsc tool that parses C headers into .hsc
> files, both on Hackage, are looking for new maintainers. People are using
> these libraries to get real work done, and I no longer wish to be a stumbling
> block due to lack of time.
>
> If you're interested, please drop me a line. Anyone with experience at C
> parsing would be great, but those with a desire to learn it are good too. I'd
> be available to help with questions indefinitely, I just lack the time to stay
> on top of every bug.
>
> Thank you,
>   John Wiegley
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From joehillen at gmail.com  Thu Nov  5 04:01:28 2015
From: joehillen at gmail.com (Joe Hillenbrand)
Date: Wed, 4 Nov 2015 20:01:28 -0800
Subject: [Haskell-cafe] Looking for a new maintainer: Bindings-DSL, c2hsc
In-Reply-To: <m2fv0l5krn.fsf@newartisans.com>
References: <m2fv0l5krn.fsf@newartisans.com>
Message-ID: <CANJQ5C4DLqg-pycrTGKO6+m8M637=NEnfX9Gp1=KGJogzNVytA@mail.gmail.com>

Congrats on the new gig.
On Nov 4, 2015 4:53 PM, "John Wiegley" <johnw at newartisans.com> wrote:

> Hello,
>
> The Bindings-DSL libraries, and the c2hsc tool that parses C headers into
> .hsc
> files, both on Hackage, are looking for new maintainers. People are using
> these libraries to get real work done, and I no longer wish to be a
> stumbling
> block due to lack of time.
>
> If you're interested, please drop me a line. Anyone with experience at C
> parsing would be great, but those with a desire to learn it are good too.
> I'd
> be available to help with questions indefinitely, I just lack the time to
> stay
> on top of every bug.
>
> Thank you,
>   John Wiegley
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151104/d9269cfa/attachment.html>

From ivanperezdominguez at gmail.com  Thu Nov  5 11:58:40 2015
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Thu, 5 Nov 2015 11:58:40 +0000
Subject: [Haskell-cafe] Yampa: upcoming changes;
	maintaining the projects we care about
Message-ID: <CACZKWEKSiXUW52L2Zcar23MWVWhByKRMTCTU4CgCXa6JvTcRug@mail.gmail.com>

Dear all

I am the current maintainer of the FRP implementation Yampa. (For context:
I'm a PhD student at Nottingham, working with Henrik Nilsson.)

Yampa contains legacy code that used to be useful to get things running
quickly. In the interest of having minimal overhead and using existing
robust solutions whenever possible, we'd like to remove some of that old
auxiliary code.

These changes will not affect the core of Yampa (SF definitions, arrow
combinators, switches, etc.), but only auxiliary/miscelaneous stuff (vector
spaces, deep strict evaluation type class, tupling/monad aux functions,
etc.).

We've been introducing these changes progressively over the last year, by
first re-structuring the code base and marking some functions as
deprecated. The time is coming for backwards incompatible changes, but I'd
like to make sure that the projects you care about keep working as before.
This may include (but is not limited to):
* Code (which may not be on hackage, so it may be difficult for me to even
know it exists).
* Examples included in papers, slides, blog posts, etc.

So, if you may be affected by these changes, please:
- Watch the github project [1] and subscribe to yampa-users at cs.yale.edu,
which is where details will be announced. It's a low traffic mailing list.
- If you can deal with it yourself by upgrading your code, please do so.
 Otherwise, feel free to drop a line.
- If your use case does not support easy upgrading (papers? talk videos?)
please let me know. For starters, we may be able to concentrate all the
potential compilation errors that your users might get in one place in the
documentation.
- If you are affected in a way that I'm not seeing, please let me know.

All the best

Ivan

[1] http://github.com/ivanperez-keera/Yampa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151105/a2ad954c/attachment.html>

From me at fujimuradaisuke.com  Thu Nov  5 16:33:49 2015
From: me at fujimuradaisuke.com (Daisuke Fujimura)
Date: Fri, 6 Nov 2015 01:33:49 +0900
Subject: [Haskell-cafe] Where io-streams won't fit,
	comparing to conduit or pipes
Message-ID: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>

Hello cafe,

Now I'm preparing a presentatio for meetup for stream processing in
functional programming(in Tokyo), and my part is something like "why stream
processing library".

While preparing material, I encountered the question that why io-streams is
so simple comparing others, and the reason and downsides behind its
simplicity. I'm guessing it's due to its resource handling strategy, but
not so confident about it because I couldn't came up with a concrete
example yet.

Do you know any good example where io-streams won't fit? Let me know if you
have.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151106/92c11c26/attachment.html>

From greg at gregorycollins.net  Thu Nov  5 17:45:41 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 5 Nov 2015 09:45:41 -0800
Subject: [Haskell-cafe] Where io-streams won't fit,
 comparing to conduit or pipes
In-Reply-To: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>
References: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>
Message-ID: <CAHZrzdr0AkABcCFHf114X=s8ikYBu0195CJ-NB6-auUKu+6pJA@mail.gmail.com>

*Programming style*

Conduits and pipes use a categorical programming model in
continuation-passing style, and implement Monad instances that lift over an
arbitrary base monad. The io-streams library is not polymorphic over the
base monad, instead preferring to fix computations to IO. It's worth
pointing out that stream transformation in io-streams style is also
(implicitly) categorical in style, but in the Kleisli category for IO.

Conduits and pipes take responsibility for controlling the evaluation of
the streaming computation in its entirety, while you can either treat an
Input/OutputStream from io-streams like a Handle and feed work to it
element-wise, or chain an Input and OutputStream together using a
combinator like "connect" in streaming style.

IO-streams only does one-way streaming, while pipes and conduits can pass
data back and forth between different stream transducers.

*Resources and exceptions*

The io-streams library purposely does not do any resource management for
you, with the exception of a few "with*" functions that do some bracketing
for you. The fact that all io-streams computations run in the base IO monad
makes exception handling cheap there, but with the disadvantage that you
e.g. cannot write a stream transducer that will install an exception
handler, yield some elements, and then expect to be notified if a
downstream consumer throws an exception. In general, in io-streams, if
you're an InputStream or OutputStream that has yielded or consumed its
value, you are not guaranteed that your continuation will ever be called
again, so there is no opportunity for you to take on a cleanup action or
release some resources -- that work has to be done outside the streaming
computation. You can think of io-streams as little transducers that attach
to resources.

Since pipes and conduits use continuation-passing monads, the exception
handler problem arises there also, with the difference that since the pipes
or conduits library is running the computation, it's possible to write a
MonadCatch instance (or whatever) can carefully mask/unmask exceptions and
thread an exception handler through the monad continuation for you. The
issue with this is that every monad bind means a masking/unmasking of
exceptions and the installation/cleanup of an exception handler. Usually
people solve this by running in a ResourceT, which punts on the exception
issue for resource handling by installing one exception handler and scoping
all resource acquisition to explicit stack-like (Oleg's paper calls these
"monadic regions") contexts.

*Simplicity*

Both pipes and conduits are *much* more complicated (especially re: type
parameters), but you get additional features to go along with this
complexity so there is an engineering tradeoff there. I designed io-streams
to be as simple as possible and easy to understand for new Haskellers as
possible, while giving me of the features I needed to implement our web
programming framework.

*Correctness/Laws*

All three libraries do well on this front; pipes has had quite a bit of
formal verification done to it, and purports to follow categorical laws.
IO-streams is very simple and has 100% test coverage. Conduits is used by
quite a few people so you can expect solidity there also (but I've never
used it in anger).

*Performance*

All else being equal, an io-streams computation is likely to be slightly
faster than the others because you pay a performance penalty at bind time
for monadic polymorphism. Both pipes and conduits have leveraged their
algebraic/categorical design, however, to create RULES pragmas to do some
kinds of whole-computation stream fusion (i.e. map f . map g should get
turned into "map (f . g)"), which might lessen this disadvantage or even
eliminate it, depending on what kind of computation is happening.

Hope this helps
G

On Thu, Nov 5, 2015 at 8:33 AM, Daisuke Fujimura <me at fujimuradaisuke.com>
wrote:

> Hello cafe,
>
> Now I'm preparing a presentatio for meetup for stream processing in
> functional programming(in Tokyo), and my part is something like "why stream
> processing library".
>
> While preparing material, I encountered the question that why io-streams
> is so simple comparing others, and the reason and downsides behind its
> simplicity. I'm guessing it's due to its resource handling strategy, but
> not so confident about it because I couldn't came up with a concrete
> example yet.
>
> Do you know any good example where io-streams won't fit? Let me know if
> you have.
>
> Thanks!
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151105/914c93be/attachment.html>

From ahammel87 at gmail.com  Thu Nov  5 17:48:52 2015
From: ahammel87 at gmail.com (Alex Hammel)
Date: Thu, 5 Nov 2015 09:48:52 -0800 (PST)
Subject: [Haskell-cafe] Where io-streams won't fit,
 comparing to conduit or pipes
In-Reply-To: <CAHZrzdr0AkABcCFHf114X=s8ikYBu0195CJ-NB6-auUKu+6pJA@mail.gmail.com>
References: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>
 <CAHZrzdr0AkABcCFHf114X=s8ikYBu0195CJ-NB6-auUKu+6pJA@mail.gmail.com>
Message-ID: <4ccdfacc-6251-49e5-8250-40d91052bd13@googlegroups.com>

Thanks for the run-down. I don't know about the OP, but that was certainly 
quite enlightening to me!

On Thursday, 5 November 2015 09:45:49 UTC-8, Gregory Collins wrote:
>
> *Programming style*
>
> Conduits and pipes use a categorical programming model in 
> continuation-passing style, and implement Monad instances that lift over an 
> arbitrary base monad. The io-streams library is not polymorphic over the 
> base monad, instead preferring to fix computations to IO. It's worth 
> pointing out that stream transformation in io-streams style is also 
> (implicitly) categorical in style, but in the Kleisli category for IO.
>
> Conduits and pipes take responsibility for controlling the evaluation of 
> the streaming computation in its entirety, while you can either treat an 
> Input/OutputStream from io-streams like a Handle and feed work to it 
> element-wise, or chain an Input and OutputStream together using a 
> combinator like "connect" in streaming style.
>
> IO-streams only does one-way streaming, while pipes and conduits can pass 
> data back and forth between different stream transducers.
>
> *Resources and exceptions*
>
> The io-streams library purposely does not do any resource management for 
> you, with the exception of a few "with*" functions that do some bracketing 
> for you. The fact that all io-streams computations run in the base IO monad 
> makes exception handling cheap there, but with the disadvantage that you 
> e.g. cannot write a stream transducer that will install an exception 
> handler, yield some elements, and then expect to be notified if a 
> downstream consumer throws an exception. In general, in io-streams, if 
> you're an InputStream or OutputStream that has yielded or consumed its 
> value, you are not guaranteed that your continuation will ever be called 
> again, so there is no opportunity for you to take on a cleanup action or 
> release some resources -- that work has to be done outside the streaming 
> computation. You can think of io-streams as little transducers that attach 
> to resources.
>
> Since pipes and conduits use continuation-passing monads, the exception 
> handler problem arises there also, with the difference that since the pipes 
> or conduits library is running the computation, it's possible to write a 
> MonadCatch instance (or whatever) can carefully mask/unmask exceptions and 
> thread an exception handler through the monad continuation for you. The 
> issue with this is that every monad bind means a masking/unmasking of 
> exceptions and the installation/cleanup of an exception handler. Usually 
> people solve this by running in a ResourceT, which punts on the exception 
> issue for resource handling by installing one exception handler and scoping 
> all resource acquisition to explicit stack-like (Oleg's paper calls these 
> "monadic regions") contexts.
>
> *Simplicity*
>
> Both pipes and conduits are *much* more complicated (especially re: type 
> parameters), but you get additional features to go along with this 
> complexity so there is an engineering tradeoff there. I designed io-streams 
> to be as simple as possible and easy to understand for new Haskellers as 
> possible, while giving me of the features I needed to implement our web 
> programming framework.
>
> *Correctness/Laws*
>
> All three libraries do well on this front; pipes has had quite a bit of 
> formal verification done to it, and purports to follow categorical laws. 
> IO-streams is very simple and has 100% test coverage. Conduits is used by 
> quite a few people so you can expect solidity there also (but I've never 
> used it in anger).
>
> *Performance*
>
> All else being equal, an io-streams computation is likely to be slightly 
> faster than the others because you pay a performance penalty at bind time 
> for monadic polymorphism. Both pipes and conduits have leveraged their 
> algebraic/categorical design, however, to create RULES pragmas to do some 
> kinds of whole-computation stream fusion (i.e. map f . map g should get 
> turned into "map (f . g)"), which might lessen this disadvantage or even 
> eliminate it, depending on what kind of computation is happening.
>
> Hope this helps
> G
>
> On Thu, Nov 5, 2015 at 8:33 AM, Daisuke Fujimura <m... at fujimuradaisuke.com 
> <javascript:>> wrote:
>
>> Hello cafe,
>>
>> Now I'm preparing a presentatio for meetup for stream processing in 
>> functional programming(in Tokyo), and my part is something like "why stream 
>> processing library".
>>
>> While preparing material, I encountered the question that why io-streams 
>> is so simple comparing others, and the reason and downsides behind its 
>> simplicity. I'm guessing it's due to its resource handling strategy, but 
>> not so confident about it because I couldn't came up with a concrete 
>> example yet.
>>
>> Do you know any good example where io-streams won't fit? Let me know if 
>> you have.
>>
>> Thanks!
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskel... at haskell.org <javascript:>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
> -- 
> Gregory Collins <gr... at gregorycollins.net <javascript:>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151105/67633158/attachment.html>

From ariep at xs4all.nl  Thu Nov  5 18:57:25 2015
From: ariep at xs4all.nl (Arie Peterson)
Date: Thu, 05 Nov 2015 19:57:25 +0100
Subject: [Haskell-cafe] How to install newest ghcjs-base
Message-ID: <65764584.Khr8JbEgVe@pook>

5 days ago a change [1] was made to the ghcjs-base library. How can one obtain 
a ghcjs that incorporates such a recent version of ghcjs-base?

I installed ghcjs from git master yesterday, and installed the boot libraries 
using "ghcjs-boot --dev". However, I still get "Module 
?JavaScript.Web.MessageEvent? does not export ?getData?", so apparently my 
ghcjs-base lags behind somehow.

What determines the version of ghcjs-base that is installed?


Regards,

Arie


[1] <https://github.com/ghcjs/ghcjs-base/commit/e827ded07053a3281c50ee52b3e3ebd38286055e>


From stegeman at gmail.com  Thu Nov  5 21:29:40 2015
From: stegeman at gmail.com (Luite Stegeman)
Date: Thu, 05 Nov 2015 21:29:40 +0000
Subject: [Haskell-cafe] How to install newest ghcjs-base
In-Reply-To: <65764584.Khr8JbEgVe@pook>
References: <65764584.Khr8JbEgVe@pook>
Message-ID: <CALqQuoj2krQZczW3anZM17FRynyQh9WJy7sr4arYZ0dkKfpcxA@mail.gmail.com>

That depends on how you install GHCJS. If you do a release build, starting
from a ghcjs-x.y.z.tar.gz sdist (there are some prereleases out there to be
used with stack), then all libraries are taken from this archive.

If you do a development build (boot with --dev), then the ghcjs-boot
program clones the ghcjs-boot repository, which contains ghcjs-base as a
submodule. The submodule determines exactly which ghcjs-base version you
get.

I've been working on the ghcjs-base library recently, but since I had no
way to automatically test things like WebSocket and XMLHttpRequest, much of
that code has only seen rather spotty testing. I've now updated the GHCJS
testsuite to support automated browser testing through Selenium, so I'll be
adding tests and fixing things soon, and bump the submodule when I feel
reasonably confident that it works.

However, unlike ghcjs-prim, ghcjs-base is a fairly normal package that you
can install in your user package database or in a sandbox (there are still
lots of low-level implementation details in there, so don't expect long
term compiler compatibility, but bugfix updates should be ok). So just
clone a copy and install it if you want to help test (or fix) the changes.

luite

On Thu, Nov 5, 2015 at 6:57 PM Arie Peterson <ariep at xs4all.nl> wrote:

> 5 days ago a change [1] was made to the ghcjs-base library. How can one
> obtain
> a ghcjs that incorporates such a recent version of ghcjs-base?
>
> I installed ghcjs from git master yesterday, and installed the boot
> libraries
> using "ghcjs-boot --dev". However, I still get "Module
> ?JavaScript.Web.MessageEvent? does not export ?getData?", so apparently my
> ghcjs-base lags behind somehow.
>
> What determines the version of ghcjs-base that is installed?
>
>
> Regards,
>
> Arie
>
>
> [1] <
> https://github.com/ghcjs/ghcjs-base/commit/e827ded07053a3281c50ee52b3e3ebd38286055e
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151105/29e062ca/attachment.html>

From k-bx at k-bx.com  Fri Nov  6 09:01:24 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Fri, 6 Nov 2015 11:01:24 +0200
Subject: [Haskell-cafe] User guide for DeriveAnyClass
Message-ID: <CAAbahfQ9R0428=uU4sMxQ9AypuO11zoOQOf3kSXZ6POb6v1p9w@mail.gmail.com>

Is there a topic for DeriveAnyClass extension in user guide? It is
mentioned several times in different places, also I see link to it in from
cabal haddocs [0] into its page inside "other type extensions" [1], but it
leads nowhere.

Thank you.

[0]:
https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Language-Haskell-Extension.html
[1]:
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#derive-any-class
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151106/af00bbec/attachment.html>

From ivan.miljenovic at gmail.com  Fri Nov  6 09:08:57 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Fri, 6 Nov 2015 20:08:57 +1100
Subject: [Haskell-cafe] User guide for DeriveAnyClass
In-Reply-To: <CAAbahfQ9R0428=uU4sMxQ9AypuO11zoOQOf3kSXZ6POb6v1p9w@mail.gmail.com>
References: <CAAbahfQ9R0428=uU4sMxQ9AypuO11zoOQOf3kSXZ6POb6v1p9w@mail.gmail.com>
Message-ID: <CA+u6gbzow+B6FWJAP-169hJG3MZ7jy0_jfn7hdyaZZR49WqJGg@mail.gmail.com>

Did you mean this link for the Users Guide?
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.html#derive-any-class

DeriveAny class lets you write

> data Foo = ... deriving (Bar)

instead of:

> data Foo = ...
> instance Bar Foo

(i.e. if it's possible to make it an instance without having to
provide explicit method implementations); as the Users Guide hints
it's primarily useful in cases where default definitions are provided
for you, typically using the DefaultSignatures definition with
GHC.Generics.

On 6 November 2015 at 20:01, Kostiantyn Rybnikov <k-bx at k-bx.com> wrote:
> Is there a topic for DeriveAnyClass extension in user guide? It is mentioned
> several times in different places, also I see link to it in from cabal
> haddocs [0] into its page inside "other type extensions" [1], but it leads
> nowhere.
>
> Thank you.
>
> [0]:
> https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Language-Haskell-Extension.html
> [1]:
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#derive-any-class
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From k-bx at k-bx.com  Fri Nov  6 09:26:50 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Fri, 6 Nov 2015 11:26:50 +0200
Subject: [Haskell-cafe] User guide for DeriveAnyClass
In-Reply-To: <CA+u6gbzow+B6FWJAP-169hJG3MZ7jy0_jfn7hdyaZZR49WqJGg@mail.gmail.com>
References: <CAAbahfQ9R0428=uU4sMxQ9AypuO11zoOQOf3kSXZ6POb6v1p9w@mail.gmail.com>
 <CA+u6gbzow+B6FWJAP-169hJG3MZ7jy0_jfn7hdyaZZR49WqJGg@mail.gmail.com>
Message-ID: <CAAbahfTfq=uYOG==00tVfoXCTvo2agmsmnF4JZQYx7JGgFL=hw@mail.gmail.com>

Ah, thank you, I've seen it before but somehow couldn't find now.

On Fri, Nov 6, 2015 at 11:08 AM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> Did you mean this link for the Users Guide?
>
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.html#derive-any-class
>
> DeriveAny class lets you write
>
> > data Foo = ... deriving (Bar)
>
> instead of:
>
> > data Foo = ...
> > instance Bar Foo
>
> (i.e. if it's possible to make it an instance without having to
> provide explicit method implementations); as the Users Guide hints
> it's primarily useful in cases where default definitions are provided
> for you, typically using the DefaultSignatures definition with
> GHC.Generics.
>
> On 6 November 2015 at 20:01, Kostiantyn Rybnikov <k-bx at k-bx.com> wrote:
> > Is there a topic for DeriveAnyClass extension in user guide? It is
> mentioned
> > several times in different places, also I see link to it in from cabal
> > haddocs [0] into its page inside "other type extensions" [1], but it
> leads
> > nowhere.
> >
> > Thank you.
> >
> > [0]:
> >
> https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Language-Haskell-Extension.html
> > [1]:
> >
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-extensions.html#derive-any-class
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Ivan Lazar Miljenovic
> Ivan.Miljenovic at gmail.com
> http://IvanMiljenovic.wordpress.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151106/838f7609/attachment.html>

From vlatko.basic at gmail.com  Fri Nov  6 15:20:33 2015
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Fri, 6 Nov 2015 16:20:33 +0100
Subject: [Haskell-cafe] Pattern matching with OverloadedLists
Message-ID: <563CC541.1050508@gmail.com>

Hello Cafe,

wiki for OverloadedLists says that

g  [x,y,z]  =  ...

is treated as

g  (toList->  [x,y,z])  =


Shouldn't this work? Both 'f's should be treated the same.

f :: Text -> Int
f (toList -> ('9':_)) = 1   -- OK
f                 ('1':_)  = 2   -- Couldn't match expected type ?Text? with 
actual type ?[Char]?

(OverloadedStrings is also on)

Am I missing something?

br,
vlatko




From trupill at gmail.com  Fri Nov  6 15:38:22 2015
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 6 Nov 2015 16:38:22 +0100
Subject: [Haskell-cafe] Pattern matching with OverloadedLists
In-Reply-To: <563CC541.1050508@gmail.com>
References: <563CC541.1050508@gmail.com>
Message-ID: <CAHnFXOvRn1ta714A5n=CVWd5bBHqDXxKrSuRLzpcFHC1ALFz=w@mail.gmail.com>

You need to write `toList` in both branches:

f (toList -> ('9':_)) = 1
f (toList -> ('1':_)) = 2

2015-11-06 16:20 GMT+01:00 Vlatko Basic <vlatko.basic at gmail.com>:

> Hello Cafe,
>
> wiki for OverloadedLists says that
>
> g  [x,y,z]  =  ...
>
> is treated as
>
> g  (toList->  [x,y,z])  =
>
>
> Shouldn't this work? Both 'f's should be treated the same.
>
> f :: Text -> Int
> f (toList -> ('9':_)) = 1   -- OK
> f                 ('1':_)  = 2   -- Couldn't match expected type ?Text?
> with actual type ?[Char]?
>
> (OverloadedStrings is also on)
>
> Am I missing something?
>
> br,
> vlatko
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151106/1282bff1/attachment.html>

From vlatko.basic at gmail.com  Fri Nov  6 16:35:09 2015
From: vlatko.basic at gmail.com (Vlatko Basic)
Date: Fri, 6 Nov 2015 17:35:09 +0100
Subject: [Haskell-cafe] Pattern matching with OverloadedLists
In-Reply-To: <CAHnFXOvRn1ta714A5n=CVWd5bBHqDXxKrSuRLzpcFHC1ALFz=w@mail.gmail.com>
References: <563CC541.1050508@gmail.com>
 <CAHnFXOvRn1ta714A5n=CVWd5bBHqDXxKrSuRLzpcFHC1ALFz=w@mail.gmail.com>
Message-ID: <563CD6BD.90806@gmail.com>

I was only wondering why doesn't that work.
The two functions were just an example of how I thought OverloadedLists 
should/could work.

I got an answer on irc that ':' constructor is not desugared, but I expected it is.
Compiler can see when overloading is for "real" list and skip it, preserving 
performance.



> -------- Original Message --------
> Subject: Re: [Haskell-cafe] Pattern matching with OverloadedLists
> From: Alejandro Serrano Mena <trupill at gmail.com>
> To: vlatko.basic at gmail.com
> Cc: haskell-cafe <Haskell-cafe at haskell.org>
> Date: 06/11/15 16:38
>
>
> You need to write `toList` in both branches:
>
> f (toList -> ('9':_)) = 1
> f (toList -> ('1':_)) = 2
>
> 2015-11-06 16:20 GMT+01:00 Vlatko Basic <vlatko.basic at gmail.com 
> <mailto:vlatko.basic at gmail.com>>:
>
>     Hello Cafe,
>
>     wiki for OverloadedLists says that
>
>     g  [x,y,z]  =  ...
>
>     is treated as
>
>     g  (toList->  [x,y,z])  =
>
>
>     Shouldn't this work? Both 'f's should be treated the same.
>
>     f :: Text -> Int
>     f (toList -> ('9':_)) = 1   -- OK
>     f                 ('1':_)  = 2   -- Couldn't match expected type ?Text?
>     with actual type ?[Char]?
>
>     (OverloadedStrings is also on)
>
>     Am I missing something?
>
>     br,
>     vlatko
>
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151106/976f42f7/attachment.html>

From mail at nh2.me  Sun Nov  8 00:10:05 2015
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Sun, 8 Nov 2015 01:10:05 +0100
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
Message-ID: <563E92DD.5000708@nh2.me>

Hello everyone,

to my dismay, a -Wall compiled program I deployed today crashed with

  Exception: Non-exhaustive patterns in lambda

and I learned from http://dev.stephendiehl.com/hask/ that

  A more subtle case is when implicitly pattern matching with a single
  "uni-pattern" in a lambda expression. The following will fail when
  given a Nothing.

    boom = \(Just a) -> something

  GHC can warn about these cases with the
  -fwarn-incomplete-uni-patterns flag.

And in fact:

  ghci -Wall
  > map (\Nothing -> "ok") [Just 'a']
  ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda
  > :set -fwarn-incomplete-uni-patterns
  > map (\Nothing -> "ok") [Just 'a']
  <interactive>:4:6: Warning:
      Pattern match(es) are non-exhaustive

It really surprised me that -fwarn-incomplete-uni-patterns is not
included in -Wall; I've felt really safe with my -Wall so far,
especially about totality and similar things that will almost certainly
lead to crashes.

In an older mail from 2010
(https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html)
I saw Simon mention that it wasn't planned to warn about inexhaustive
patterns like this.

I feel like there has been a strong push towards more totality in the
last years, and I would like to ask if enabling
-fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
next GHC version, or if there are still opponents to that.

Niklas

From clintonmead at gmail.com  Sun Nov  8 00:48:20 2015
From: clintonmead at gmail.com (Clinton Mead)
Date: Sun, 8 Nov 2015 11:48:20 +1100
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <563E92DD.5000708@nh2.me>
References: <563E92DD.5000708@nh2.me>
Message-ID: <CAFDVgwGjut5r0kgudMS2YAmoj6AxX+j_BuYtOs9t4A50-FwTZA@mail.gmail.com>

I guess the difference between lambdas and top level functions is that it's
more reasonable to assume top level functions must expect to deal with
every value (particularly when they're part of an interface), whereas
inline lambdas often can reasonably make assumptions about their input.

For example, whilst:

capitalise (l:ls) = (toUpper l):ls

you could argue as bad code because it fails on the empty string case,
something like:

capitalisedDictionary = map (\(l:ls) -> (toUpper l):ls) myDictionary where
  myDIctionary = ...

you could argue is perfectly reasonable code. when the programmer knows
that "myDictionary" doesn't contain any empty strings (perhaps because of
checking that's already occurred).

You could even go further here, and suggest that GHC should have an option
"don't check incomplete patterns", allowing GHC to assume strings are non
empty in this case, blowing up spectacularly C style at run time if this is
incorrect with either a seg fault or launching the nuclear missiles,
although this could allow optimisation opportunities (does GHC already have
such an option?).


On Sun, Nov 8, 2015 at 11:10 AM, Niklas Hamb?chen <mail at nh2.me> wrote:

> Hello everyone,
>
> to my dismay, a -Wall compiled program I deployed today crashed with
>
>   Exception: Non-exhaustive patterns in lambda
>
> and I learned from http://dev.stephendiehl.com/hask/ that
>
>   A more subtle case is when implicitly pattern matching with a single
>   "uni-pattern" in a lambda expression. The following will fail when
>   given a Nothing.
>
>     boom = \(Just a) -> something
>
>   GHC can warn about these cases with the
>   -fwarn-incomplete-uni-patterns flag.
>
> And in fact:
>
>   ghci -Wall
>   > map (\Nothing -> "ok") [Just 'a']
>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda
>   > :set -fwarn-incomplete-uni-patterns
>   > map (\Nothing -> "ok") [Just 'a']
>   <interactive>:4:6: Warning:
>       Pattern match(es) are non-exhaustive
>
> It really surprised me that -fwarn-incomplete-uni-patterns is not
> included in -Wall; I've felt really safe with my -Wall so far,
> especially about totality and similar things that will almost certainly
> lead to crashes.
>
> In an older mail from 2010
> (
> https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html
> )
> I saw Simon mention that it wasn't planned to warn about inexhaustive
> patterns like this.
>
> I feel like there has been a strong push towards more totality in the
> last years, and I would like to ask if enabling
> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
> next GHC version, or if there are still opponents to that.
>
> Niklas
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/f5a667e7/attachment.html>

From will.yager at gmail.com  Sun Nov  8 01:16:21 2015
From: will.yager at gmail.com (William Yager)
Date: Sat, 7 Nov 2015 19:16:21 -0600
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <563E92DD.5000708@nh2.me>
References: <563E92DD.5000708@nh2.me>
Message-ID: <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>

Absolutely agreed. The only time it is generally safe to write pattern
matching lambdas is if the type only has a single constructor. It's very
possible that someone re-factors their code so the type has multiple
constructors, but forgets that they wrote some of these lambda expressions.
-Wall should warn them about this.

--Will

On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hamb?chen <mail at nh2.me> wrote:

> Hello everyone,
>
> to my dismay, a -Wall compiled program I deployed today crashed with
>
>   Exception: Non-exhaustive patterns in lambda
>
> and I learned from http://dev.stephendiehl.com/hask/ that
>
>   A more subtle case is when implicitly pattern matching with a single
>   "uni-pattern" in a lambda expression. The following will fail when
>   given a Nothing.
>
>     boom = \(Just a) -> something
>
>   GHC can warn about these cases with the
>   -fwarn-incomplete-uni-patterns flag.
>
> And in fact:
>
>   ghci -Wall
>   > map (\Nothing -> "ok") [Just 'a']
>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda
>   > :set -fwarn-incomplete-uni-patterns
>   > map (\Nothing -> "ok") [Just 'a']
>   <interactive>:4:6: Warning:
>       Pattern match(es) are non-exhaustive
>
> It really surprised me that -fwarn-incomplete-uni-patterns is not
> included in -Wall; I've felt really safe with my -Wall so far,
> especially about totality and similar things that will almost certainly
> lead to crashes.
>
> In an older mail from 2010
> (
> https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html
> )
> I saw Simon mention that it wasn't planned to warn about inexhaustive
> patterns like this.
>
> I feel like there has been a strong push towards more totality in the
> last years, and I would like to ask if enabling
> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
> next GHC version, or if there are still opponents to that.
>
> Niklas
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151107/aa32457d/attachment.html>

From apostolis.xekoukoulotakis at gmail.com  Sun Nov  8 01:21:21 2015
From: apostolis.xekoukoulotakis at gmail.com (Apostolis Xekoukoulotakis)
Date: Sun, 8 Nov 2015 03:21:21 +0200
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
References: <563E92DD.5000708@nh2.me>
 <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
Message-ID: <CAFEV_-hv6hSV2aqjTojbPVM45c5jHztqC8Rq-TSnvZAHqW9d_w@mail.gmail.com>

Just learning Haskell here but I also agree. Rust gives a compile error by
default for non-exhaustive patterns.
I expect Haskell to be more secure than Rust.

https://doc.rust-lang.org/book/match.html

On Sun, Nov 8, 2015 at 3:16 AM, William Yager <will.yager at gmail.com> wrote:

> Absolutely agreed. The only time it is generally safe to write pattern
> matching lambdas is if the type only has a single constructor. It's very
> possible that someone re-factors their code so the type has multiple
> constructors, but forgets that they wrote some of these lambda expressions.
> -Wall should warn them about this.
>
> --Will
>
> On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
>
>> Hello everyone,
>>
>> to my dismay, a -Wall compiled program I deployed today crashed with
>>
>>   Exception: Non-exhaustive patterns in lambda
>>
>> and I learned from http://dev.stephendiehl.com/hask/ that
>>
>>   A more subtle case is when implicitly pattern matching with a single
>>   "uni-pattern" in a lambda expression. The following will fail when
>>   given a Nothing.
>>
>>     boom = \(Just a) -> something
>>
>>   GHC can warn about these cases with the
>>   -fwarn-incomplete-uni-patterns flag.
>>
>> And in fact:
>>
>>   ghci -Wall
>>   > map (\Nothing -> "ok") [Just 'a']
>>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda
>>   > :set -fwarn-incomplete-uni-patterns
>>   > map (\Nothing -> "ok") [Just 'a']
>>   <interactive>:4:6: Warning:
>>       Pattern match(es) are non-exhaustive
>>
>> It really surprised me that -fwarn-incomplete-uni-patterns is not
>> included in -Wall; I've felt really safe with my -Wall so far,
>> especially about totality and similar things that will almost certainly
>> lead to crashes.
>>
>> In an older mail from 2010
>> (
>> https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html
>> )
>> I saw Simon mention that it wasn't planned to warn about inexhaustive
>> patterns like this.
>>
>> I feel like there has been a strong push towards more totality in the
>> last years, and I would like to ask if enabling
>> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
>> next GHC version, or if there are still opponents to that.
>>
>> Niklas
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/bbbc5a1f/attachment.html>

From plredmond at gmail.com  Sun Nov  8 01:29:00 2015
From: plredmond at gmail.com (Patrick Redmond)
Date: Sat, 7 Nov 2015 17:29:00 -0800
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <CAFEV_-hv6hSV2aqjTojbPVM45c5jHztqC8Rq-TSnvZAHqW9d_w@mail.gmail.com>
References: <563E92DD.5000708@nh2.me>
 <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
 <CAFEV_-hv6hSV2aqjTojbPVM45c5jHztqC8Rq-TSnvZAHqW9d_w@mail.gmail.com>
Message-ID: <CAHUea4HXhuOaH5pbz1OnhaEMxjycNCDtkma-fG+zXMiJOqX+3g@mail.gmail.com>

Clinton:
> when the programmer knows that "myDictionary" doesn't contain any empty strings (perhaps because of checking that's already occurred).

I think if the non-empty string invariant is only required for the
implementation of one function, it might be safe write a lambda which
assumes the invariant, but in general such assumptions are better
expressed through the type system (eg, a newtype with only a smart
constructor exposed, which checks that the string is nonempty).

William:
> It's very possible that someone re-factors their code so the type has multiple constructors, but forgets that they wrote some of these lambda expressions. -Wall should warn them about this.

Yikes. This is a very good argument for these warnings to be enabled.
I'll probably modify the `stack new` project template to include
-fwarn-incomplete-uni-patterns in the cabal file for the time being.

On Sat, Nov 7, 2015 at 5:21 PM, Apostolis Xekoukoulotakis
<apostolis.xekoukoulotakis at gmail.com> wrote:
> Just learning Haskell here but I also agree. Rust gives a compile error by
> default for non-exhaustive patterns.
> I expect Haskell to be more secure than Rust.
>
> https://doc.rust-lang.org/book/match.html
>
> On Sun, Nov 8, 2015 at 3:16 AM, William Yager <will.yager at gmail.com> wrote:
>>
>> Absolutely agreed. The only time it is generally safe to write pattern
>> matching lambdas is if the type only has a single constructor. It's very
>> possible that someone re-factors their code so the type has multiple
>> constructors, but forgets that they wrote some of these lambda expressions.
>> -Wall should warn them about this.
>>
>> --Will
>>
>> On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
>>>
>>> Hello everyone,
>>>
>>> to my dismay, a -Wall compiled program I deployed today crashed with
>>>
>>>   Exception: Non-exhaustive patterns in lambda
>>>
>>> and I learned from http://dev.stephendiehl.com/hask/ that
>>>
>>>   A more subtle case is when implicitly pattern matching with a single
>>>   "uni-pattern" in a lambda expression. The following will fail when
>>>   given a Nothing.
>>>
>>>     boom = \(Just a) -> something
>>>
>>>   GHC can warn about these cases with the
>>>   -fwarn-incomplete-uni-patterns flag.
>>>
>>> And in fact:
>>>
>>>   ghci -Wall
>>>   > map (\Nothing -> "ok") [Just 'a']
>>>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in
>>> lambda
>>>   > :set -fwarn-incomplete-uni-patterns
>>>   > map (\Nothing -> "ok") [Just 'a']
>>>   <interactive>:4:6: Warning:
>>>       Pattern match(es) are non-exhaustive
>>>
>>> It really surprised me that -fwarn-incomplete-uni-patterns is not
>>> included in -Wall; I've felt really safe with my -Wall so far,
>>> especially about totality and similar things that will almost certainly
>>> lead to crashes.
>>>
>>> In an older mail from 2010
>>>
>>> (https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html)
>>> I saw Simon mention that it wasn't planned to warn about inexhaustive
>>> patterns like this.
>>>
>>> I feel like there has been a strong push towards more totality in the
>>> last years, and I would like to ask if enabling
>>> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
>>> next GHC version, or if there are still opponents to that.
>>>
>>> Niklas
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From adam at bergmark.nl  Sun Nov  8 03:19:13 2015
From: adam at bergmark.nl (Adam Bergmark)
Date: Sun, 8 Nov 2015 04:19:13 +0100
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <CAHUea4HXhuOaH5pbz1OnhaEMxjycNCDtkma-fG+zXMiJOqX+3g@mail.gmail.com>
References: <563E92DD.5000708@nh2.me>
 <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
 <CAFEV_-hv6hSV2aqjTojbPVM45c5jHztqC8Rq-TSnvZAHqW9d_w@mail.gmail.com>
 <CAHUea4HXhuOaH5pbz1OnhaEMxjycNCDtkma-fG+zXMiJOqX+3g@mail.gmail.com>
Message-ID: <CACnqJZYdqwg4-w0u-x7xR6ipAo5AOH_RpGy86zPjLBubKrA0Ug@mail.gmail.com>

I agree that this should be included in -Wall. I've many times added a uni
pattern "temporarily" and sometimes forgotten to fix it later on.

- Adam


On Sun, Nov 8, 2015 at 2:29 AM, Patrick Redmond <plredmond at gmail.com> wrote:

> Clinton:
> > when the programmer knows that "myDictionary" doesn't contain any empty
> strings (perhaps because of checking that's already occurred).
>
> I think if the non-empty string invariant is only required for the
> implementation of one function, it might be safe write a lambda which
> assumes the invariant, but in general such assumptions are better
> expressed through the type system (eg, a newtype with only a smart
> constructor exposed, which checks that the string is nonempty).
>
> William:
> > It's very possible that someone re-factors their code so the type has
> multiple constructors, but forgets that they wrote some of these lambda
> expressions. -Wall should warn them about this.
>
> Yikes. This is a very good argument for these warnings to be enabled.
> I'll probably modify the `stack new` project template to include
> -fwarn-incomplete-uni-patterns in the cabal file for the time being.
>
> On Sat, Nov 7, 2015 at 5:21 PM, Apostolis Xekoukoulotakis
> <apostolis.xekoukoulotakis at gmail.com> wrote:
> > Just learning Haskell here but I also agree. Rust gives a compile error
> by
> > default for non-exhaustive patterns.
> > I expect Haskell to be more secure than Rust.
> >
> > https://doc.rust-lang.org/book/match.html
> >
> > On Sun, Nov 8, 2015 at 3:16 AM, William Yager <will.yager at gmail.com>
> wrote:
> >>
> >> Absolutely agreed. The only time it is generally safe to write pattern
> >> matching lambdas is if the type only has a single constructor. It's very
> >> possible that someone re-factors their code so the type has multiple
> >> constructors, but forgets that they wrote some of these lambda
> expressions.
> >> -Wall should warn them about this.
> >>
> >> --Will
> >>
> >> On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
> >>>
> >>> Hello everyone,
> >>>
> >>> to my dismay, a -Wall compiled program I deployed today crashed with
> >>>
> >>>   Exception: Non-exhaustive patterns in lambda
> >>>
> >>> and I learned from http://dev.stephendiehl.com/hask/ that
> >>>
> >>>   A more subtle case is when implicitly pattern matching with a single
> >>>   "uni-pattern" in a lambda expression. The following will fail when
> >>>   given a Nothing.
> >>>
> >>>     boom = \(Just a) -> something
> >>>
> >>>   GHC can warn about these cases with the
> >>>   -fwarn-incomplete-uni-patterns flag.
> >>>
> >>> And in fact:
> >>>
> >>>   ghci -Wall
> >>>   > map (\Nothing -> "ok") [Just 'a']
> >>>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in
> >>> lambda
> >>>   > :set -fwarn-incomplete-uni-patterns
> >>>   > map (\Nothing -> "ok") [Just 'a']
> >>>   <interactive>:4:6: Warning:
> >>>       Pattern match(es) are non-exhaustive
> >>>
> >>> It really surprised me that -fwarn-incomplete-uni-patterns is not
> >>> included in -Wall; I've felt really safe with my -Wall so far,
> >>> especially about totality and similar things that will almost certainly
> >>> lead to crashes.
> >>>
> >>> In an older mail from 2010
> >>>
> >>> (
> https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html
> )
> >>> I saw Simon mention that it wasn't planned to warn about inexhaustive
> >>> patterns like this.
> >>>
> >>> I feel like there has been a strong push towards more totality in the
> >>> last years, and I would like to ask if enabling
> >>> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a
> coming
> >>> next GHC version, or if there are still opponents to that.
> >>>
> >>> Niklas
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe at haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/be7c2c61/attachment.html>

From mail at joachim-breitner.de  Sun Nov  8 08:36:13 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 08 Nov 2015 09:36:13 +0100
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <563E92DD.5000708@nh2.me>
References: <563E92DD.5000708@nh2.me>
Message-ID: <1446971773.1771.4.camel@joachim-breitner.de>

Hi Niklas,

Am Sonntag, den 08.11.2015, 01:10 +0100 schrieb Niklas Hamb?chen:
> In an older mail from 2010
> (https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-Septem
> ber/019237.html)
> I saw Simon mention that it wasn't planned to warn about inexhaustive
> patterns like this.

note that in that mail, he refers to patterns in where clauses, which
is a different use-case than the lambdas you refer to.

GHC is a large code base that traditionally is kept -Wall clean. You
could make your proposal a bit more substantial by compiling GHC with
-fwarn-incomplete-uni-patterns on and see what breaks, what the usual
use-cases are, how to change the code to make it clean again.

Then you are in a good position to argue that it is an improvement (or
you will find that SPJ, as very often, has a good instinct and making
it warn about that prohibits many useful idioms.)

Personally, I?m sympathetic to ?he who uses -Wall gets to jump through
hoops?, but incomplete where patterns that bind variables that are not
used in all cases are useful...

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/74f802e2/attachment.sig>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Nov  8 09:30:09 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 8 Nov 2015 09:30:09 +0000
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <1446971773.1771.4.camel@joachim-breitner.de>
References: <563E92DD.5000708@nh2.me>
 <1446971773.1771.4.camel@joachim-breitner.de>
Message-ID: <20151108093009.GR10714@weber>

On Sun, Nov 08, 2015 at 09:36:13AM +0100, Joachim Breitner wrote:
> Am Sonntag, den 08.11.2015, 01:10 +0100 schrieb Niklas Hamb?chen:
> > In an older mail from 2010
> > (https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-Septem
> > ber/019237.html)
> > I saw Simon mention that it wasn't planned to warn about inexhaustive
> > patterns like this.
> 
> note that in that mail, he refers to patterns in where clauses, which
> is a different use-case than the lambdas you refer to.
>
[...]
> 
> Then you are in a good position to argue that it is an improvement (or
> you will find that SPJ, as very often, has a good instinct and making
> it warn about that prohibits many useful idioms.)

Simon's code is inadvisable, in my opinion.  It is

    f xs | null xs = blah
         | otherwise = x+1
         where
           (x:_) = xs

where it really should be

    f xs = case xs of []    -> blah
                      (x:_) -> x + 1

Tom

From mail at joachim-breitner.de  Sun Nov  8 09:42:35 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 08 Nov 2015 10:42:35 +0100
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <20151108093009.GR10714@weber>
References: <563E92DD.5000708@nh2.me>
 <1446971773.1771.4.camel@joachim-breitner.de>
 <20151108093009.GR10714@weber>
Message-ID: <1446975755.1771.16.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 08.11.2015, 09:30 +0000 schrieb Tom Ellis:
> Simon's code is inadvisable, in my opinion.??It is
> 
> ????f xs | null xs = blah
> ?????????| otherwise = x+1
> ?????????where
> ???????????(x:_) = xs
> 
> where it really should be
> 
> ????f xs = case xs of []????-> blah
> ??????????????????????(x:_) -> x + 1
> 

yes, in this particular, small example

But often you have complex decisions in the guards that are not
obviously related to the pattern match, and the where-bound and
partially-pattern-matched value are used in multiple branches of the
guard.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/a63c2962/attachment.sig>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Nov  8 09:49:18 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 8 Nov 2015 09:49:18 +0000
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <1446975755.1771.16.camel@joachim-breitner.de>
References: <563E92DD.5000708@nh2.me>
 <1446971773.1771.4.camel@joachim-breitner.de>
 <20151108093009.GR10714@weber>
 <1446975755.1771.16.camel@joachim-breitner.de>
Message-ID: <20151108094918.GA17422@weber>

On Sun, Nov 08, 2015 at 10:42:35AM +0100, Joachim Breitner wrote:
> Am Sonntag, den 08.11.2015, 09:30 +0000 schrieb Tom Ellis:
> > Simon's code is inadvisable, in my opinion.??It is
> > 
> > ????f xs | null xs = blah
> > ?????????| otherwise = x+1
> > ?????????where
> > ???????????(x:_) = xs
> > 
> > where it really should be
> > 
> > ????f xs = case xs of []????-> blah
> > ??????????????????????(x:_) -> x + 1
> > 
> 
> yes, in this particular, small example
> 
> But often you have complex decisions in the guards that are not
> obviously related to the pattern match, and the where-bound and
> partially-pattern-matched value are used in multiple branches of the
> guard.

I can't address less particular, larger, examples until I'm shown them, but
I am going to make the very bold claim that there's *always* a version
without partial pattern matches that is at least as clear as the original. 
I strongly encourage you to challenge me on this claim!

Tom

From petr.mvd at gmail.com  Sun Nov  8 13:19:33 2015
From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=)
Date: Sun, 08 Nov 2015 13:19:33 +0000
Subject: [Haskell-cafe] More death to partial functions: Should
 -fwarn-incomplete-uni-patterns be enabled with -Wall?
In-Reply-To: <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
References: <563E92DD.5000708@nh2.me>
 <CAG8oi1OWsm-JtN-RWAvG2f3LFpk-p08g74uHFzmBu0HDX1o6GA@mail.gmail.com>
Message-ID: <CABSda-cGyxBdXqPfKRRMZXN3QyyR+o4crqrtHJw2VDdwn3TNAg@mail.gmail.com>

ne 8. 11. 2015 v 2:16 odes?latel William Yager <will.yager at gmail.com>
napsal:

> Absolutely agreed. The only time it is generally safe to write pattern
> matching lambdas is if the type only has a single constructor. It's very
> possible that someone re-factors their code so the type has multiple
> constructors, but forgets that they wrote some of these lambda expressions.
> -Wall should warn them about this.
>
> +1


> --Will
>
> On Sat, Nov 7, 2015 at 6:10 PM, Niklas Hamb?chen <mail at nh2.me> wrote:
>
>> Hello everyone,
>>
>> to my dismay, a -Wall compiled program I deployed today crashed with
>>
>>   Exception: Non-exhaustive patterns in lambda
>>
>> and I learned from http://dev.stephendiehl.com/hask/ that
>>
>>   A more subtle case is when implicitly pattern matching with a single
>>   "uni-pattern" in a lambda expression. The following will fail when
>>   given a Nothing.
>>
>>     boom = \(Just a) -> something
>>
>>   GHC can warn about these cases with the
>>   -fwarn-incomplete-uni-patterns flag.
>>
>> And in fact:
>>
>>   ghci -Wall
>>   > map (\Nothing -> "ok") [Just 'a']
>>   ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda
>>   > :set -fwarn-incomplete-uni-patterns
>>   > map (\Nothing -> "ok") [Just 'a']
>>   <interactive>:4:6: Warning:
>>       Pattern match(es) are non-exhaustive
>>
>> It really surprised me that -fwarn-incomplete-uni-patterns is not
>> included in -Wall; I've felt really safe with my -Wall so far,
>> especially about totality and similar things that will almost certainly
>> lead to crashes.
>>
>> In an older mail from 2010
>> (
>> https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019237.html
>> )
>> I saw Simon mention that it wasn't planned to warn about inexhaustive
>> patterns like this.
>>
>> I feel like there has been a strong push towards more totality in the
>> last years, and I would like to ask if enabling
>> -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming
>> next GHC version, or if there are still opponents to that.
>>
>> Niklas
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/e11e59e4/attachment.html>

From clintonmead at gmail.com  Mon Nov  9 00:41:27 2015
From: clintonmead at gmail.com (Clinton Mead)
Date: Mon, 9 Nov 2015 11:41:27 +1100
Subject: [Haskell-cafe] How to get GHC to produce ADC instructions for long
	addition
Message-ID: <CAFDVgwHGph1brPtD1C5wAh87v+mWmrowBF3yF2Aw=tGVHqahXg@mail.gmail.com>

Here is some code that adds two 192 bit numbers, represented as three 64bit
machine words (well, on my machine anyway), and returns the result and any
carry:

{-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Prim(
plusWord2#, Word#, or#) longAdd :: (# Word#, Word#, Word# #) -> (# Word#,
Word#, Word# #) -> (# Word#, (# Word#, Word#, Word# #) #) longAdd (# xl, xm,
xh #) (# yl, ym, yh #) = let plusWord2WithCarry x y c = let (# c1, r1 #) =
plusWord2# x y (# c2, r2 #) = plusWord2# r1 c in (# plusWord# c1 c2, r2 #)
(# cl, rl #) = plusWord2# xl yl (# cm, rm #) = plusWord2WithCarry xm ym cl
(# ch, rh #) = plusWord2WithCarry xh yh cm
in (# ch, (# rl, rm, rh #) #)

(My code covers words other than size 3 btw)

I'd like this to compile into something like:

add x1 y1
adc x2 y2
adc x3 y3

Unfortunately, I think my problem is with the "plusWord2WithCarry". As
there's no primitive operation in Haskell which adds two words and a carry.
What seems to happen when I look at the generated assembly is the following:

xor some_reg_1 some_reg_1
add x1 y1
adc $0 some_reg_1
xor some_reg_2 some_reg_2
adc x2 y2
adc $0 some_reg_2
xor some_reg_3 some_reg_3
adc some_reg_1 y2
adc $0 some_reg_3
add some_reg_2 some_reg_3
... and so on


Basically, instead of just using the carry flag in add of the next two
higher words, it instead saves it to a register, adds the next higher order
words without the carry, clears a register and then adds the carry to this
register, adds the first mentioned carry, against clears a register and
saves that carry, combines the two resulting carries and passes it to the
next higher order addition. I know that sounds complex, and the code is a
bit of a mess.

Bizarrely, when I send it through the LLVM backend it ends up worse,
generating a bunch of 32 bit shifts for reasons I can't understand.

I was hoping the LLVM backend would be able to produce the "adc"
instructions. Is there anything I could do to coax it into it. I know
writing it in C (or inline assembly in C) is an option, but after you add
the code to call and return such a small amount of work it seems hardly
worth it. I'd like to keep it in GHC so it can be inlined where
appropriate.

Any ideas on how to entice GHC (either natively or via LLVM) to produce
better code in this case?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151109/bcf71742/attachment.html>

From jeremy at n-heptane.com  Mon Nov  9 01:41:31 2015
From: jeremy at n-heptane.com (Jeremy Shaw)
Date: Sun, 8 Nov 2015 19:41:31 -0600
Subject: [Haskell-cafe] Where io-streams won't fit,
 comparing to conduit or pipes
In-Reply-To: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>
References: <CAOtUY6Kw_xiR_r_7owk6v0k9O4x2Bn30Cvt1MWLvg01Tm=K1zQ@mail.gmail.com>
Message-ID: <CAGE_JKYEuVnxRF+ts-pVWdXn9paQNPYHPeGrm3VQ+xSKz332qw@mail.gmail.com>

A slight take on what Gregory said is that io-streams is fundamentally
about streaming IO, where is pipes can be used with any base monad,
including Identity or other pure monads -- not just ones that implement
MonadIO. So if you want to compose pure streaming operations, you would
likely prefer pipes. I think conduits works that way as well now (it
originally was also IO-only).

- jeremy

On Thu, Nov 5, 2015 at 10:33 AM, Daisuke Fujimura <me at fujimuradaisuke.com>
wrote:

> Hello cafe,
>
> Now I'm preparing a presentatio for meetup for stream processing in
> functional programming(in Tokyo), and my part is something like "why stream
> processing library".
>
> While preparing material, I encountered the question that why io-streams
> is so simple comparing others, and the reason and downsides behind its
> simplicity. I'm guessing it's due to its resource handling strategy, but
> not so confident about it because I couldn't came up with a concrete
> example yet.
>
> Do you know any good example where io-streams won't fit? Let me know if
> you have.
>
> Thanks!
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151108/b1afbb4b/attachment.html>

From spam at scientician.net  Mon Nov  9 05:18:59 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 9 Nov 2015 06:18:59 +0100
Subject: [Haskell-cafe] Anybody using the "top-down" cabal-install solver?
Message-ID: <n1pac3$tko$1@ger.gmane.org>

(Sorry if you get this twice, forgot to cross-post to -cafe initially.)

Hi all,

Just to get input from as many people as possible: I was pondering a
plan for modularizing[2] the Cabal solver[1] and wanted to reach as many
people as possible with my question:

   Is anybody is still using the top-down solver?

Please respond to this list if you are, especially if you're doing so
because there's no other way to get the modular solver to do what you
want. (Obviously, I'm not promising to fix any problems you may have
with the modular solver, but it would be valuable information since it
could affect the decision of whether we have to keep the top-down solver
around.)

Regards,

--
[1] https://github.com/haskell/cabal/pull/2768#issuecomment-154917165

[2] "Splitting it out into its own library" is perhaps a more accurate
description, but somewhat unwieldly :).


From guillaumh at gmail.com  Mon Nov  9 14:17:44 2015
From: guillaumh at gmail.com (Guillaume Hoffmann)
Date: Mon, 9 Nov 2015 11:17:44 -0300
Subject: [Haskell-cafe] darcs 2.10.2 release
Message-ID: <CADw8UJprRJBe6h+RG2yLMyOpA_FHU8wFWoQYFZegSq6CJWL=uQ@mail.gmail.com>

The darcs team is pleased to announce the release of darcs 2.10.2 !

# Downloading #

The easiest way to install darcs 2.10.2 from source is by first
installing the Haskell Platform (http://www.haskell.org/platform). If
you have installed the Haskell Platform or cabal-install, you can
install this release by doing:

$ cabal update
$ cabal install darcs-2.10.2

Alternatively, you can download the tarball from
http://darcs.net/releases/darcs-2.10.2.tar.gz and build it by hand as
explained in the README file.

The 2.10 branch is also available as a darcs repository from
http://darcs.net/releases/branch-2.10

# What's new in 2.10.2 (since 2.10.1) #

 * optimize patch apply code memory use
 * make patch selection lazier in presence of matchers
 * switch patches retrieval order when using packs
 * switch from dataenc (deprecated) to sandi
 * finish updating help strings with new command names
 * clean contrib scripts
 * disable mmap on Windows
 * enhance darcs send message
 * fix quickcheck suite
 * shorter README with quickstart instructions
 * fixed the following bugs:

    * 2457: fix darcs-test command line options
    * 2463: building darcs on powerpc
    * 2444: added default interactivity parameter to isInteractive

# Feedback #

If you have an issue with darcs 2.10.2, you can report it on
http://bugs.darcs.net/ . You can also report bugs by email to
bugs at darcs.net, or come to #darcs on irc.freenode.net.

From hjgtuyl at chello.nl  Mon Nov  9 17:51:20 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Mon, 09 Nov 2015 18:51:20 +0100
Subject: [Haskell-cafe] darcs 2.10.2 release
In-Reply-To: <CADw8UJprRJBe6h+RG2yLMyOpA_FHU8wFWoQYFZegSq6CJWL=uQ@mail.gmail.com>
References: <CADw8UJprRJBe6h+RG2yLMyOpA_FHU8wFWoQYFZegSq6CJWL=uQ@mail.gmail.com>
Message-ID: <op.x7ug7ztxpz0j5l@alquantor>

On Mon, 09 Nov 2015 15:17:44 +0100, Guillaume Hoffmann  
<guillaumh at gmail.com> wrote:

> The darcs team is pleased to announce the release of darcs 2.10.2 !
>
> # Downloading #
>
> The easiest way to install darcs 2.10.2 from source is by first
> installing the Haskell Platform (http://www.haskell.org/platform). If
> you have installed the Haskell Platform or cabal-install, you can
> install this release by doing:
>
> $ cabal update
> $ cabal install darcs-2.10.2

Windows users must use
   cabal install darcs-2.10.2 -f-curl

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From guillaumh at gmail.com  Mon Nov  9 22:40:31 2015
From: guillaumh at gmail.com (Guillaume Hoffmann)
Date: Mon, 9 Nov 2015 19:40:31 -0300
Subject: [Haskell-cafe] darcs 2.10.2 release
In-Reply-To: <op.x7ug7ztxpz0j5l@alquantor>
References: <CADw8UJprRJBe6h+RG2yLMyOpA_FHU8wFWoQYFZegSq6CJWL=uQ@mail.gmail.com>
 <op.x7ug7ztxpz0j5l@alquantor>
Message-ID: <CADw8UJq92Tg4vgn8CcajvVqOu2UBnkkh20TVi0jKJri__73Zpw@mail.gmail.com>

Thanks Henk-Jan!

My setup is very linux-and-cabal centric so help like this is very
welcome. I also had feedback about how to provide build instructions
with stack.

Guillaume

2015-11-09 14:51 GMT-03:00 Henk-Jan van Tuyl <hjgtuyl at chello.nl>:
> On Mon, 09 Nov 2015 15:17:44 +0100, Guillaume Hoffmann <guillaumh at gmail.com>
> wrote:
>
>> The darcs team is pleased to announce the release of darcs 2.10.2 !
>>
>> # Downloading #
>>
>> The easiest way to install darcs 2.10.2 from source is by first
>> installing the Haskell Platform (http://www.haskell.org/platform). If
>> you have installed the Haskell Platform or cabal-install, you can
>> install this release by doing:
>>
>> $ cabal update
>> $ cabal install darcs-2.10.2
>
>
> Windows users must use
>   cabal install darcs-2.10.2 -f-curl
>
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> Folding at home
> What if you could share your unused computer power to help find a cure? In
> just 5 minutes you can join the world's biggest networked computer and get
> us closer sooner. Watch the video.
> http://folding.stanford.edu/
>
>
> http://Van.Tuyl.eu/
> http://members.chello.nl/hjgtuyl/tourdemonad.html
> Haskell programming
> --

From erkokl at gmail.com  Tue Nov 10 03:03:34 2015
From: erkokl at gmail.com (Levent Erkok)
Date: Mon, 9 Nov 2015 19:03:34 -0800
Subject: [Haskell-cafe] [ANN] SBV 5.4 is out
Message-ID: <CACOpX0fS9OFSMjqu42xQmjc_V8wPs0pYRJOcVYsfgUOcXG5rrw@mail.gmail.com>

I'm happy to announce a new release (v5.4) of SBV: SMT Based Verification.
See: http://hackage.haskell.org/package/sbv

New in this release is the 'sAssert' function, which allows
boolean-assertions to be sprinkled in symbolic code, which can then be
statically discharged (or shown violating assignments for) using the 'safe'
function. See:
http://hackage.haskell.org/package/sbv-5.4/docs/Data-SBV.html#g:39

A slightly larger example checks for lack-of-division-by-0 in a simple
program:
http://hackage.haskell.org/package/sbv-5.4/docs/Data-SBV-Examples-Misc-NoDiv0.html

Further documentation on SBV is available at:
http://leventerkok.github.io/sbv/

Calls to sAssert calls are also preserved in the SBV->C compilation path.
This feature is rather experimental and , and I'd love to hear if you give
it a try and see any gotchas..

Happy proving.

-Levent.

PS. Thanks to Brett Letner for suggesting this functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151109/55bebed1/attachment.html>

From capn.freako at gmail.com  Tue Nov 10 16:15:39 2015
From: capn.freako at gmail.com (David Banas)
Date: Tue, 10 Nov 2015 08:15:39 -0800
Subject: [Haskell-cafe] Question, re: illegal instance error.
Message-ID: <495D63F3-8252-409E-AC77-5C9C380FCCE3@gmail.com>

Hi all,

I don?t understand why this code:

50: instance (IsNat n, RealFloat a) => FFT (RTree n) a where

is generating this error:

fft_test.hs:50:36:
    Illegal instance declaration for ?FFT (RTree n) a?
      (All instance types must be of the form (T a1 ... an)
       where a1 ... an are *distinct type variables*,
       and each type variable appears at most once in the instance head.
       Use FlexibleInstances if you want to disable this.)
    In the instance declaration for ?FFT (RTree n) a?

and was hoping someone could help me get it.

Thanks!
-db

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151110/da262128/attachment.html>

From achudnov at gmail.com  Tue Nov 10 16:41:43 2015
From: achudnov at gmail.com (Andrey Chudnov)
Date: Tue, 10 Nov 2015 11:41:43 -0500
Subject: [Haskell-cafe] Question, re: illegal instance error.
In-Reply-To: <495D63F3-8252-409E-AC77-5C9C380FCCE3@gmail.com>
References: <495D63F3-8252-409E-AC77-5C9C380FCCE3@gmail.com>
Message-ID: <56421E47.8020208@gmail.com>

 From the Haskell 2010 report: "An instance declaration introduces an 
instance of a class. Let class cx=> C uwhere{ cbody} be a class 
declaration. The general form of the corresponding instance declaration 
is: instance cx?=> C(T u_1 ? u_k )where{ d} where k ? 0."

Note that your instance declaration has a form C (T u1) u2.

I think adding the FlexibleInstances extension, as suggested by the 
compiler, will work. Although, depending on the context, you might need 
UndecidableInstances too.

The core problem is that the FFT class must have been defined with the 
MultiParamTypeClasses extension, which usually leads to nastiness like this.

On 11/10/2015 11:15 AM, David Banas wrote:
> Hi all,
>
> I don?t understand why this code:
>
> 50: instance (IsNat n, RealFloat a) => FFT (RTree n) a where
>
> is generating this error:
>
> fft_test.hs:50:36:
>   Illegal instance declaration for ?FFT (RTree n) a?
>     (All instance types must be of the form (T a1 ... an)
>     where a1 ... an are *distinct type variables*,
>     and each type variable appears at most once in the instance head.
>     Use FlexibleInstances if you want to disable this.)
>   In the instance declaration for ?FFT (RTree n) a?
>
> and was hoping someone could help me get it.
>
> Thanks!
> -db
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151110/ebc7d1db/attachment.html>

From olshanskydr at gmail.com  Tue Nov 10 20:59:01 2015
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Tue, 10 Nov 2015 23:59:01 +0300
Subject: [Haskell-cafe] types calculation
Message-ID: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>

Hello!

It seems that types without parameters are not reduced in ghc unlike CAFs.

I.e. if we have

type T1 a b = ...
type T2 = T1 Int Int

than T2 will be calculated on each utilization.

Is my statement correct? If so, why is it?
With complicated type-calculation compile time is growing too fast.

Best regards,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151110/c202de70/attachment.html>

From lambda.fairy at gmail.com  Wed Nov 11 06:33:11 2015
From: lambda.fairy at gmail.com (Chris Wong)
Date: Wed, 11 Nov 2015 19:33:11 +1300
Subject: [Haskell-cafe] Question, re: illegal instance error.
In-Reply-To: <495D63F3-8252-409E-AC77-5C9C380FCCE3@gmail.com>
References: <495D63F3-8252-409E-AC77-5C9C380FCCE3@gmail.com>
Message-ID: <CANQO64L+zDuhYCJjGozLJu6KdPijMJfdgY8ccGXA-i784idAmA@mail.gmail.com>

Hi David,

Andrey's answer is correct.

I asked a similar question on StackOverflow a few years back [1]. You
might find the resulting discussion useful.

Chris

[1] http://stackoverflow.com/q/8633470/617159

On Wed, Nov 11, 2015 at 5:15 AM, David Banas <capn.freako at gmail.com> wrote:
> Hi all,
>
> I don?t understand why this code:
>
> 50: instance (IsNat n, RealFloat a) => FFT (RTree n) a where
>
> is generating this error:
>
> fft_test.hs:50:36:
>     Illegal instance declaration for ?FFT (RTree n) a?
>       (All instance types must be of the form (T a1 ... an)
>        where a1 ... an are *distinct type variables*,
>        and each type variable appears at most once in the instance head.
>        Use FlexibleInstances if you want to disable this.)
>     In the instance declaration for ?FFT (RTree n) a?
>
> and was hoping someone could help me get it.
>
> Thanks!
> -db
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Wong (https://lambda.xyz)

"I had not the vaguest idea what this meant and when I could not
remember the words, my tutor threw the book at my head, which did not
stimulate my intellect in any way." -- Bertrand Russell

From rustompmody at gmail.com  Wed Nov 11 11:37:59 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Wed, 11 Nov 2015 17:07:59 +0530
Subject: [Haskell-cafe] Stack: Copying possible?
Message-ID: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>

Trying to switch over to stack

I copied over ~/.stack to another Linux box
And it gives me sanity check failed
Machines are same -- both 64 bit ubuntu wily -- user-names are different
and that shows in the error message.

I'd like to avoid almost a Gb of repeated downloads if possible.
But if thats not kosher that fine... Just asking :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/4616b3e0/attachment.html>

From rustompmody at gmail.com  Wed Nov 11 12:22:29 2015
From: rustompmody at gmail.com (rustompmody at gmail.com)
Date: Wed, 11 Nov 2015 12:22:29 +0000
Subject: [Haskell-cafe] Stack: Copying possible?
In-Reply-To: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>
References: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>
Message-ID: <s719073533656253149000@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/25769603/attachment.html>

From manny at fpcomplete.com  Wed Nov 11 13:36:02 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Wed, 11 Nov 2015 13:36:02 +0000
Subject: [Haskell-cafe] Stack: Copying possible?
In-Reply-To: <s719073533656253149000@gmail.com>
References: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>
 <s719073533656253149000@gmail.com>
Message-ID: <CACGj5v+s2D9BsSN4K3bd-uNu=ZAYL3oDf=V7E6OwY_wSQWy6mw@mail.gmail.com>

Compiled Haskell libraries and GHC installations are not generally
relocatable to a different path.  So in theory copying ~/.stack between
machines should work if your home directory is in the same place on the
filesystem (and the architecture matches), but won't work if your home
directory changes.

On Wed, Nov 11, 2015 at 4:27 AM <rustompmody at gmail.com> wrote:

> Another way of asking:
>
> $ stack setup
>
> should be representable as
>
> $ git clone ...
>
> $ other-stuff
>
>
>
> What is other-stuff?
>
>
>
> (Pls excuse top post -- from phone)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/c0ff713d/attachment.html>

From eir at cis.upenn.edu  Wed Nov 11 13:43:07 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 11 Nov 2015 08:43:07 -0500
Subject: [Haskell-cafe] types calculation
In-Reply-To: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>
References: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>
Message-ID: <58110E7E-C4A0-413B-9CDA-AE598B56A827@cis.upenn.edu>

Users often introduce so-called "vanilla" type synonyms (with `type` but not `type instance`) to be helpful abbreviations in code. As such, GHC actually takes quite a bit of effort *not* to expand these, so that error messages can report the synonyms instead of their expansions. On the other hand, type /families/ tend to be used for type-level computation. So GHC has decided to try to reduce all type families, while preserving all type synonyms. This is all a bit arbitrary, and it should have no end-user consequence except for error messages and, perhaps, performance.

If you have a complicated type-level program whose compile time is increasing faster than the program size, we'd love to know about it. We (GHC devs) want type-level computation to be efficient!

Thanks,
Richard

On Nov 10, 2015, at 3:59 PM, Dmitry Olshansky <olshanskydr at gmail.com> wrote:

> Hello!
> 
> It seems that types without parameters are not reduced in ghc unlike CAFs.
> 
> I.e. if we have
> 
> type T1 a b = ... 
> type T2 = T1 Int Int
> 
> than T2 will be calculated on each utilization.
> 
> Is my statement correct? If so, why is it?
> With complicated type-calculation compile time is growing too fast.
> 
> Best regards,
> Dmitry
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From rustompmody at gmail.com  Wed Nov 11 13:45:10 2015
From: rustompmody at gmail.com (Rustom Mody)
Date: Wed, 11 Nov 2015 19:15:10 +0530
Subject: [Haskell-cafe] Stack: Copying possible?
In-Reply-To: <CACGj5v+s2D9BsSN4K3bd-uNu=ZAYL3oDf=V7E6OwY_wSQWy6mw@mail.gmail.com>
References: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>
 <s719073533656253149000@gmail.com>
 <CACGj5v+s2D9BsSN4K3bd-uNu=ZAYL3oDf=V7E6OwY_wSQWy6mw@mail.gmail.com>
Message-ID: <CAJ+Teof8sAi6_eiwt7rQ8nN-s7pDUHx=gtwijLh2KtB1szgk=w@mail.gmail.com>

On Wed, Nov 11, 2015 at 7:06 PM, Emanuel Borsboom <manny at fpcomplete.com>
wrote:

> Compiled Haskell libraries and GHC installations are not generally
> relocatable to a different path.  So in theory copying ~/.stack between
> machines should work if your home directory is in the same place on the
> filesystem (and the architecture matches), but won't work if your home
> directory changes.
>
>
Just checked
Removed from ~/.stack/programs/x86_64-linux both
- ghc.7.10.2 (directory)
- ghc-7.10.2.installed

And reran
$ stack setup

The messages seemed to say something the the effect "already downloaded"
Spent some  time setting up...

And now
$ stack ghci
seems to be working.

Also now all references to the old username
on grepping in ~/.stack seem to have vanished


So is this ok or improper... ???
May the experts opine!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/2f189aab/attachment.html>

From manny at fpcomplete.com  Wed Nov 11 13:54:23 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Wed, 11 Nov 2015 13:54:23 +0000
Subject: [Haskell-cafe] Stack: Copying possible?
In-Reply-To: <CAJ+Teof8sAi6_eiwt7rQ8nN-s7pDUHx=gtwijLh2KtB1szgk=w@mail.gmail.com>
References: <CAJ+TeofWTa9gbd=V20c+GXvEvhZ5z9LvKWNv8wYrY9BVNVMo_Q@mail.gmail.com>
 <s719073533656253149000@gmail.com>
 <CACGj5v+s2D9BsSN4K3bd-uNu=ZAYL3oDf=V7E6OwY_wSQWy6mw@mail.gmail.com>
 <CAJ+Teof8sAi6_eiwt7rQ8nN-s7pDUHx=gtwijLh2KtB1szgk=w@mail.gmail.com>
Message-ID: <CACGj5vK+O9RCAcQ8m+w=z+0gdSP4q3ta+sTfeN4nSzZ8Wvb4Wg@mail.gmail.com>

So is this ok or improper? ???
May the experts opine!

Seems fine in theory. I wouldn?t be surprised if you run into trouble when
building with snapshot packages (those that don?t come with GHC), so if
that happens you?ll also have to rm -rf ~/.stack/snapshots.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/b5373fe6/attachment.html>

From olshanskydr at gmail.com  Wed Nov 11 15:43:12 2015
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Wed, 11 Nov 2015 18:43:12 +0300
Subject: [Haskell-cafe] types calculation
In-Reply-To: <58110E7E-C4A0-413B-9CDA-AE598B56A827@cis.upenn.edu>
References: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>
 <58110E7E-C4A0-413B-9CDA-AE598B56A827@cis.upenn.edu>
Message-ID: <CAHe9v2J2uAPbK-FMg3E71xLeZHnHerLTE55eg7KR_7XGKEd3RA@mail.gmail.com>

There are some questions / notes:

1. Could ghc use reduced "vanila types" for calculation with definition
stored somewhere specially for error messages?

2.  I didn't expect that type families can be without any parameters. But
they really can. So instead of
> type T2 = T1 Int Int
I can write
> type family T2 where T2 = T1 Int Int
which is rather strange though.
Moreover in this case ghc asks me for TypeFamilies and UndecidableInstances.
In my scenario such code should write library-user. So including these
(especially UndecidableInstances) extensions in his/her code is Undesirable.

3. For type families more natural to have parameters but in this case we
often can't reduce it deeply I suppose.
Short simple example:
type family L a b where
  L a () = (a,())
  L a (b,c) = (a,(b,c))
type T1 = L Int ()
type T2 = L Int T1
type T3 = L Int T2
type T3_Char = L Char T2
and so on...


Well, about my "complicated type-level program" now.  I start to play/work
with well-known "named-fields" problem. My code is here
<https://github.com/odr/pers>.
I hoped to find decision with properties:
- O(log n) time to get field from record by name
- record construction independent from order of fields definitions
- no TH preferrable, some TH possible
- projections and joins are desirable

I tried to implement it using "very-well balanced tree" (I don't know the
right name) on type level.
This is a binary search (by name) tree with count of left items is the same
or one more than on the right side (for each subtree).
The problem is construction. I realized it with FunDeps
<https://github.com/odr/pers/blob/master/src/NamedBTree.hs> and  with TF
<https://github.com/odr/pers/blob/master/src/NamedBTree2.hs>. User should
write
> type Rec = () <+ "a":>Int <+ "b":>Char <+ "c":>String
> rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' ::
"b":>Char)
or
> rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' ::
"b":>Char) :: Rec
and got
rec = (((),V 1,()),V'b',((),V "c")) ::
(((),"a":>Int,()),"b":>Char,((),"c":>String,())

(Constructions like (V 1 :: "a" :> Int) rather ugly. Any ideas are
welcomed... Perhaps some TH?)

But compile time for user application
<https://github.com/odr/pers/blob/master/app/Main.hs> is absolutely blocked
this idea!

I tried also to make a type-level sorted list
<https://github.com/odr/pers/blob/master/src/List.hs> but it is also too
complicated for ghc.

I didn't check time with no-parameters-TF as you suggested. I will.

Best regards,
Dmitry






2015-11-11 16:43 GMT+03:00 Richard Eisenberg <eir at cis.upenn.edu>:

> Users often introduce so-called "vanilla" type synonyms (with `type` but
> not `type instance`) to be helpful abbreviations in code. As such, GHC
> actually takes quite a bit of effort *not* to expand these, so that error
> messages can report the synonyms instead of their expansions. On the other
> hand, type /families/ tend to be used for type-level computation. So GHC
> has decided to try to reduce all type families, while preserving all type
> synonyms. This is all a bit arbitrary, and it should have no end-user
> consequence except for error messages and, perhaps, performance.
>
> If you have a complicated type-level program whose compile time is
> increasing faster than the program size, we'd love to know about it. We
> (GHC devs) want type-level computation to be efficient!
>
> Thanks,
> Richard
>
> On Nov 10, 2015, at 3:59 PM, Dmitry Olshansky <olshanskydr at gmail.com>
> wrote:
>
> > Hello!
> >
> > It seems that types without parameters are not reduced in ghc unlike
> CAFs.
> >
> > I.e. if we have
> >
> > type T1 a b = ...
> > type T2 = T1 Int Int
> >
> > than T2 will be calculated on each utilization.
> >
> > Is my statement correct? If so, why is it?
> > With complicated type-calculation compile time is growing too fast.
> >
> > Best regards,
> > Dmitry
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/67bedddb/attachment.html>

From eir at cis.upenn.edu  Wed Nov 11 16:03:10 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 11 Nov 2015 11:03:10 -0500
Subject: [Haskell-cafe] types calculation
In-Reply-To: <CAHe9v2J2uAPbK-FMg3E71xLeZHnHerLTE55eg7KR_7XGKEd3RA@mail.gmail.com>
References: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>
 <58110E7E-C4A0-413B-9CDA-AE598B56A827@cis.upenn.edu>
 <CAHe9v2J2uAPbK-FMg3E71xLeZHnHerLTE55eg7KR_7XGKEd3RA@mail.gmail.com>
Message-ID: <F24B7937-9E63-475C-8D41-F546E027D5F2@cis.upenn.edu>

On Nov 11, 2015, at 10:43 AM, Dmitry Olshansky <olshanskydr at gmail.com> wrote:

> There are some questions / notes:
> 
> 1. Could ghc use reduced "vanila types" for calculation with definition stored somewhere specially for error messages?

Perhaps. But I'm not yet convinced that the current treatment of type synonyms is causing your slowdown.

> 
> 2.  I didn't expect that type families can be without any parameters. But they really can. So instead of
> > type T2 = T1 Int Int
> I can write 
> > type family T2 where T2 = T1 Int Int
> which is rather strange though.
> Moreover in this case ghc asks me for TypeFamilies and UndecidableInstances.
> In my scenario such code should write library-user. So including these (especially UndecidableInstances) extensions in his/her code is Undesirable.

If your clients will have to include fancy type-level definitions, they will probably need UndecidableInstances. We're open to improving the termination checker if you have a good approach to how. :)

> 
> 3. For type families more natural to have parameters but in this case we often can't reduce it deeply I suppose.
> Short simple example:
> type family L a b where 
>   L a () = (a,())
>   L a (b,c) = (a,(b,c))
> type T1 = L Int ()
> type T2 = L Int T1
> type T3 = L Int T2
> type T3_Char = L Char T2
> and so on...

I'm not sure what you're getting at here. Type synonyms and type families should behave the same (other than in error messages). Do you have an example where the compile time with type synonyms is demonstrably slower than the time with type families?

> 
> 
> Well, about my "complicated type-level program" now.  I start to play/work with well-known "named-fields" problem. My code is here.

Thanks for sharing your code. But it's very hard to understand what to look at here. I see in your "user application" link below that you have times. Are these compile times? Under what tests? Which version of GHC? We need to be really concrete so that I (or some other GHC dev) can reproduce what you're experiencing.

Thanks!
Richard

> I hoped to find decision with properties:
> - O(log n) time to get field from record by name
> - record construction independent from order of fields definitions
> - no TH preferrable, some TH possible
> - projections and joins are desirable
> 
> I tried to implement it using "very-well balanced tree" (I don't know the right name) on type level. 
> This is a binary search (by name) tree with count of left items is the same or one more than on the right side (for each subtree).
> The problem is construction. I realized it with FunDeps and  with TF. User should write 
> > type Rec = () <+ "a":>Int <+ "b":>Char <+ "c":>String
> > rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' :: "b":>Char)
> or
> > rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' :: "b":>Char) :: Rec
> and got 
> rec = (((),V 1,()),V'b',((),V "c")) :: (((),"a":>Int,()),"b":>Char,((),"c":>String,()) 
> 
> (Constructions like (V 1 :: "a" :> Int) rather ugly. Any ideas are welcomed... Perhaps some TH?)
> 
> But compile time for user application is absolutely blocked this idea!
> 
> I tried also to make a type-level sorted list but it is also too complicated for ghc.
> 
> I didn't check time with no-parameters-TF as you suggested. I will.
> 
> Best regards,
> Dmitry
> 
> 
> 
> 
> 
> 
> 2015-11-11 16:43 GMT+03:00 Richard Eisenberg <eir at cis.upenn.edu>:
> Users often introduce so-called "vanilla" type synonyms (with `type` but not `type instance`) to be helpful abbreviations in code. As such, GHC actually takes quite a bit of effort *not* to expand these, so that error messages can report the synonyms instead of their expansions. On the other hand, type /families/ tend to be used for type-level computation. So GHC has decided to try to reduce all type families, while preserving all type synonyms. This is all a bit arbitrary, and it should have no end-user consequence except for error messages and, perhaps, performance.
> 
> If you have a complicated type-level program whose compile time is increasing faster than the program size, we'd love to know about it. We (GHC devs) want type-level computation to be efficient!
> 
> Thanks,
> Richard
> 
> On Nov 10, 2015, at 3:59 PM, Dmitry Olshansky <olshanskydr at gmail.com> wrote:
> 
> > Hello!
> >
> > It seems that types without parameters are not reduced in ghc unlike CAFs.
> >
> > I.e. if we have
> >
> > type T1 a b = ...
> > type T2 = T1 Int Int
> >
> > than T2 will be calculated on each utilization.
> >
> > Is my statement correct? If so, why is it?
> > With complicated type-calculation compile time is growing too fast.
> >
> > Best regards,
> > Dmitry
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/26109ff9/attachment.html>

From olshanskydr at gmail.com  Wed Nov 11 17:03:50 2015
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Wed, 11 Nov 2015 20:03:50 +0300
Subject: [Haskell-cafe] types calculation
In-Reply-To: <F24B7937-9E63-475C-8D41-F546E027D5F2@cis.upenn.edu>
References: <CAHe9v2+6e8tAhjk=bQKA-yFEarHNxNNFF0dtgU7j2Q2S=HRRbw@mail.gmail.com>
 <58110E7E-C4A0-413B-9CDA-AE598B56A827@cis.upenn.edu>
 <CAHe9v2J2uAPbK-FMg3E71xLeZHnHerLTE55eg7KR_7XGKEd3RA@mail.gmail.com>
 <F24B7937-9E63-475C-8D41-F546E027D5F2@cis.upenn.edu>
Message-ID: <CAHe9v2+06y2RdNeBvSOR3m3UxJO3M6t7KwNRbZcZyY0bnNqgAA@mail.gmail.com>

>> If your clients will have to include fancy type-level definitions, they
will probably need UndecidableInstances. We're open to improving the
termination checker if you have a good approach to how. :)

When client wrote
> type T = T1 Int Int
we hadn't UI. But when he/she wrote
> type family T where T = T1 Int Int
we had.

I can imagine now that it means we try to reduce Undecidable TF here. But
from client point it looks rather strange.

About technical details I answered personnaly.

Thanks,
Dmitry




2015-11-11 19:03 GMT+03:00 Richard Eisenberg <eir at cis.upenn.edu>:

> On Nov 11, 2015, at 10:43 AM, Dmitry Olshansky <olshanskydr at gmail.com>
> wrote:
>
> There are some questions / notes:
>
> 1. Could ghc use reduced "vanila types" for calculation with definition
> stored somewhere specially for error messages?
>
>
> Perhaps. But I'm not yet convinced that the current treatment of type
> synonyms is causing your slowdown.
>
>
> 2.  I didn't expect that type families can be without any parameters. But
> they really can. So instead of
> > type T2 = T1 Int Int
> I can write
> > type family T2 where T2 = T1 Int Int
> which is rather strange though.
> Moreover in this case ghc asks me for TypeFamilies and
> UndecidableInstances.
> In my scenario such code should write library-user. So including these
> (especially UndecidableInstances) extensions in his/her code is
> Undesirable.
>
>
> If your clients will have to include fancy type-level definitions, they
> will probably need UndecidableInstances. We're open to improving the
> termination checker if you have a good approach to how. :)
>
>
> 3. For type families more natural to have parameters but in this case we
> often can't reduce it deeply I suppose.
> Short simple example:
> type family L a b where
>   L a () = (a,())
>   L a (b,c) = (a,(b,c))
> type T1 = L Int ()
> type T2 = L Int T1
> type T3 = L Int T2
> type T3_Char = L Char T2
> and so on...
>
>
> I'm not sure what you're getting at here. Type synonyms and type families
> should behave the same (other than in error messages). Do you have an
> example where the compile time with type synonyms is demonstrably slower
> than the time with type families?
>
>
>
> Well, about my "complicated type-level program" now.  I start to play/work
> with well-known "named-fields" problem. My code is here
> <https://github.com/odr/pers>.
>
>
> Thanks for sharing your code. But it's very hard to understand what to
> look at here. I see in your "user application" link below that you have
> times. Are these compile times? Under what tests? Which version of GHC? We
> need to be really concrete so that I (or some other GHC dev) can reproduce
> what you're experiencing.
>
> Thanks!
> Richard
>
> I hoped to find decision with properties:
> - O(log n) time to get field from record by name
> - record construction independent from order of fields definitions
> - no TH preferrable, some TH possible
> - projections and joins are desirable
>
> I tried to implement it using "very-well balanced tree" (I don't know the
> right name) on type level.
> This is a binary search (by name) tree with count of left items is the
> same or one more than on the right side (for each subtree).
> The problem is construction. I realized it with FunDeps
> <https://github.com/odr/pers/blob/master/src/NamedBTree.hs> and  with TF
> <https://github.com/odr/pers/blob/master/src/NamedBTree2.hs>. User should
> write
> > type Rec = () <+ "a":>Int <+ "b":>Char <+ "c":>String
> > rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' ::
> "b":>Char)
> or
> > rec = () <+ (V "c" :: "c":>String) <+ (V 1 :: "a":>Int) <+ (V 'b' ::
> "b":>Char) :: Rec
> and got
> rec = (((),V 1,()),V'b',((),V "c")) ::
> (((),"a":>Int,()),"b":>Char,((),"c":>String,())
>
> (Constructions like (V 1 :: "a" :> Int) rather ugly. Any ideas are
> welcomed... Perhaps some TH?)
>
> But compile time for user application
> <https://github.com/odr/pers/blob/master/app/Main.hs> is absolutely
> blocked this idea!
>
> I tried also to make a type-level sorted list
> <https://github.com/odr/pers/blob/master/src/List.hs> but it is also too
> complicated for ghc.
>
> I didn't check time with no-parameters-TF as you suggested. I will.
>
> Best regards,
> Dmitry
>
>
>
>
>
>
> 2015-11-11 16:43 GMT+03:00 Richard Eisenberg <eir at cis.upenn.edu>:
>
>> Users often introduce so-called "vanilla" type synonyms (with `type` but
>> not `type instance`) to be helpful abbreviations in code. As such, GHC
>> actually takes quite a bit of effort *not* to expand these, so that error
>> messages can report the synonyms instead of their expansions. On the other
>> hand, type /families/ tend to be used for type-level computation. So GHC
>> has decided to try to reduce all type families, while preserving all type
>> synonyms. This is all a bit arbitrary, and it should have no end-user
>> consequence except for error messages and, perhaps, performance.
>>
>> If you have a complicated type-level program whose compile time is
>> increasing faster than the program size, we'd love to know about it. We
>> (GHC devs) want type-level computation to be efficient!
>>
>> Thanks,
>> Richard
>>
>> On Nov 10, 2015, at 3:59 PM, Dmitry Olshansky <olshanskydr at gmail.com>
>> wrote:
>>
>> > Hello!
>> >
>> > It seems that types without parameters are not reduced in ghc unlike
>> CAFs.
>> >
>> > I.e. if we have
>> >
>> > type T1 a b = ...
>> > type T2 = T1 Int Int
>> >
>> > than T2 will be calculated on each utilization.
>> >
>> > Is my statement correct? If so, why is it?
>> > With complicated type-calculation compile time is growing too fast.
>> >
>> > Best regards,
>> > Dmitry
>> >
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/f31b4952/attachment.html>

From kocic.miroslav at mail.com  Thu Nov 12 03:34:52 2015
From: kocic.miroslav at mail.com (Miroslav Kocic)
Date: Thu, 12 Nov 2015 04:34:52 +0100
Subject: [Haskell-cafe] checking whether the list is active
Message-ID: <trinity-011c039b-0714-40b1-bf6f-45446a770299-1447299292681@3capp-mailcom-lxa14>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/e2423f48/attachment.html>

From greg at gregorycollins.net  Thu Nov 12 04:48:25 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Wed, 11 Nov 2015 20:48:25 -0800
Subject: [Haskell-cafe] checking whether the list is active
In-Reply-To: <trinity-011c039b-0714-40b1-bf6f-45446a770299-1447299292681@3capp-mailcom-lxa14>
References: <trinity-011c039b-0714-40b1-bf6f-45446a770299-1447299292681@3capp-mailcom-lxa14>
Message-ID: <CAHZrzdq0UA4VN_CKnSu=LM-PL7Cu6M=Kmv=WSZmcCxLO60f+3A@mail.gmail.com>

Yes

On Wed, Nov 11, 2015 at 7:34 PM, Miroslav Kocic <kocic.miroslav at mail.com>
wrote:

> I'm just checking whether this list is still active. If activity has
> migrated elsewhere, please tell me where.
>
> Miroslav
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151111/25fffb7f/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Thu Nov 12 14:25:16 2015
From: mantkiew at gsd.uwaterloo.ca (=?UTF-8?Q?Micha=C5=82_Antkiewicz?=)
Date: Thu, 12 Nov 2015 09:25:16 -0500
Subject: [Haskell-cafe] checking whether the list is active
In-Reply-To: <trinity-011c039b-0714-40b1-bf6f-45446a770299-1447299292681@3capp-mailcom-lxa14>
References: <trinity-011c039b-0714-40b1-bf6f-45446a770299-1447299292681@3capp-mailcom-lxa14>
Message-ID: <CAGW9QSxAiY1fmOcJ0wtXABnEKfoWwL+E0JHioFie1G+x3BH5oA@mail.gmail.com>

See the archives

https://mail.haskell.org/pipermail/haskell-cafe/

Micha?

On Wed, Nov 11, 2015 at 10:34 PM, Miroslav Kocic
<kocic.miroslav at mail.com> wrote:
> I'm just checking whether this list is still active. If activity has
> migrated elsewhere, please tell me where.
>
> Miroslav
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

From matthewtpickering at gmail.com  Thu Nov 12 17:37:19 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 12 Nov 2015 17:37:19 +0000
Subject: [Haskell-cafe] haskell-src-exts maintenance
In-Reply-To: <284CD5F5-C667-4AF4-9CDE-F5F37556CE69@gmail.com>
References: <CALuQ0m_D=zj=1fFfW4ADKTTGwhXBPuQp33x9-cGcc+ma65tu1A@mail.gmail.com>
 <20150701065452.GA29000@cucumber.anchor.net.au>
 <CAKKZoUVmNf2p8TUo65RxY0uSmMFXd2z2SpqMCwo8=ZQa--phMQ@mail.gmail.com>
 <CANma=H_8fym0+Kv+PEX4_FuV-y8PN-WD8_24u6karhezP_zzzQ@mail.gmail.com>
 <20150701083154.GB2283@cucumber.anchor.net.au>
 <CALuQ0m_KsqaOU_0OC0zcT1KqSr7Z80CMMk+z8AMGQBRML4uL3g@mail.gmail.com>
 <CAKcFpmL6e=XP5b1Go89+wytxjpoYiCLwTOOQYkv+hv+HVD+tQQ@mail.gmail.com>
 <284CD5F5-C667-4AF4-9CDE-F5F37556CE69@gmail.com>
Message-ID: <CALuQ0m_po=k6CNB7RRWxZxJpEfEBQCdkfSaBpBfdL9BnqAq8sg@mail.gmail.com>

Peter,

Please can you do the release. I completed the work updating HSE
several months ago, a much better version of HSE has been waiting on
the master branch since then. I thank you for providing helpful review
for the patches I submitted but since then I have sent three emails
asking about the release. After the second you promised to do a
release at the end of October but that never happened.

It is a shame that the user's of HSE have had to live with many long
standing bugs when they have been fixed for months.

If you can not do it for whatever reason then please can you add me as
a maintainer on hackage and the github repo so that users can get an
updated version of HSE.

Best wishes,

Matt



On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson
<jonsson.peter.a at gmail.com> wrote:
> I?m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole.
>
> I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn?t follow up on that so there was probably some miscommunication between the two of us.
>
> I?ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don?t want to rush things out through the door at any cost though?I believe HSE?s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released.
>
> Best Wishes,
>
> Peter
>
>> On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell at gmail.com> wrote:
>>
>> As a very heavy HSE user (HLint and Hoogle), who has had a reasonably
>> close working relationship with all of Niklas (my SoC mentor and my
>> SoC mentee), Roman and Peter (a fellow supercompiler developer) and
>> Matt (currently hacking on HLint), I thought I should weigh in.
>>
>> The current state of HSE is a little forlorn - there are 22 open pull
>> requests, everything from reducing algorithm complexity (an accidental
>> n^3), fixing the default encoding (should be UTF8) and lots of actual
>> parser fixes. A lot of this is good stuff, and the high level of
>> external contributions is a really good sign. But they need to be
>> merged and reviewed, and it seems the bandwidth just isn't there at
>> the moment. Given Matt's comments on the existing tickets, and the
>> triage he's already performing on the repo, I have high hopes that
>> Matt could provide a bit more of the time and attention. Peter,
>> perhaps a co-maintainer would be good for a little while?
>>
>>> If it's not soon then please could you add myself and Christian to the
>>> maintainers so that we can perform some short term maintenance.  My
>>> immediate plan of action would be
>>>
>>> 1. Immediately cut a 1.17 release from the master branch as it
>>> contains much better parsing of lifted constructors which are becoming
>>> more prevalent.
>>> 2. Review and merge recent pull requests.
>>> 3. Update the parser as far as possible with missing features.
>>> 4. Release 1.18 with these improvements within 1 month.
>>
>> Awesome! Although as a preference I'd go for as much of 2 as you can
>> in a couple of days before doing 1 - a lot of the patches are simple
>> and valuable, and a 2 day wait isn't going to be too problematic.
>>
>> Thanks, Neil
>

From agocorona at gmail.com  Thu Nov 12 17:49:47 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 12 Nov 2015 18:49:47 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
Message-ID: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>

Looking at this:

https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html

It seems that it is impossible to manage data in Haskell within a core
without L1 cache faults. Except for unboxed arrays of primitive types.

Since it is impossible to have unboxed arrays of user-defined types.

Am I right?

This is definitively very bad for tasks that are inherently single threaded
and in general for the image of Haskell as a practical language.

I have more to say about that, but I would like to know first if I?m right
and second If there is some idea to going on to permit user defined boxed
datatypes.  Or if there is some low level trick for having it using foreign
call and unsafeCoerce in some way,

I know that the language ATS has unboxing a la carte....

-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/69dcbdb2/attachment.html>

From kane at kane.cx  Thu Nov 12 17:56:26 2015
From: kane at kane.cx (David Kraeutmann)
Date: Thu, 12 Nov 2015 18:56:26 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
Message-ID: <5644D2CA.7000102@kane.cx>

This might be of interest to you:
https://hackage.haskell.org/package/structs


On 11/12/2015 6:49 PM, Alberto G. Corona wrote:
> Looking at this:
>
> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>
> It seems that it is impossible to manage data in Haskell within a core
> without L1 cache faults. Except for unboxed arrays of primitive types.
>
> Since it is impossible to have unboxed arrays of user-defined types.
>
> Am I right?
>
> This is definitively very bad for tasks that are inherently single threaded
> and in general for the image of Haskell as a practical language.
>
> I have more to say about that, but I would like to know first if I?m right
> and second If there is some idea to going on to permit user defined boxed
> datatypes.  Or if there is some low level trick for having it using foreign
> call and unsafeCoerce in some way,
>
> I know that the language ATS has unboxing a la carte....
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/02d7edc5/attachment.bin>

From will.yager at gmail.com  Thu Nov 12 19:38:00 2015
From: will.yager at gmail.com (William Yager)
Date: Thu, 12 Nov 2015 13:38:00 -0600
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
Message-ID: <CAG8oi1NmaePMxr70vxXAh62_Lyho4KTcb0H-RMH54CGwRrR5DA@mail.gmail.com>

Also see
https://hackage.haskell.org/package/vector-0.11.0.0/docs/Data-Vector-Storable.html

On Thu, Nov 12, 2015 at 11:49 AM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> Looking at this:
>
>
> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>
> It seems that it is impossible to manage data in Haskell within a core
> without L1 cache faults. Except for unboxed arrays of primitive types.
>
> Since it is impossible to have unboxed arrays of user-defined types.
>
> Am I right?
>
> This is definitively very bad for tasks that are inherently single
> threaded and in general for the image of Haskell as a practical language.
>
> I have more to say about that, but I would like to know first if I?m right
> and second If there is some idea to going on to permit user defined boxed
> datatypes.  Or if there is some low level trick for having it using foreign
> call and unsafeCoerce in some way,
>
> I know that the language ATS has unboxing a la carte....
>
> --
> Alberto.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/6422a197/attachment.html>

From agocorona at gmail.com  Thu Nov 12 22:52:44 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 12 Nov 2015 23:52:44 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAG8oi1NmaePMxr70vxXAh62_Lyho4KTcb0H-RMH54CGwRrR5DA@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <CAG8oi1NmaePMxr70vxXAh62_Lyho4KTcb0H-RMH54CGwRrR5DA@mail.gmail.com>
Message-ID: <CAArEJmYoBT0XAC+3Gnq=f+U1-Vk4VDpEOGjy-ZZcUsJ6i++m2Q@mail.gmail.com>

A buildt-in derivation of the Storable instance would be the solution for
the problem. Perhaps a meaningful summer of code project?

2015-11-12 20:38 GMT+01:00 William Yager <will.yager at gmail.com>:

> Also see
> https://hackage.haskell.org/package/vector-0.11.0.0/docs/Data-Vector-Storable.html
>
> On Thu, Nov 12, 2015 at 11:49 AM, Alberto G. Corona <agocorona at gmail.com>
> wrote:
>
>> Looking at this:
>>
>>
>> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>>
>> It seems that it is impossible to manage data in Haskell within a core
>> without L1 cache faults. Except for unboxed arrays of primitive types.
>>
>> Since it is impossible to have unboxed arrays of user-defined types.
>>
>> Am I right?
>>
>> This is definitively very bad for tasks that are inherently single
>> threaded and in general for the image of Haskell as a practical language.
>>
>> I have more to say about that, but I would like to know first if I?m
>> right and second If there is some idea to going on to permit user defined
>> boxed datatypes.  Or if there is some low level trick for having it using
>> foreign call and unsafeCoerce in some way,
>>
>> I know that the language ATS has unboxing a la carte....
>>
>> --
>> Alberto.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/5ad89d9f/attachment.html>

From agocorona at gmail.com  Thu Nov 12 22:53:50 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 12 Nov 2015 23:53:50 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <5644D2CA.7000102@kane.cx>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
Message-ID: <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>

There are no examples. It is hard to guess the functionality and the
maturity of he approach.

2015-11-12 18:56 GMT+01:00 David Kraeutmann <kane at kane.cx>:

> This might be of interest to you:
> https://hackage.haskell.org/package/structs
>
>
> On 11/12/2015 6:49 PM, Alberto G. Corona wrote:
> > Looking at this:
> >
> >
> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
> >
> > It seems that it is impossible to manage data in Haskell within a core
> > without L1 cache faults. Except for unboxed arrays of primitive types.
> >
> > Since it is impossible to have unboxed arrays of user-defined types.
> >
> > Am I right?
> >
> > This is definitively very bad for tasks that are inherently single
> threaded
> > and in general for the image of Haskell as a practical language.
> >
> > I have more to say about that, but I would like to know first if I?m
> right
> > and second If there is some idea to going on to permit user defined boxed
> > datatypes.  Or if there is some low level trick for having it using
> foreign
> > call and unsafeCoerce in some way,
> >
> > I know that the language ATS has unboxing a la carte....
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/7e245e0a/attachment.html>

From michael at snoyman.com  Thu Nov 12 22:56:03 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 12 Nov 2015 14:56:03 -0800
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
Message-ID: <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>

How about vector-th-unbox[1]?

[1] https://www.stackage.org/package/vector-th-unbox

On Thu, Nov 12, 2015 at 2:53 PM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> There are no examples. It is hard to guess the functionality and the
> maturity of he approach.
>
> 2015-11-12 18:56 GMT+01:00 David Kraeutmann <kane at kane.cx>:
>
>> This might be of interest to you:
>> https://hackage.haskell.org/package/structs
>>
>>
>> On 11/12/2015 6:49 PM, Alberto G. Corona wrote:
>> > Looking at this:
>> >
>> >
>> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>> >
>> > It seems that it is impossible to manage data in Haskell within a core
>> > without L1 cache faults. Except for unboxed arrays of primitive types.
>> >
>> > Since it is impossible to have unboxed arrays of user-defined types.
>> >
>> > Am I right?
>> >
>> > This is definitively very bad for tasks that are inherently single
>> threaded
>> > and in general for the image of Haskell as a practical language.
>> >
>> > I have more to say about that, but I would like to know first if I?m
>> right
>> > and second If there is some idea to going on to permit user defined
>> boxed
>> > datatypes.  Or if there is some low level trick for having it using
>> foreign
>> > call and unsafeCoerce in some way,
>> >
>> > I know that the language ATS has unboxing a la carte....
>> >
>> >
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> >
>>
>>
>>
>
>
> --
> Alberto.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/b8a61e2a/attachment.html>

From gershomb at gmail.com  Fri Nov 13 04:47:03 2015
From: gershomb at gmail.com (Gershom B)
Date: Thu, 12 Nov 2015 23:47:03 -0500
Subject: [Haskell-cafe] Haskell Platform Plans
Message-ID: <CAM8RHpGtRNg100f-xzBsqPUjwcFvLseDwWZCnAc4HdwFE7Q1yg@mail.gmail.com>

Dear all,

As you know, Mark has passed on the Haskell Platform maintainer hat to me.

I wanted to give a heads-up on current plans to keep folks in the loop.
This message has three sections, first the 7.10.3 release, next the 8.0
release, and finally some general musings on fiddly details and future
plans.

1) 7.10.3

The 7.10.3 release candidates have been out for windows and unix for a bit.
As I understand it there is still work underway on the mac build, but that
will hopefully be coming shortly. The plan is to release a new platform
roughly simultaneously. This platform will work essentially as in the past,
for two reasons. First, because it is the last release in the 7.10 series
and should be seen like the 7.10.3 compiler as just incorporating some
necessary patches rather than any serious changes. Furthermore, the future
plans underway rely on a few patches to cabal which have been merged, but
are not yet in any existing cabal-install release. A few packages have
received minor version bumps, as follows:

PACKAGE           7.10.2-a   latest
-------------------------------------------
case-insensitive  1.2.0.4   1.2.0.5
fgl               5.5.2.0   5.5.2.3
GLUT              2.7.0.1   2.7.0.3
GLURaw            1.5.0.1   1.5.0.2
HUnit             1.2.5.2   1.3.0.0
OpenGL            2.12.0.1  2.13.1.0
OpenGLRaw         2.5.1.0   2.6.0.0
primitive         0.6       0.6.1.0
syb               0.5.1     0.6
scientific        0.3.3.8   0.3.4.2
StateVar          1.1.0.0   1.1.0.1

A few packages were held back due to dependency issues (notably zlib) and
additionally, packages shipped with ghc were held back to the versions that
will be shipped with 7.10.3.

2) 8.0

We also plan to ship a new platform concurrently with the ghc 8.0 that
should be released early next year.

That platform will implement some long-discussed and requested changes.
First, the platform already ships with msys on windows. However, it does
not do so in a way that lets you, as with minGHC, install the network
library directly, or for that matter install directly other libraries that
use build-type configure. This is because the msys binaries don't get
placed into the path, by design. The new platform will ship with a newer
cabal, incorporating a patch (pull request #2480) that uses the
extra-prog-path setting for build-type: configure. This should allow
network and other things reliant on build-type: configure to directly cabal
install. The goal for the platform on windows will be that any packages
binding to msys libraries _should_ be cabal installable without hassle. If
you maintain a library that you think would be a good test-case for this,
please drop a line so we can work together towards this goal.

Second, the default platform will be _minimal_. That is to say that it will
_only_ install into the global package database those packages that are
directly shipped with ghc, and not any additional platform packages.

"Blessed" platform packages will however still be shipped as a "default
user cabal.config" file, so in a setting where users want to work
unsandboxed, their versions of platform libs will remain pegged to those
chosen by the platform, should they not choose to alter their settings. In
a sandboxed setting, or in the presence of a local cabal.config generated
by a freeze, those constraints will be disregarded.

Furthermore, it is likely but not certain that the "nix-like cabal" or
"no-reinstall cabal" will be available for the 8.0 release. If this is the
case, users will be able to operate in an unsandboxed environment without
conflicts, as multiple instances of the same version of a package, with
different dependency choices, will be able to live side-by-side.

Third, the platform will ship not only with cabal-install, but also with
the stack tool, so that users can choose either workflow, depending on
their project or preferences. A number of people have adopted the stack
tool, and many beginners have reported success with it as well, so it will
be good to provide that functionality out of the box with every platform
install.

Time and resources permitting we would also like to ship a platform version
_with_ the platform libraries prebuilt and included, as that is also a use
case that some people continue to like. However, this is a secondary
priority, and contingent on us getting our build infrastructure into a good
enough shape to make this not too much extra hassle.

I'm excited about these changes, and confident we can get their in a
timespan that matches the 8.0 release of ghc.

3) Generalities

As I mentioned, it would be good to have a more uniform build
infrastructure. Generally, I have put out some feelers and am working
towards extending the ghc nightly buildbot infrastructure to both cover
more platforms and also cover more tools -- not only ghc, but cabal, the
platform, perhaps haddock, ghcjs, etc. This way we can get an economy of
scale and many of our core tools will be able to all share regular
automated builds across many platforms. If you like CI/buildbot systems and
would like to help out with this project, please reach out.

Also, once we've modernized and fixed up the core platform installer tech,
it would be nice to move back to the process of making the platform a good
set of blessed libraries -- taking more proposals for additions to it,
looking to cull libraries that are no longer widely used, etc. As part of
this I intend to move the haskell-platform list off our deprecated
community.haskell.org infrastructure and onto mail.haskell.org with our
other active lists.

Finally, I'm happy to be maintainer of the platform through this period of
change and transition, but at some future point, as things get sorted out
and the release process becomes more standard and mechanical, I would very
much like to pass this responsibility on. I have had some nibbles of
offers, but if other people want to begin to get involved, please let me
know and we can start to get small contributions from you so that you can
become familiar with the various tech and systems involved.

The Haskell ecosystem is a team effort, a collective project, and volunteer
driven. In my modest experience hacking on the various systems involved
(cabal, cabal-install, hackage, the platform build, etc.) some are a bit
confusing, but I have always found helpful contributors willing to explain
things and review patches, and to help think about and diagnose problems.
And none of the code has been as confusing as things I've had to wade
through for employment-related purposes :-). So when this stuff doesn't
work as well as we'd like, we can investigate together, and then put our
heads together and figure out how to improve it together. Furthermore, it
can be very satisfying to do so, because the impact of those improvements
makes itself widely felt. I look forward to more people joining in!

Best,
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151112/b7c01cc0/attachment.html>

From dct25-561bs at mythic-beasts.com  Fri Nov 13 11:11:16 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Fri, 13 Nov 2015 11:11:16 +0000
Subject: [Haskell-cafe] Where did these threads come from?
Message-ID: <CAErCyQ_FzDf6czzp7t3kbFwPdQ_9tP9MsRJUGFKtDFm15t8Odw@mail.gmail.com>

Hi all,

I'm working on a server process that has (by design) fairly high memory
usage but serves relatively few requests and spends most of its time idle.
By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to
improve its quiescent CPU usage as this is currently the limiting factor
for how cheaply we can run this service - we're aiming for the cheapest
t-class EC2 machine we can get.

The quiescent CPU usage is currently about 50%. This seems to be largely
due to the idle GC, because running with -I0 cuts it down to about 0.3%.
Pretty much every time any thread wakes up it triggers the idle GC a short
while later and because of the high memory usage these GCs are somewhat
expensive.

Using threadscope I found the biggest problem was the reaper thread in
resource-pool which wakes up every second whether there's anything to reap
or not. Fortunately this was easy to spot as the reaper thread labels
itself as such. I've replaced this with an event-driven reaper that only
wakes up on demand and cut the baseline from 50% down to just under 10%.

There are two more threads I can now see waking up periodically in
threadscope, with respective periods approximately 10 sec and 30 sec. I
have a hunch what the 30-sec one is but no idea about the 10-sec one. If I
can kill off the 10 sec one then that should take CPU usage down to <5%
which would be just fine.

My question: is there any reliable way to determine where these threads
came from, in terms of the location of the forkIO call that made them? I've
just been looking for likely candidates and labelling threads and this is
rather tedious.

Cheers,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/ac31d0d8/attachment.html>

From agocorona at gmail.com  Fri Nov 13 11:42:27 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Fri, 13 Nov 2015 12:42:27 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
Message-ID: <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>

That is more practical.

It is a pity that the Unboxed class does not interact with the UNPACK
pragma. Or it seems so.

The problem that round my head after being exposed to the Google phylosophy
of "count the bytes" is the trade off when choosing containers: Either
boxed, pure, linked multithreaded or  unboxed mutable single threaded.

Haskell philosophy choose the first, while almost all the mainstream
languages choose the second. That is another problem for the adoption of
haskell.  Google people say: we don?t need multithreaded programs because
we run many single threaded programs in one machine, we use all the cores.
Only when there is a single application to run the justification for the
extra effort of multithreading is justified. And this happens rarely in the
real world: In scientific, engineering, financial it is usual. It also
happens in distributed settings but in that last case, performance per
thread and core is also critical, so Haskell is ruled out.

But that hasn?t to be that way, or at least that is what I think.
DiffUArrays are internally mutable but with a pure interface.  They use a
kind of versioning. in single threaded environments it theoretically
perform at mutable speeds.  the versioning of diffArray is the blend of
packed and linked structure that can mix the two worlds.

If the unboxing is extended to any kind of user defined data, the
versioning idea can be used to have containers that perform at C speeds
when single threaded, but preserve the purity when multithreaded.  So it is
possible to have the cake and eat it too.

it is even possible to codify balanced binary trees in a compact diffarray,
so very fast maps can be used in single threaded applications that also are
pure and work multithreaded.

The goal is to remove the objections about haskell coming from that side of
the computer industry by having such containers available without forcing
the user to know lots of things about the internals of haskell and GHC.

I do not know if there are thing going on in some of this direction. Maybe
I?m being simplistic and there is something that I miss .

By experience I know that what sell more from a language is not the real
performance numbers, but the approaches that the language takes and how
much that promises for the future:

For example I can develop a kind of container following this idea that
perform badly both in single and multithreaded. for sure the early version
should be so. But, if  people understand that the design has potential for
being optimized in the future, people will buy the idea and will accept
happily the Haskell language for performance semi-critical apps because
they will have arguments against the objections of this kind .

2015-11-12 23:56 GMT+01:00 Michael Snoyman <michael at snoyman.com>:

> How about vector-th-unbox[1]?
>
> [1] https://www.stackage.org/package/vector-th-unbox
>
> On Thu, Nov 12, 2015 at 2:53 PM, Alberto G. Corona <agocorona at gmail.com>
> wrote:
>
>> There are no examples. It is hard to guess the functionality and the
>> maturity of he approach.
>>
>> 2015-11-12 18:56 GMT+01:00 David Kraeutmann <kane at kane.cx>:
>>
>>> This might be of interest to you:
>>> https://hackage.haskell.org/package/structs
>>>
>>>
>>> On 11/12/2015 6:49 PM, Alberto G. Corona wrote:
>>> > Looking at this:
>>> >
>>> >
>>> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>>> >
>>> > It seems that it is impossible to manage data in Haskell within a core
>>> > without L1 cache faults. Except for unboxed arrays of primitive types.
>>> >
>>> > Since it is impossible to have unboxed arrays of user-defined types.
>>> >
>>> > Am I right?
>>> >
>>> > This is definitively very bad for tasks that are inherently single
>>> threaded
>>> > and in general for the image of Haskell as a practical language.
>>> >
>>> > I have more to say about that, but I would like to know first if I?m
>>> right
>>> > and second If there is some idea to going on to permit user defined
>>> boxed
>>> > datatypes.  Or if there is some low level trick for having it using
>>> foreign
>>> > call and unsafeCoerce in some way,
>>> >
>>> > I know that the language ATS has unboxing a la carte....
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskell-Cafe at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Alberto.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/048fdafa/attachment.html>

From dct25-561bs at mythic-beasts.com  Fri Nov 13 11:50:21 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Fri, 13 Nov 2015 11:50:21 +0000
Subject: [Haskell-cafe] Where did these threads come from?
In-Reply-To: <CAErCyQ_FzDf6czzp7t3kbFwPdQ_9tP9MsRJUGFKtDFm15t8Odw@mail.gmail.com>
References: <CAErCyQ_FzDf6czzp7t3kbFwPdQ_9tP9MsRJUGFKtDFm15t8Odw@mail.gmail.com>
Message-ID: <CAErCyQ-wphmaeDSM2HEY83Vo62P0UEATkR_t9Wvi3nhdTTB7vw@mail.gmail.com>

Ah yes, and the more obvious question: should I just run it with -I0? I'm
kind of assuming that the idle GC is a Good Thing since it's on by default.

Cheers,

On 13 November 2015 at 11:11, David Turner <dct25-561bs at mythic-beasts.com>
wrote:

> Hi all,
>
> I'm working on a server process that has (by design) fairly high memory
> usage but serves relatively few requests and spends most of its time idle.
> By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to
> improve its quiescent CPU usage as this is currently the limiting factor
> for how cheaply we can run this service - we're aiming for the cheapest
> t-class EC2 machine we can get.
>
> The quiescent CPU usage is currently about 50%. This seems to be largely
> due to the idle GC, because running with -I0 cuts it down to about 0.3%.
> Pretty much every time any thread wakes up it triggers the idle GC a short
> while later and because of the high memory usage these GCs are somewhat
> expensive.
>
> Using threadscope I found the biggest problem was the reaper thread in
> resource-pool which wakes up every second whether there's anything to reap
> or not. Fortunately this was easy to spot as the reaper thread labels
> itself as such. I've replaced this with an event-driven reaper that only
> wakes up on demand and cut the baseline from 50% down to just under 10%.
>
> There are two more threads I can now see waking up periodically in
> threadscope, with respective periods approximately 10 sec and 30 sec. I
> have a hunch what the 30-sec one is but no idea about the 10-sec one. If I
> can kill off the 10 sec one then that should take CPU usage down to <5%
> which would be just fine.
>
> My question: is there any reliable way to determine where these threads
> came from, in terms of the location of the forkIO call that made them? I've
> just been looking for likely candidates and labelling threads and this is
> rather tedious.
>
> Cheers,
>
> David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/9aef7f2f/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Fri Nov 13 13:12:35 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 13 Nov 2015 14:12:35 +0100
Subject: [Haskell-cafe] Registration now open: Haskell in Leipzig (Germany)
	December 4/5
Message-ID: <5645E1C3.3050109@htwk-leipzig.de>

Register now - for Amazing Talks and Thrilling Tutorials:

      HaL-10  Haskell in Leipzig  December 4/5
      http://nfa.imn.htwk-leipzig.de/HAL2015/

Opens with an invited talk by Joachim Breitner on MonadFix,
closes with a presentation of Liquid Haskell by Michael Beaumont.

- Johannes Waldmann.

PS: HaL-1 (in 2006, on quite the same day) also had a MonadFix talk.
Well of course, this has something to do with recurrence...

From greg at gregorycollins.net  Fri Nov 13 15:14:25 2015
From: greg at gregorycollins.net (Gregory Collins)
Date: Fri, 13 Nov 2015 07:14:25 -0800
Subject: [Haskell-cafe] Where did these threads come from?
In-Reply-To: <CAErCyQ-wphmaeDSM2HEY83Vo62P0UEATkR_t9Wvi3nhdTTB7vw@mail.gmail.com>
References: <CAErCyQ_FzDf6czzp7t3kbFwPdQ_9tP9MsRJUGFKtDFm15t8Odw@mail.gmail.com>
 <CAErCyQ-wphmaeDSM2HEY83Vo62P0UEATkR_t9Wvi3nhdTTB7vw@mail.gmail.com>
Message-ID: <CAHZrzdqBBRjeuoQMMqN7ZzFv6m-KfFCSmRMihhO-Wf1M-7Os0A@mail.gmail.com>

What idle GC does for you is tries to make you take the latency hit for
garbage collection when your program is not CPU-bound, rather than doing it
when you hit an arbitrary allocation threshold (probably during request
processing when you're actually doing work). So in that case it's a good
thing, yes --- but for yours I'd probably turn it off too. Other tweaks you
can try include tweaking the RTS gc settings if you haven't already,
especially increasing -A.

On Fri, Nov 13, 2015 at 3:50 AM, David Turner <dct25-561bs at mythic-beasts.com
> wrote:

> Ah yes, and the more obvious question: should I just run it with -I0? I'm
> kind of assuming that the idle GC is a Good Thing since it's on by default.
>
> Cheers,
>
> On 13 November 2015 at 11:11, David Turner <dct25-561bs at mythic-beasts.com>
> wrote:
>
>> Hi all,
>>
>> I'm working on a server process that has (by design) fairly high memory
>> usage but serves relatively few requests and spends most of its time idle.
>> By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to
>> improve its quiescent CPU usage as this is currently the limiting factor
>> for how cheaply we can run this service - we're aiming for the cheapest
>> t-class EC2 machine we can get.
>>
>> The quiescent CPU usage is currently about 50%. This seems to be largely
>> due to the idle GC, because running with -I0 cuts it down to about 0.3%.
>> Pretty much every time any thread wakes up it triggers the idle GC a short
>> while later and because of the high memory usage these GCs are somewhat
>> expensive.
>>
>> Using threadscope I found the biggest problem was the reaper thread in
>> resource-pool which wakes up every second whether there's anything to reap
>> or not. Fortunately this was easy to spot as the reaper thread labels
>> itself as such. I've replaced this with an event-driven reaper that only
>> wakes up on demand and cut the baseline from 50% down to just under 10%.
>>
>> There are two more threads I can now see waking up periodically in
>> threadscope, with respective periods approximately 10 sec and 30 sec. I
>> have a hunch what the 30-sec one is but no idea about the 10-sec one. If I
>> can kill off the 10 sec one then that should take CPU usage down to <5%
>> which would be just fine.
>>
>> My question: is there any reliable way to determine where these threads
>> came from, in terms of the location of the forkIO call that made them? I've
>> just been looking for likely candidates and labelling threads and this is
>> rather tedious.
>>
>> Cheers,
>>
>> David
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/432cf64f/attachment.html>

From michael at schmong.org  Fri Nov 13 15:16:19 2015
From: michael at schmong.org (Michael Litchard)
Date: Fri, 13 Nov 2015 07:16:19 -0800
Subject: [Haskell-cafe] Do I Need To Write An Instance for Assertable Here?
Message-ID: <CAEzeKYoq=WOYu55nibuAfF1Kkwkrn5E6W0jMjGsYd6-bZnt=9Q@mail.gmail.com>

Below is some test code I am writing for my game, the link to the
entire codebase, the error message and some discussion

main :: IO ()
main = defaultMain
  [ testGroup "EventNetwork Input"
    [testBuffer "bBuffer" Populated]
  ]

testBuffer :: String -> BufferState -> Test
testBuffer name Populated =
  testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move
(ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))
testBuffer name Empty =
  testCase name $ assert $ bufferEmptied (UAC (PlayerCommand (Move
(ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))

bufferPopulated :: UAC -> MomentIO Bool
bufferPopulated ev = do
  let eInput = ev <$ never
      eValidated = toVAC <$> eInput
  bBufferMap <- (buffer eValidated eClear) :: MomentIO (Behavior BufferMap)
  let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100"))
(toVAC ev) (M.empty :: M.Map AID VAC))]
  r1 <- liftIO $ ((interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap])
  return $ r1 == r2

bufferEmptied :: UAC -> MomentIO Bool
bufferEmptied ev = undefined

eBuffer :: Behavior BufferMap -> Event a -> Event BufferMap
eBuffer bBufferMap nvr =
  bBufferMap <@ (() <$ nvr)

eClear = Clear <$ (() <$ never)


When I run stack build I get

tests/Spec.hs:26:19:
    No instance for (Test.HUnit.Base.Assertable (MomentIO Bool))
      arising from a use of ?assert?
In the expression: assert
In the second argument of ?($)?, namely
  ?assert
   $ bufferPopulated
       (UAC
          (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))?
In the expression:
  testCase name
  $ assert
    $ bufferPopulated
        (UAC
           (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))

The problem lies with buffer. It relies on accumB which requires the
MomentIO monad. I considered writing an
instance for Assertable, but I think that's a red-herring and the
answer lies elsewhere. I need to reconcile the
fact that assert wants an IO Bool, but accumB wants a MomentIO. Maybe
I do need to write an instance for Assertable.

Here's the link to the
project:https://github.com/mlitchard/emporos/tree/banana-1.0.0/src
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/ea0c168c/attachment.html>

From michael at schmong.org  Fri Nov 13 16:48:06 2015
From: michael at schmong.org (Michael Litchard)
Date: Fri, 13 Nov 2015 08:48:06 -0800
Subject: [Haskell-cafe] Do I Need To Write An Instance for Assertable
	Here?
In-Reply-To: <CAEzeKYoq=WOYu55nibuAfF1Kkwkrn5E6W0jMjGsYd6-bZnt=9Q@mail.gmail.com>
References: <CAEzeKYoq=WOYu55nibuAfF1Kkwkrn5E6W0jMjGsYd6-bZnt=9Q@mail.gmail.com>
Message-ID: <CAEzeKYonx+-M8arwL6O=sw9e-Zp73fp0Y_w=x=zdBxcFPC=+PA@mail.gmail.com>

 I think I'm on the right track. I have commented out all test harness code
and have changed the signature for bufferPopulated

bufferPopulated :: UAC -> IO Bool
bufferPopulated ev = do
  let eInput = ev <$ never
      eValidated = toVAC <$> eInput
  bBufferMap <- liftMoment ((buffer eValidated eClear) :: Moment
(Behavior BufferMap))
  let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100"))
(toVAC ev) (M.empty :: M.Map AID VAC))]
  r1 <- (interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap])
  return $ r1 == r2

I believe this should work, but here's the error

tests/Spec.hs:35:17:
    No instance for (MonadMoment IO) arising from a use of ?liftMoment?
    In a stmt of a 'do' block:
      bBufferMap <- liftMoment
                      ((buffer eValidated eClear) :: Moment (Behavior
 BufferMap))

Let's take a look at MonadMoment from Reactive.Banana.Combinators
class Monad m => MonadMoment m where
 An instance of the MonadMoment class denotes a computation that happens at
one particular moment in time.
 Unlike the Moment monad, it need not be pure anymore.
 Methods
   liftMoment :: Moment a -> m a
 Instances
 MonadMoment MomentIO
 MonadMoment Moment

m can be any Monad, IO is a Monad. so liftMoment should lift the Moment
Behavior (BufferMap) to IO Behavior (BufferMap) , why doesn't it. What's
wrong with my reasoning?


On Fri, Nov 13, 2015 at 7:16 AM, Michael Litchard <michael at schmong.org>
wrote:

> Below is some test code I am writing for my game, the link to the entire codebase, the error message and some discussion
>
> main :: IO ()
> main = defaultMain
>   [ testGroup "EventNetwork Input"
>     [testBuffer "bBuffer" Populated]
>   ]
>
> testBuffer :: String -> BufferState -> Test
> testBuffer name Populated =
>   testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))
> testBuffer name Empty =
>   testCase name $ assert $ bufferEmptied (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))
>
> bufferPopulated :: UAC -> MomentIO Bool
> bufferPopulated ev = do
>   let eInput = ev <$ never
>       eValidated = toVAC <$> eInput
>   bBufferMap <- (buffer eValidated eClear) :: MomentIO (Behavior BufferMap)
>   let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100")) (toVAC ev) (M.empty :: M.Map AID VAC))]
>   r1 <- liftIO $ ((interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap])
>   return $ r1 == r2
>
> bufferEmptied :: UAC -> MomentIO Bool
> bufferEmptied ev = undefined
>
> eBuffer :: Behavior BufferMap -> Event a -> Event BufferMap
> eBuffer bBufferMap nvr =
>   bBufferMap <@ (() <$ nvr)
>
> eClear = Clear <$ (() <$ never)
>
>
> When I run stack build I get
>
> tests/Spec.hs:26:19:
>     No instance for (Test.HUnit.Base.Assertable (MomentIO Bool))
>       arising from a use of ?assert?
> In the expression: assert
> In the second argument of ?($)?, namely
>   ?assert
>    $ bufferPopulated
>        (UAC
>           (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))?
> In the expression:
>   testCase name
>   $ assert
>     $ bufferPopulated
>         (UAC
>            (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))
>
> The problem lies with buffer. It relies on accumB which requires the MomentIO monad. I considered writing an
> instance for Assertable, but I think that's a red-herring and the answer lies elsewhere. I need to reconcile the
> fact that assert wants an IO Bool, but accumB wants a MomentIO. Maybe I do need to write an instance for Assertable.
>
> Here's the link to the project:https://github.com/mlitchard/emporos/tree/banana-1.0.0/src
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/49ea46b3/attachment.html>

From jo at durchholz.org  Fri Nov 13 19:43:36 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 13 Nov 2015 20:43:36 +0100
Subject: [Haskell-cafe] The last decade: what has changed,
	was has stayed the same?
Message-ID: <56463D68.6020600@durchholz.org>

Hi all,

I used to be interested in Haskell roughly a decade ago, then life happened.
Now that I'm setting up project work, I'm interested in what has been 
happening in the meantime.
I read a bit on the usual pages, did a quick scan of the mailing list, 
didn't find out what the important questions of today are and what 
answers exist.

Some ideas of relevant questions below.
Feel free to pose and answer your own questions :-)

After learning the bare language, how long does it take a competent 
programmer to become confident in the performance of his Haskell code?

After learning the bare language, how long does it take a competent 
programmer to know when and when not to use strictness 
annotations/operators?

I'm seeing a lot of typesystem golf happening.
Is this teachable to the average competent programmer?
Is it relevant to everyday programming such as business logic, database 
access, or webpage generation? (If no, for what programming endeavours 
is it relevant?)

What's the status of debugging - I dimly remember a rough consensus that 
stack traces are hard to interpret in a meaningful way.
(I know that debugging is far less important for a referentially 
transparent language than for others, but it would still be interesting.)

What's the status of all the "boring stuff":
- logging
- profiling
- dialog layout
- input validation
- database interaction
- webpage generation, webflow
- multi-tiered applications

On the "instant to-do" side: What would a competent programmer need to 
do to become a competent Haskell programmer?
(I suspect the usual set of toy projects will not work. Toy projects 
give you only so much mileage; in particular, you don't learn anything 
about what patterns will hold up for larger projects and what patterns 
won't scale.)

Regards,
Jo

From ryani.spam at gmail.com  Fri Nov 13 22:43:02 2015
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Fri, 13 Nov 2015 14:43:02 -0800
Subject: [Haskell-cafe] Do I Need To Write An Instance for Assertable
	Here?
In-Reply-To: <CAEzeKYonx+-M8arwL6O=sw9e-Zp73fp0Y_w=x=zdBxcFPC=+PA@mail.gmail.com>
References: <CAEzeKYoq=WOYu55nibuAfF1Kkwkrn5E6W0jMjGsYd6-bZnt=9Q@mail.gmail.com>
 <CAEzeKYonx+-M8arwL6O=sw9e-Zp73fp0Y_w=x=zdBxcFPC=+PA@mail.gmail.com>
Message-ID: <CA+XKtKjLOeQPQ2H_BAB_WznZz6RpcsuZ0765S-KuHVbLUjRYgA@mail.gmail.com>

Here's the important info:
    liftMoment :: MonadMoment m => Moment a -> m a
    instance MonadMoment MomentIO
    instance MonadMoment Moment

So liftMoment gives you a MomentIO or a Moment, not an IO.  You need to do
something with that.

From
https://hackage.haskell.org/package/reactive-banana-1.0.0.0/docs/Reactive-Banana-Frameworks.html#v:compile
    compile :: MomentIO () -> IO EventNetwork

It looks like the intended usage is to compile into an EventNetwork, then
use the functions that operate on EventNetwork (like "actuate" to start
it).  If you need to get a boolean value out, you need another way to do so
(such as using reactimate to call a callback)

  -- ryan

On Fri, Nov 13, 2015 at 8:48 AM, Michael Litchard <michael at schmong.org>
wrote:

>  I think I'm on the right track. I have commented out all test harness
> code and have changed the signature for bufferPopulated
>
> bufferPopulated :: UAC -> IO Bool
> bufferPopulated ev = do
>   let eInput = ev <$ never
>       eValidated = toVAC <$> eInput
>   bBufferMap <- liftMoment ((buffer eValidated eClear) :: Moment    (Behavior BufferMap))
>   let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100")) (toVAC ev) (M.empty :: M.Map AID VAC))]
>   r1 <- (interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap])
>   return $ r1 == r2
>
> I believe this should work, but here's the error
>
> tests/Spec.hs:35:17:
>     No instance for (MonadMoment IO) arising from a use of ?liftMoment?
>     In a stmt of a 'do' block:
>       bBufferMap <- liftMoment
>                       ((buffer eValidated eClear) :: Moment (Behavior   BufferMap))
>
> Let's take a look at MonadMoment from Reactive.Banana.Combinators
> class Monad m => MonadMoment m where
>  An instance of the MonadMoment class denotes a computation that happens
> at one particular moment in time.
>  Unlike the Moment monad, it need not be pure anymore.
>  Methods
>    liftMoment :: Moment a -> m a
>  Instances
>  MonadMoment MomentIO
>  MonadMoment Moment
>
> m can be any Monad, IO is a Monad. so liftMoment should lift the Moment
> Behavior (BufferMap) to IO Behavior (BufferMap) , why doesn't it. What's
> wrong with my reasoning?
>
>
> On Fri, Nov 13, 2015 at 7:16 AM, Michael Litchard <michael at schmong.org>
> wrote:
>
>> Below is some test code I am writing for my game, the link to the entire codebase, the error message and some discussion
>>
>> main :: IO ()
>> main = defaultMain
>>   [ testGroup "EventNetwork Input"
>>     [testBuffer "bBuffer" Populated]
>>   ]
>>
>> testBuffer :: String -> BufferState -> Test
>> testBuffer name Populated =
>>   testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))
>> testBuffer name Empty =
>>   testCase name $ assert $ bufferEmptied (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100"))))
>>
>> bufferPopulated :: UAC -> MomentIO Bool
>> bufferPopulated ev = do
>>   let eInput = ev <$ never
>>       eValidated = toVAC <$> eInput
>>   bBufferMap <- (buffer eValidated eClear) :: MomentIO (Behavior BufferMap)
>>   let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100")) (toVAC ev) (M.empty :: M.Map AID VAC))]
>>   r1 <- liftIO $ ((interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap])
>>   return $ r1 == r2
>>
>> bufferEmptied :: UAC -> MomentIO Bool
>> bufferEmptied ev = undefined
>>
>> eBuffer :: Behavior BufferMap -> Event a -> Event BufferMap
>> eBuffer bBufferMap nvr =
>>   bBufferMap <@ (() <$ nvr)
>>
>> eClear = Clear <$ (() <$ never)
>>
>>
>> When I run stack build I get
>>
>> tests/Spec.hs:26:19:
>>     No instance for (Test.HUnit.Base.Assertable (MomentIO Bool))
>>       arising from a use of ?assert?
>> In the expression: assert
>> In the second argument of ?($)?, namely
>>   ?assert
>>    $ bufferPopulated
>>        (UAC
>>           (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))?
>> In the expression:
>>   testCase name
>>   $ assert
>>     $ bufferPopulated
>>         (UAC
>>            (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))
>>
>> The problem lies with buffer. It relies on accumB which requires the MomentIO monad. I considered writing an
>> instance for Assertable, but I think that's a red-herring and the answer lies elsewhere. I need to reconcile the
>> fact that assert wants an IO Bool, but accumB wants a MomentIO. Maybe I do need to write an instance for Assertable.
>>
>> Here's the link to the project:https://github.com/mlitchard/emporos/tree/banana-1.0.0/src
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151113/b1d921ed/attachment.html>

From gruen0aermel at gmail.com  Sat Nov 14 04:14:06 2015
From: gruen0aermel at gmail.com (Aaron VonderHaar)
Date: Fri, 13 Nov 2015 20:14:06 -0800
Subject: [Haskell-cafe] test coverage of Parsec parsers
Message-ID: <CAMZecXn6ycrWYhujxrx-bN14MY_bjRmOqMCHd1VbAenCLZ3_Bw@mail.gmail.com>

Hi, I'm adding HUnit tests to a parser that uses Parsec, and I wanted
to see test coverage of my parser.  I've successfully used hpc to get
a coverage report, but it has a significant deficiency:  An expression
in my parser will show as covered if the expression is ever evaluated,
but I'd really like to see branch coverage of the parser monads.

For example, if I have a single test that parses the string "*" with
the following parser:

plusOrStar =
    do
        result <- (string "+" <|> string "*")
        _ <- (many $ string " ")
        return result

then hpc will report that all the code is covered, but I'd like to be
able to see the fact that (string "+") only ever failed, and that
(string "*") only ever succeeded.

Are there any existing tools for getting that sort of coverage report
for parsers or monads?  Is there an approach other than hpc that I
should be considering to get confidence in my test suite?  If not, I
understand that hpc works by doing source-code transformation--does it
seem like a reasonable endeavor to try to customize it to do what I am
interested in?

Thanks,
--Aaron V.

From martin.drautzburg at web.de  Sat Nov 14 10:10:15 2015
From: martin.drautzburg at web.de (martin)
Date: Sat, 14 Nov 2015 11:10:15 +0100
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
Message-ID: <56470887.9030502@web.de>

Hello all,

I have a Logger which produces log entries and a new version of itself

newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)}

Loggers are used in a function like this

runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log
runSim (!lgr, !hdr, xtp) (!log,!dom,!evq)  =
        case step of
            Nothing -> (log, dom, evq) -- end of simulation
            Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq)
        where
            -- check for end conditions or run handler
            step = do
                (evt, evts) <- H.view evq -- no more Events -> Nothing
                if xtp (evt,dom)  then Nothing
                else
                        let (evq', dom', hdr') = runHandler hdr evt dom
                            (log',lgr')        = runLogger lgr evt dom'        -- <--
                        -- append new event and new log entries
                        in return (evq'<>evts, dom', hdr', lgr', log'<>log)    -- <--



I then wrote a function to combine two Loggers

addLgr (lgr1) (lgr2) = Lgr lgr
        where
            lgr tev dom = let (log1', lgr1') = runLogger lgr1  tev dom
                              (log2', lgr2') = runLogger lgr2  tev dom
                              (!log') = log2'  <> log1'                       -- x --
--                          in (log2', addLgr lgr1' lgr2')
                          in (log', addLgr lgr1' lgr2')


When called a million times, this produces a heap profile which climbs steadily (with or without the stricness
annotation in line x). When I omit the (<>) as in the commented line, the heap stays flat. My log is really just a list
of strings and most of the time the loggers do not produce any output, i.e. they return an empty list.

Am I on the right track, that this trouble is probably caused by laziness and that forcing strictness is the way to go?

Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious
reason, I just fail to see.

Where to go from here?





From agocorona at gmail.com  Sat Nov 14 11:30:12 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Sat, 14 Nov 2015 12:30:12 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
Message-ID: <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>

Michael,

Thanks to your insight I took a look at Data.Vector.Unboxed

I was very happy, but there is a caveat; Looking at the documentation:

"In particular, unboxed vectors of pairs are represented as pairs of
unboxed vectors". https://tldrify.com/cfj

it seems that derivingUnbox and all the Unboxed Vectors code do as much as
is possible with what GHC offers to make things unboxed, which are reduced
to the primitive types.

So the only way to pack an user defined data is to create one Vector of
unboxed primitive type for each  field of the data . So if I have a data
with five fields the result is five Vectors.

This is nice in some cases, but does most of the time does not. this does
not solve the problem of CPU cache since the fields in the data are at
least lenght (Vector)  away. I mean that if the vector is moderately long,
if the first field is in the cache, the second or third etc may not be.
Usually the fields of any data are handled together.

This solution will not match C- C++ speed consistently for most single
threaded programs.  Moreover there is an additional cost in the
packing/unpacking necessary.

However this is the best that can be done with what GHC offers now.

The solution is the possibility of unboxed user-defined types:

data MyUnboxedData= MyUnboxedData#    Int#    Float# ....

where MyUnboxedData#   is an unboxed constructor

Then there are some questions:
1) Am I wrong?
2) It is feashible?
3) It is worth the pain? (My answer: yes This is not satisfactory, it is
very important for Haskell success and should be addressed if there is no
 insurmountable barrier)
4) Are there alternatives before making a formal proposal?

Thanks

2015-11-13 12:42 GMT+01:00 Alberto G. Corona <agocorona at gmail.com>:

> That is more practical.
>
> It is a pity that the Unboxed class does not interact with the UNPACK
> pragma. Or it seems so.
>
> The problem that round my head after being exposed to the Google
> phylosophy of "count the bytes" is the trade off when choosing containers:
> Either boxed, pure, linked multithreaded or  unboxed mutable single
> threaded.
>
> Haskell philosophy choose the first, while almost all the mainstream
> languages choose the second. That is another problem for the adoption of
> haskell.  Google people say: we don?t need multithreaded programs because
> we run many single threaded programs in one machine, we use all the cores.
> Only when there is a single application to run the justification for the
> extra effort of multithreading is justified. And this happens rarely in the
> real world: In scientific, engineering, financial it is usual. It also
> happens in distributed settings but in that last case, performance per
> thread and core is also critical, so Haskell is ruled out.
>
> But that hasn?t to be that way, or at least that is what I think.
> DiffUArrays are internally mutable but with a pure interface.  They use a
> kind of versioning. in single threaded environments it theoretically
> perform at mutable speeds.  the versioning of diffArray is the blend of
> packed and linked structure that can mix the two worlds.
>
> If the unboxing is extended to any kind of user defined data, the
> versioning idea can be used to have containers that perform at C speeds
> when single threaded, but preserve the purity when multithreaded.  So it is
> possible to have the cake and eat it too.
>
> it is even possible to codify balanced binary trees in a compact
> diffarray, so very fast maps can be used in single threaded applications
> that also are pure and work multithreaded.
>
> The goal is to remove the objections about haskell coming from that side
> of the computer industry by having such containers available without
> forcing the user to know lots of things about the internals of haskell and
> GHC.
>
> I do not know if there are thing going on in some of this direction. Maybe
> I?m being simplistic and there is something that I miss .
>
> By experience I know that what sell more from a language is not the real
> performance numbers, but the approaches that the language takes and how
> much that promises for the future:
>
> For example I can develop a kind of container following this idea that
> perform badly both in single and multithreaded. for sure the early version
> should be so. But, if  people understand that the design has potential for
> being optimized in the future, people will buy the idea and will accept
> happily the Haskell language for performance semi-critical apps because
> they will have arguments against the objections of this kind .
>
> 2015-11-12 23:56 GMT+01:00 Michael Snoyman <michael at snoyman.com>:
>
>> How about vector-th-unbox[1]?
>>
>> [1] https://www.stackage.org/package/vector-th-unbox
>>
>> On Thu, Nov 12, 2015 at 2:53 PM, Alberto G. Corona <agocorona at gmail.com>
>> wrote:
>>
>>> There are no examples. It is hard to guess the functionality and the
>>> maturity of he approach.
>>>
>>> 2015-11-12 18:56 GMT+01:00 David Kraeutmann <kane at kane.cx>:
>>>
>>>> This might be of interest to you:
>>>> https://hackage.haskell.org/package/structs
>>>>
>>>>
>>>> On 11/12/2015 6:49 PM, Alberto G. Corona wrote:
>>>> > Looking at this:
>>>> >
>>>> >
>>>> https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.html
>>>> >
>>>> > It seems that it is impossible to manage data in Haskell within a core
>>>> > without L1 cache faults. Except for unboxed arrays of primitive types.
>>>> >
>>>> > Since it is impossible to have unboxed arrays of user-defined types.
>>>> >
>>>> > Am I right?
>>>> >
>>>> > This is definitively very bad for tasks that are inherently single
>>>> threaded
>>>> > and in general for the image of Haskell as a practical language.
>>>> >
>>>> > I have more to say about that, but I would like to know first if I?m
>>>> right
>>>> > and second If there is some idea to going on to permit user defined
>>>> boxed
>>>> > datatypes.  Or if there is some low level trick for having it using
>>>> foreign
>>>> > call and unsafeCoerce in some way,
>>>> >
>>>> > I know that the language ATS has unboxing a la carte....
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Haskell-Cafe mailing list
>>>> > Haskell-Cafe at haskell.org
>>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Alberto.
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/950055f8/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Nov 14 11:37:47 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 14 Nov 2015 11:37:47 +0000
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
Message-ID: <20151114113747.GH28889@weber>

On Sat, Nov 14, 2015 at 12:30:12PM +0100, Alberto G. Corona  wrote:
> 4) Are there alternatives before making a formal proposal?

I think you should talk to Edward Kmett and Johan Tibell about this.
They are interested in such matters.

Tom

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Nov 14 12:23:54 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 14 Nov 2015 12:23:54 +0000
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
In-Reply-To: <56470887.9030502@web.de>
References: <56470887.9030502@web.de>
Message-ID: <20151114122354.GI28889@weber>

On Sat, Nov 14, 2015 at 11:10:15AM +0100, martin wrote:
> newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)}
> 
> runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log
> runSim (!lgr, !hdr, xtp) (!log,!dom,!evq)  =
>         case step of
>             Nothing -> (log, dom, evq) -- end of simulation
>             Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq)
>         where
>             -- check for end conditions or run handler
>             step = do
>                 (evt, evts) <- H.view evq -- no more Events -> Nothing
>                 if xtp (evt,dom)  then Nothing
>                 else
>                         let (evq', dom', hdr') = runHandler hdr evt dom
>                             (log',lgr')        = runLogger lgr evt dom'        -- <--
>                         -- append new event and new log entries
>                         in return (evq'<>evts, dom', hdr', lgr', log'<>log)    -- <--
> 
> addLgr (lgr1) (lgr2) = Lgr lgr
>         where
>             lgr tev dom = let (log1', lgr1') = runLogger lgr1  tev dom
>                               (log2', lgr2') = runLogger lgr2  tev dom
>                               (!log') = log2'  <> log1'                       -- x --
> --                          in (log2', addLgr lgr1' lgr2')
>                           in (log', addLgr lgr1' lgr2')
> 
[...]
> Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious
> reason, I just fail to see.

Yes, forcing a list is more-or-less useless, most of the time.  All you're
doing is checking whether the length is zero or non-zero.

> Where to go from here?

The first thing to do would be to check whether

    import Control.DeepSeq

    ...

    !log' = deepseq (log2'  <> log1')

solves the space leak.  If it does then you have found the problem.  That's
not the same thing as finding a solution though!

There are plenty of pre-rolled logging solutions available.  I think I'd
just suggest choosing one of those, rather than implementing your own.

Tom

From martin.drautzburg at web.de  Sat Nov 14 12:28:58 2015
From: martin.drautzburg at web.de (martin)
Date: Sat, 14 Nov 2015 13:28:58 +0100
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
In-Reply-To: <56470887.9030502@web.de>
References: <56470887.9030502@web.de>
Message-ID: <5647290A.6070609@web.de>

I profiled the program and the profile does not say anything about THUNKs. Instead the main culprit seems to be

(352)cor.cnd/cor/ex_lgr.lo...	2837612

This probably points to this function:

newtype Condition a  = Cnd {checkCnd :: a ->  (Bool, Condition a)}

-- | Create a 'Condition' from two conditions which holds when one of
-- them holds.
cor :: Condition a -> Condition a -> Condition a
cor c1 c2 = Cnd cnd
        where
            cnd a = let (b1', c1') = checkCnd c1 a
                        (b2', c2') = checkCnd c2 a
                    in if b1' || b2'
                       then (True,  cor c1' c2')
                       else (False, cor c1 c2)


logWhen :: Monoid log => Condition (Timed evt,dom) -> Logger evt dom log -> Logger evt dom log
logWhen cnd lgrIn = Lgr lgr'
        where
            lgr' tev dom =
                    case checkCnd cnd (tev, dom) of
                        (True, cnd') -> let (log', lgrIn') = runLogger lgrIn tev dom
                                         in (log', logWhen cnd' lgrIn')
                        (False,cnd')   -> (mempty, logWhen cnd' lgrIn)

Am I holding on to some data where I shouldn't? I cannot see it.


Am 11/14/2015 um 11:10 AM schrieb martin:
> Hello all,
> 
> I have a Logger which produces log entries and a new version of itself
> 
> newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)}
> 
> Loggers are used in a function like this
> 
> runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log
> runSim (!lgr, !hdr, xtp) (!log,!dom,!evq)  =
>         case step of
>             Nothing -> (log, dom, evq) -- end of simulation
>             Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq)
>         where
>             -- check for end conditions or run handler
>             step = do
>                 (evt, evts) <- H.view evq -- no more Events -> Nothing
>                 if xtp (evt,dom)  then Nothing
>                 else
>                         let (evq', dom', hdr') = runHandler hdr evt dom
>                             (log',lgr')        = runLogger lgr evt dom'        -- <--
>                         -- append new event and new log entries
>                         in return (evq'<>evts, dom', hdr', lgr', log'<>log)    -- <--
> 
> 
> 
> I then wrote a function to combine two Loggers
> 
> addLgr (lgr1) (lgr2) = Lgr lgr
>         where
>             lgr tev dom = let (log1', lgr1') = runLogger lgr1  tev dom
>                               (log2', lgr2') = runLogger lgr2  tev dom
>                               (!log') = log2'  <> log1'                       -- x --
> --                          in (log2', addLgr lgr1' lgr2')
>                           in (log', addLgr lgr1' lgr2')
> 
> 
> When called a million times, this produces a heap profile which climbs steadily (with or without the stricness
> annotation in line x). When I omit the (<>) as in the commented line, the heap stays flat. My log is really just a list
> of strings and most of the time the loggers do not produce any output, i.e. they return an empty list.
> 
> Am I on the right track, that this trouble is probably caused by laziness and that forcing strictness is the way to go?
> 
> Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious
> reason, I just fail to see.
> 
> Where to go from here?
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Nov 14 12:43:47 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 14 Nov 2015 12:43:47 +0000
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
In-Reply-To: <5647290A.6070609@web.de>
References: <56470887.9030502@web.de>
 <5647290A.6070609@web.de>
Message-ID: <20151114124347.GJ28889@weber>

On Sat, Nov 14, 2015 at 01:28:58PM +0100, martin wrote:
> newtype Condition a  = Cnd {checkCnd :: a ->  (Bool, Condition a)}
> 
> -- | Create a 'Condition' from two conditions which holds when one of
> -- them holds.
> cor :: Condition a -> Condition a -> Condition a
> cor c1 c2 = Cnd cnd
>         where
>             cnd a = let (b1', c1') = checkCnd c1 a
>                         (b2', c2') = checkCnd c2 a
>                     in if b1' || b2'
>                        then (True,  cor c1' c2')
>                        else (False, cor c1 c2)
> 
> 
> logWhen :: Monoid log => Condition (Timed evt,dom) -> Logger evt dom log -> Logger evt dom log
> logWhen cnd lgrIn = Lgr lgr'
>         where
>             lgr' tev dom =
>                     case checkCnd cnd (tev, dom) of
>                         (True, cnd') -> let (log', lgrIn') = runLogger lgrIn tev dom
>                                          in (log', logWhen cnd' lgrIn')
>                         (False,cnd')   -> (mempty, logWhen cnd' lgrIn)
> 
> Am I holding on to some data where I shouldn't? I cannot see it.

Sure, this

    (log', lgrIn') = runLogger lgrIn tev dom

allocates a thunk for log' that holds on to tev and dom.  Even if they are
small, holding onto them for thousands or millions of iterations is going to
leak a lot of space.

The only way to avoid this is to force log' sufficiently far that tev and
dom can be released.

Tom

From martin.drautzburg at web.de  Sat Nov 14 16:17:41 2015
From: martin.drautzburg at web.de (martin)
Date: Sat, 14 Nov 2015 17:17:41 +0100
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
In-Reply-To: <20151114124347.GJ28889@weber>
References: <56470887.9030502@web.de> <5647290A.6070609@web.de>
 <20151114124347.GJ28889@weber>
Message-ID: <56475EA5.1070505@web.de>


Thanks Tom,

with lots of trial and error I believe I finally put the exclamation marks in the right spots, but I still don't understand.

addLgr (lgr1) (lgr2) = Lgr lgr
        where
            lgr tev dom = let (!(log1', lgr1')) = runLogger lgr1  tev dom
                              (!(log2', lgr2')) = runLogger lgr2  tev dom
                              (!log') = log1' <> log2'
                          in (log', addLgr lgr2' lgr1')

I had previously put the marks inside the tuples as in (!log1', !lgr1') but that didn't help. Can someone explain the
difference between (!log1', !lgr1') and !(log1', lgr1'). I thought the former enforces more strictness than the later,
but I must be missing something.

Am 11/14/2015 um 01:43 PM schrieb Tom Ellis:
> On Sat, Nov 14, 2015 at 01:28:58PM +0100, martin wrote:
>> newtype Condition a  = Cnd {checkCnd :: a ->  (Bool, Condition a)}
>>
>> -- | Create a 'Condition' from two conditions which holds when one of
>> -- them holds.
>> cor :: Condition a -> Condition a -> Condition a
>> cor c1 c2 = Cnd cnd
>>         where
>>             cnd a = let (b1', c1') = checkCnd c1 a
>>                         (b2', c2') = checkCnd c2 a
>>                     in if b1' || b2'
>>                        then (True,  cor c1' c2')
>>                        else (False, cor c1 c2)
>>
>>
>> logWhen :: Monoid log => Condition (Timed evt,dom) -> Logger evt dom log -> Logger evt dom log
>> logWhen cnd lgrIn = Lgr lgr'
>>         where
>>             lgr' tev dom =
>>                     case checkCnd cnd (tev, dom) of
>>                         (True, cnd') -> let (log', lgrIn') = runLogger lgrIn tev dom
>>                                          in (log', logWhen cnd' lgrIn')
>>                         (False,cnd')   -> (mempty, logWhen cnd' lgrIn)
>>
>> Am I holding on to some data where I shouldn't? I cannot see it.
> 
> Sure, this
> 
>     (log', lgrIn') = runLogger lgrIn tev dom
> 
> allocates a thunk for log' that holds on to tev and dom.  Even if they are
> small, holding onto them for thousands or millions of iterations is going to
> leak a lot of space.
> 
> The only way to avoid this is to force log' sufficiently far that tev and
> dom can be released.
> 
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Nov 14 16:32:19 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 14 Nov 2015 16:32:19 +0000
Subject: [Haskell-cafe] Daunting heap profile when using (<>)
In-Reply-To: <56475EA5.1070505@web.de>
References: <56470887.9030502@web.de> <5647290A.6070609@web.de>
 <20151114124347.GJ28889@weber> <56475EA5.1070505@web.de>
Message-ID: <20151114163219.GK28889@weber>

On Sat, Nov 14, 2015 at 05:17:41PM +0100, martin wrote:
> with lots of trial and error I believe I finally put the exclamation marks
> in the right spots, but I still don't understand.

It's pretty reasonable not to understand!  Understanding exactly what's
going with strictness annotations can be very mind-bending.

> I had previously put the marks inside the tuples as in (!log1', !lgr1')
> but that didn't help.  Can someone explain the difference between (!log1',
> !lgr1') and !(log1', lgr1').  I thought the former enforces more
> strictness than the later, but I must be missing something.

Those two are completely independent.

let !(a, b) = ... forces the tuple constructor immedately, but not the
contents

let (!a, !b) = ... doesn't force the tuple constructor, but *when it is
forced* a and b will be forced at the same time.

Neither is more or less strict than the other.

Tom

From will.yager at gmail.com  Sat Nov 14 17:53:46 2015
From: will.yager at gmail.com (Will Yager)
Date: Sat, 14 Nov 2015 11:53:46 -0600
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
Message-ID: <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>

This is why CPUs have many independent cache lines. Unpacking a vector into multiple vectors is usually fine for performance. I have seen it actually increase performance, because it simplifies addressing. 

-Will

> On Nov 14, 2015, at 05:30, Alberto G. Corona <agocorona at gmail.com> wrote:
> 
> 
> This is nice in some cases, but does most of the time does not. this does not solve the problem of CPU cache since the fields in the data are at least lenght (Vector)  away. I mean that if the vector is moderately long, if the first field is in the cache, the second or third etc may not be. Usually the fields of any data are handled together.  
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/bed498c5/attachment.html>

From heraldhoi at gmail.com  Sat Nov 14 19:28:27 2015
From: heraldhoi at gmail.com (Geraldus)
Date: Sat, 14 Nov 2015 19:28:27 +0000
Subject: [Haskell-cafe] Darcs vs Git
Message-ID: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>

Hi friends!

I love Haskell very much.  So, I'm very interested in using Darcs.  Is
there some documentation explaining diffrences between Darcs and Git.  Is
there something that makes Darcs more robust rathen that Git.  Does Darcs
have some Emacs support (something like `magit`)?

And one other question.  Currently, I have no collaborators and use Git
majorly myself to have version control, e.g. to revert some bad code, to
have a nice log with code diffs and comments, and etc.  But in future I
will need something like GitHub for collaboration, is there a good solution
for Darcs' hub already?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/fc9ffe76/attachment.html>

From fa-ml at ariis.it  Sat Nov 14 19:43:09 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sat, 14 Nov 2015 20:43:09 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
Message-ID: <20151114194309.GA8829@casa.casa>

On Sat, Nov 14, 2015 at 07:28:27PM +0000, Geraldus wrote:
> Hi friends!
> 
> I love Haskell very much.  So, I'm very interested in using Darcs.  Is
> there some documentation explaining diffrences between Darcs and Git.  Is
> there something that makes Darcs more robust rathen that Git.  Does Darcs
> have some Emacs support (something like `magit`)?
> 
> And one other question.  Currently, I have no collaborators and use Git
> majorly myself to have version control, e.g. to revert some bad code, to
> have a nice log with code diffs and comments, and etc.  But in future I
> will need something like GitHub for collaboration, is there a good solution
> for Darcs' hub already?

Hello Geraldus, I am a happy darcs user. I enjoy its basic philosophy
much more than git one (patches vs. branches [1]); I do feel the
user experience to be much smoother, too.

There are darcs hosting services, one of them being darcs hub [2].

Or you can just upload the repository to your webspace and -presto-
you are ready. I work like this [3] alongside with some barebone
issue tracker [4] and I am pretty happy.


[1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory
[2] http://hub.darcs.net/
[3] http://www.ariis.it/link/repos/
[4] http://www.ariis.it/static/articles/lentil/page.html

From mwm at mired.org  Sat Nov 14 20:10:47 2015
From: mwm at mired.org (Mike Meyer)
Date: Sat, 14 Nov 2015 20:10:47 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <20151114194309.GA8829@casa.casa>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
Message-ID: <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>

Since we're talking about this, ones is the reasons I dislike for is that
it treats the project history just like any other prolix public document,
providing tools for modifying it, changing it as you push or pull, etc. I
disagree with this, and prefer tools that believe that history should be
immutable, like hg and fossil.

Which side, if either, of this does darcs land on?

On Sat, Nov 14, 2015, 13:45 Francesco Ariis <fa-ml at ariis.it> wrote:

> On Sat, Nov 14, 2015 at 07:28:27PM +0000, Geraldus wrote:
> > Hi friends!
> >
> > I love Haskell very much.  So, I'm very interested in using Darcs.  Is
> > there some documentation explaining diffrences between Darcs and Git.  Is
> > there something that makes Darcs more robust rathen that Git.  Does Darcs
> > have some Emacs support (something like `magit`)?
> >
> > And one other question.  Currently, I have no collaborators and use Git
> > majorly myself to have version control, e.g. to revert some bad code, to
> > have a nice log with code diffs and comments, and etc.  But in future I
> > will need something like GitHub for collaboration, is there a good
> solution
> > for Darcs' hub already?
>
> Hello Geraldus, I am a happy darcs user. I enjoy its basic philosophy
> much more than git one (patches vs. branches [1]); I do feel the
> user experience to be much smoother, too.
>
> There are darcs hosting services, one of them being darcs hub [2].
>
> Or you can just upload the repository to your webspace and -presto-
> you are ready. I work like this [3] alongside with some barebone
> issue tracker [4] and I am pretty happy.
>
>
> [1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory
> [2] http://hub.darcs.net/
> [3] http://www.ariis.it/link/repos/
> [4] http://www.ariis.it/static/articles/lentil/page.html
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/dafd9c1e/attachment.html>

From jo at durchholz.org  Sat Nov 14 20:52:10 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sat, 14 Nov 2015 21:52:10 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
Message-ID: <56479EFA.5040101@durchholz.org>

Am 14.11.2015 um 21:10 schrieb Mike Meyer:
> Since we're talking about this, ones is the reasons I dislike for is that
> it treats the project history just like any other prolix public document,
> providing tools for modifying it, changing it as you push or pull, etc. I
> disagree with this, and prefer tools that believe that history should be
> immutable, like hg and fossil.

Just curious: Why?

Background: in practice, I found that git projects do not allow 
rewriting history that has been pulled for any coding. The changes can't 
be committed without rebasing, which is both somewhat advanced and 
potentially painful (due to merge conflicts), so it's actively avoided.
There are variations such as setting aside repositories or branches for 
experimentation or patch preparation which may have their history 
rewritten, but that's just editing before the patch goes in, not a real 
history rewrite.
So I think the difference is less relevant than most people think - but 
then maybe I'm overlooking something, so what's your take?

Regards,
Jo

From mwm at mired.org  Sat Nov 14 22:37:26 2015
From: mwm at mired.org (Mike Meyer)
Date: Sat, 14 Nov 2015 22:37:26 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <56479EFA.5040101@durchholz.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
Message-ID: <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>

On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Am 14.11.2015 um 21:10 schrieb Mike Meyer:
> > Since we're talking about this, ones is the reasons I dislike for is that
> > it treats the project history just like any other prolix public document,
> > providing tools for modifying it, changing it as you push or pull, etc. I
> > disagree with this, and prefer tools that believe that history should be
> > immutable, like hg and fossil.
> Just curious: Why?
>

Philosophical. I want history to reflect the way things actually happened.


> So I think the difference is less relevant than most people think - but
> then maybe I'm overlooking something, so what's your take?
>

I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
are introduced. But that's minor to not wanting history hidden. I even had
someone ask that I collapse a bunch of changes when I pushed them to my
github repo before creating a PR. Not going to happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/bdf85c2e/attachment.html>

From qdunkan at gmail.com  Sun Nov 15 00:28:42 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 14 Nov 2015 16:28:42 -0800
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
Message-ID: <CACbaDy6rHv-AnQyLFaCRCeGH2dXCZgYn1DC7WnoNy7HJsMBiCQ@mail.gmail.com>

The best way to get a feel for how darcs is different is to just go
use darcs for a while.

The short version is that darcs is like jenga, where you can mess with
things in the middle as long as no one else depends on them.  Git is
like towers of hanoi, where you have to do a bunch of juggling
regardless.  Or you could say git is like C, with a single well
defined order of execution, and darcs is like haskell, where you often
don't even think about order except as it's constrained by data
dependency.

From carter.schonwald at gmail.com  Sun Nov 15 00:45:53 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 14 Nov 2015 19:45:53 -0500
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
 <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
Message-ID: <CAHYVw0yjoY4qsvo508gUP=8WY1Y8otM9oFDOg89dVakRJrT1Rg@mail.gmail.com>

Indeed! There's no one true best format.
There was some work to add native support for c structs to the Haskell ffi,
as storable format for non recursive records, but there's some really
gnarly subtleties with respect to alignment and packing that come up that
likely are fundamentally impossible to characterize in a simple algorithmic
fashion that will serve everyone well.

On Saturday, November 14, 2015, Will Yager <will.yager at gmail.com> wrote:

> This is why CPUs have many independent cache lines. Unpacking a vector
> into multiple vectors is usually fine for performance. I have seen it
> actually increase performance, because it simplifies addressing.
>
> -Will
>
> On Nov 14, 2015, at 05:30, Alberto G. Corona <agocorona at gmail.com
> <javascript:_e(%7B%7D,'cvml','agocorona at gmail.com');>> wrote:
>
>
> This is nice in some cases, but does most of the time does not. this does
> not solve the problem of CPU cache since the fields in the data are at
> least lenght (Vector)  away. I mean that if the vector is moderately long,
> if the first field is in the cache, the second or third etc may not be.
> Usually the fields of any data are handled together.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151114/925bfd84/attachment.html>

From ivan.miljenovic at gmail.com  Sun Nov 15 01:31:15 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 15 Nov 2015 12:31:15 +1100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
Message-ID: <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>

On 15 November 2015 at 09:37, Mike Meyer <mwm at mired.org> wrote:
> On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz <jo at durchholz.org> wrote:
>>
>> Am 14.11.2015 um 21:10 schrieb Mike Meyer:
>> > Since we're talking about this, ones is the reasons I dislike for is
>> > that
>> > it treats the project history just like any other prolix public
>> > document,
>> > providing tools for modifying it, changing it as you push or pull, etc.
>> > I
>> > disagree with this, and prefer tools that believe that history should be
>> > immutable, like hg and fossil.
>> Just curious: Why?
>
>
> Philosophical. I want history to reflect the way things actually happened.
>
>>
>> So I think the difference is less relevant than most people think - but
>> then maybe I'm overlooking something, so what's your take?
>
>
> I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
> are introduced. But that's minor to not wanting history hidden. I even had
> someone ask that I collapse a bunch of changes when I pushed them to my
> github repo before creating a PR. Not going to happen.

On the other hand, when accepting a PR, I don't want it to be full of
lots of little "let's see if this worked; nope I need a second commit"
messages cluttering up the git log: I recently had such a case where
there were empty commits called "test commit", etc.  Or in my own
work, if I accidentally forgot to include a hunk in a commit I prefer
to squash that change with the commit it was meant to be in rather
than have an extra commit.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From david.feuer at gmail.com  Sun Nov 15 05:37:01 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 15 Nov 2015 00:37:01 -0500
Subject: [Haskell-cafe] Mono-whatever
In-Reply-To: <CAMgWh9twkEPEm1f_miD=gitH5Nex30OFSToCegL0t4KRxUvf7w@mail.gmail.com>
References: <CAMgWh9tXcQHH7LrOeg2d79pN6uhOQx6L1t1BSipWQ8KKW7Dufg@mail.gmail.com>
 <CAMgWh9t+2uPtcRHOfH4FZN5VKcd6jSm14A7M-0X5oSD1k0VA8A@mail.gmail.com>
 <CAMgWh9twkEPEm1f_miD=gitH5Nex30OFSToCegL0t4KRxUvf7w@mail.gmail.com>
Message-ID: <CAMgWh9t07cq=W5fDMHTrJUP5ODUmkR0aJsohBLBqxaDa+gBgVA@mail.gmail.com>

Does any package define a type like this?

data X :: * -> k -> k -> * where
  X :: b -> X b t t

So

instance (MonoFoldable b, Element b ~ t) => Foldable (X b t) where
  foldMap f (X b) = ofoldMap f b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151115/2a6c8925/attachment.html>

From spam at scientician.net  Sun Nov 15 06:40:16 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sun, 15 Nov 2015 07:40:16 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
Message-ID: <n299cg$lu0$1@ger.gmane.org>

On 11/15/2015 02:31 AM, Ivan Lazar Miljenovic wrote:
> On 15 November 2015 at 09:37, Mike Meyer <mwm at mired.org> wrote:
>>
>> I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
>> are introduced. But that's minor to not wanting history hidden. I even had
>> someone ask that I collapse a bunch of changes when I pushed them to my
>> github repo before creating a PR. Not going to happen.
> 
> On the other hand, when accepting a PR, I don't want it to be full of
> lots of little "let's see if this worked; nope I need a second commit"
> messages cluttering up the git log: I recently had such a case where
> there were empty commits called "test commit", etc.  Or in my own
> work, if I accidentally forgot to include a hunk in a commit I prefer
> to squash that change with the commit it was meant to be in rather
> than have an extra commit.
> 

Yes -- this is one extremely important use case for rebase/squash. In
git, the commit history is *not* meant for preserving "what happened".
It's meant for humans to read when you're digging through change logs,
perhaps because you're hunting a bug.

I tend to find that people who want to preserve what happened have a
different way of working where they tend to try to create good commits
as they go whereas I (post-git) just create a bunch of "WIP" commits
for almost every change regardless of whether it compiles or not and
then clean up the "history" for readability once the full change is
ready for pushing to the world. I used to be in the former group, but
have found that moving to the in the latter workflow is incredibly
liberating. It means that I don't waste nearly as much time checking
that everything compiles (etc.) for every little change I make. I just
check all that stuff for the final series of commits.

"Patch theory" is all well and good, but it's missing the point, IMO.
Tools *must* have a manual override for when the user knows best[1] and
that also means adapting to *my* workflow rather than me having to
constantly think mind "should I commit now?", "which order do I need to
do my refactoring in to get small reviewable commits?", etc. With git,
it's very rare to have to think about this.

Now, we've talked about squashing, but I also find that *splitting*
commits to be hugely valueable in that you can often
(post-working-frenzy) split everything into neat, logically coherent
easily reviewable commits/chunks. Absent strong AI, no "patch theory"
can do this since it's not a technical problem.

That's what I like about Git -- it works on *my* terms rather than its
terms. (Yeah, the UI isn't exactly great[1], but once you're over the
learning curve the UX *is*, IMO.)

Regards,

[1] If you're an emacs user: Use "magit" it's incredible. Maybe even
worth learning emacs for.


From spam at scientician.net  Sun Nov 15 07:00:39 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sun, 15 Nov 2015 08:00:39 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <n299cg$lu0$1@ger.gmane.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
Message-ID: <n29aio$81k$1@ger.gmane.org>

(Sorry about the self-reply -- just wanted to clarify a bit:)

On 11/15/2015 07:40 AM, Bardur Arantsson wrote:

> 
> That's what I like about Git -- it works on *my* terms rather than its
> terms. (Yeah, the UI isn't exactly great[1], but once you're over the
> learning curve the UX *is*, IMO.)
> 

I also tend to find that some of the UX advantages are actually
*predicated* on doing lots of commits all the time. For example, if
you're committing every 5 minutes or so, then it's extremely easy to
just rewind to a prior point in your work (git reset --hard HEAD~n) if
you find yourself in a dead end. Likewise, if you find that you've done
a bad "git reset --hard" or a bad rebase you can just dig out the old
hash from "git reflog" and reset to that.

If you commit often, none of this will result in losing significant
amounts of work.

Regards,


From ivan.miljenovic at gmail.com  Sun Nov 15 07:06:29 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 15 Nov 2015 18:06:29 +1100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <n299cg$lu0$1@ger.gmane.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
Message-ID: <CA+u6gbx7t26TRwRjzm+xa_FatKqzseD=+3PApXVJkGgj4MbPRg@mail.gmail.com>

On 15 November 2015 at 17:40, Bardur Arantsson <spam at scientician.net> wrote:
> [1] If you're an emacs user: Use "magit" it's incredible. Maybe even
> worth learning emacs for.

Actually, I would argue that using magit is worth learning/using git for ;-)

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From jo at durchholz.org  Sun Nov 15 07:15:43 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Nov 2015 08:15:43 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
Message-ID: <5648311F.9060405@durchholz.org>

Am 14.11.2015 um 23:37 schrieb Mike Meyer:

(Aside: Please "reply to list", "reply to all" massages the headers in a 
way that my own "reply to list" does not work anymore. I don't need a 
personal copy anyway.)

> On Sat, Nov 14, 2015 at 2:52 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> Am 14.11.2015 um 21:10 schrieb Mike Meyer:
>>> Since we're talking about this, ones is the reasons I dislike for is that
>>> it treats the project history just like any other prolix public document,
>>> providing tools for modifying it, changing it as you push or pull, etc. I
>>> disagree with this, and prefer tools that believe that history should be
>>> immutable, like hg and fossil.
>> Just curious: Why?
>
> Philosophical. I want history to reflect the way things actually happened.

Things actually happen in the editors of contributors, which isn't 
committed. Not even all of what you write to disk is ever committed. So 
even without history rewrites, history does not reflect what actually 
heppened.
The only difference is that git allows you to version control your local 
scratchpad.

Also, philosophically, git never rewrites history; you create a new 
history and label it with an existing branch name.
(The original branch is not automatically preserved or shown, but it's 
still there; just give it a branch name, it's as easy as "git branch 
<archival-branch-name>" before working on the new history.)

>> So I think the difference is less relevant than most people think - but
>> then maybe I'm overlooking something, so what's your take?
>
> I'm not convinced that a rebase in lieu of a merge doesn't hide where bugs
> are introduced.

git history may be changed, but it cannot be made inconsistent.
So if the tip of a branch contains a bug, git enforces that the 
introduction of that bug is in the history, including proper attribution 
(unless somebody commited in lieu of somebody else, which is something 
that no SCM can prevent).

 > But that's minor to not wanting history hidden. I even had
> someone ask that I collapse a bunch of changes when I pushed them to my
> github repo before creating a PR. Not going to happen.

As Bardur wrote, it can make the history easier to review.
Which is important for reviews.

What's the original history significant for?
I haven't seen a use case for that. And philosophical or no, 
down-to-earth practial consequences beat philosophy any day. 
("Philosophy" typically indicates subconscious reasoning. Which can 
still be important, but unless you can bring them to conscious thinking 
and verbalize them, we won't know these reasons and cannot integrate 
them into our own thinking.)

Regards,
Jo

From fa-ml at ariis.it  Sun Nov 15 08:30:36 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 15 Nov 2015 09:30:36 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <n299cg$lu0$1@ger.gmane.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
Message-ID: <20151115083036.GA1412@casa.casa>

On Sun, Nov 15, 2015 at 07:40:16AM +0100, Bardur Arantsson wrote:
> "Patch theory" is all well and good, but it's missing the point, IMO.
> Tools *must* have a manual override for when the user knows best and
> that also means adapting to *my* workflow rather than me having to
> constantly think mind "should I commit now?", "which order do I need to
> do my refactoring in to get small reviewable commits?", etc. With git,
> it's very rare to have to think about this.

Fairly recently (v2.10.0) darcs introduced `suspend` and `unsuspend`,
when you want to modify stuff deep down in the repo (a patch that
depends on one or more other patches, etc. - see this blog post [1]).

I seldom use it as cherry-picking with darcs is easy, but those times
I was really glad to have had the option.

[1] https://parenz.wordpress.com/2015/07/28/darcs-rebase-by-example/

From fa-ml at ariis.it  Sun Nov 15 08:55:15 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Sun, 15 Nov 2015 09:55:15 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
Message-ID: <20151115085515.GA2744@casa.casa>

On Sat, Nov 14, 2015 at 08:10:47PM +0000, Mike Meyer wrote:
> Since we're talking about this, ones is the reasons I dislike for is that
> it treats the project history just like any other prolix public document,
> providing tools for modifying it, changing it as you push or pull, etc. I
> disagree with this, and prefer tools that believe that history should be
> immutable, like hg and fossil.
> 
> Which side, if either, of this does darcs land on?

darcs has some tools to "rebase". I would say they are seldom used in a
typical workflow (for sure less than what I saw in typical git usage),
but they are there.

From olshanskydr at gmail.com  Sun Nov 15 13:13:31 2015
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Sun, 15 Nov 2015 16:13:31 +0300
Subject: [Haskell-cafe] Type-level lazy bool operations
Message-ID: <CAHe9v2LUcDy0hRf-GH4XuHV46VMK3fSR782ZcMbV3ApKcVxoBA@mail.gmail.com>

Hello, cafe!

There are some type-level boolean operation (If, &&, ||, Not) in Data.Type.Bool.
Are they lazy enough?

I faced with problem and it seems that the reason is non-lazy "If".
I.e. both (on-True and on-False) types are trying to be calculated.
Does it work in this way really? Could it be changed?

Then, looking into source I see such definition for (&&)

-- | Type-level "and"
type family a && b where
  'False && a      = 'False
  'True  && a      = a
  a      && 'False = 'False
  a      && 'True  = a
  a      && a      = a

Why we need the last three rules? Does it mean that an order of type
calculation is totaly undefined?

Dmitry

From mwm at mired.org  Sun Nov 15 14:53:27 2015
From: mwm at mired.org (Mike Meyer)
Date: Sun, 15 Nov 2015 14:53:27 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <n299cg$lu0$1@ger.gmane.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
Message-ID: <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>

On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson <spam at scientician.net>
wrote:

> I tend to find that people who want to preserve what happened have a
> different way of working where they tend to try to create good commits
> as they go whereas I (post-git) just create a bunch of "WIP" commits
> for almost every change regardless of whether it compiles or not and
> then clean up the "history" for readability once the full change is
> ready for pushing to the world. I used to be in the former group, but
> have found that moving to the in the latter workflow is incredibly
> liberating. It means that I don't waste nearly as much time checking
> that everything compiles (etc.) for every little change I make. I just
> check all that stuff for the final series of commits.
>

Well, I want to preserve history but tend to commit whenever it's
convenient as well. This started when I moved to perforce - because
branches are cheap, so just create them whenever you need one,and make sure
what you merge compiles. So I branched whenever I thought a change would
take more than a single session - and finished with mercurial, where all
work happens on what's essentially a branch anyway, with push as merge.

I agree, it's critical to have a tool that adopts to your workflow, but
it's also important that other people don't break your workflow, because
like languages the claim of "if you don't like it, just don't use it" is
bullshit. So while mercurial has "rebase" so you can use it if you need it,
it's disabled by default and flagged as being for expert use, not something
that's part of the daily workflow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151115/57f9f27e/attachment.html>

From spam at scientician.net  Sun Nov 15 15:01:24 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sun, 15 Nov 2015 16:01:24 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
Message-ID: <n2a6o3$iai$1@ger.gmane.org>

On 11/15/2015 03:53 PM, Mike Meyer wrote:
> On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson <spam at scientician.net>
> wrote:
> 
> I agree, it's critical to have a tool that adopts to your workflow, but
> it's also important that other people don't break your workflow, because
> like languages the claim of "if you don't like it, just don't use it" is
> bullshit. So while mercurial has "rebase" so you can use it if you need it,
> it's disabled by default and flagged as being for expert use, not something
> that's part of the daily workflow.

I think I can the number of times my workflow has been "broken" by
others rebasing on approximately zero hands :).

It just isn't an issue in practice. (Maybe I've just been lucky, who knows?)

Regards,


From jo at durchholz.org  Sun Nov 15 15:46:16 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Nov 2015 16:46:16 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <n2a6o3$iai$1@ger.gmane.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org>
Message-ID: <5648A8C8.7070204@durchholz.org>

Am 15.11.2015 um 16:01 schrieb Bardur Arantsson:
> On 11/15/2015 03:53 PM, Mike Meyer wrote:
>> On Sun, Nov 15, 2015 at 12:40 AM Bardur Arantsson <spam at scientician.net>
>> wrote:
>>
>> I agree, it's critical to have a tool that adopts to your workflow, but
>> it's also important that other people don't break your workflow, because
>> like languages the claim of "if you don't like it, just don't use it" is
>> bullshit.

It's bullshit in a codebase.
Doesn't mean it's bullshit everywhere else. You'll need to name a 
concrete problem to drive that specific point home.

 >> So while mercurial has "rebase" so you can use it if you need it,
>> it's disabled by default and flagged as being for expert use, not something
>> that's part of the daily workflow.
>
> I think I can the number of times my workflow has been "broken" by
> others rebasing on approximately zero hands :).
>
> It just isn't an issue in practice. (Maybe I've just been lucky, who knows?)

I guess I was lucky, too :-)

It can affect code reviews. OTOH that's something that reviewer and 
submitter can agree to without affecting other people's work.

Regards,
Jo

From mwm at mired.org  Sun Nov 15 15:52:40 2015
From: mwm at mired.org (Mike Meyer)
Date: Sun, 15 Nov 2015 15:52:40 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <5648A8C8.7070204@durchholz.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
Message-ID: <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>

On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz <jo at durchholz.org> wrote:

> It can affect code reviews. OTOH that's something that reviewer and
> submitter can agree to without affecting other people's work.
>

If your review tools won't let you review changes in the format you prefer,
that's an issue with the review tools, not the version control system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151115/8650e68e/attachment.html>

From heraldhoi at gmail.com  Sun Nov 15 17:27:51 2015
From: heraldhoi at gmail.com (Geraldus)
Date: Sun, 15 Nov 2015 17:27:51 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
Message-ID: <CAB2YT57_-LjR5=5aCfDqvHgrAfSq7Q6jvrHMCXnww24ogQgNVA@mail.gmail.com>

Well, thank you all, pals!  I'll try darcs in near future.

As for me I try to make each commit to present a project's state which
compiles; I like when commit have a description with easy to follow diffs
(so all staged chages should be logically connected).  Sometimes I'm
squashing minor commits into larger one.

The worst disadvantage is that I got used to `magit` very much.  Is there
anyone who tried (or thought at least) to implement something similar for
Darcs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151115/b825997d/attachment.html>

From jo at durchholz.org  Sun Nov 15 17:50:25 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Nov 2015 18:50:25 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
Message-ID: <5648C5E1.604@durchholz.org>

Am 15.11.2015 um 16:52 schrieb Mike Meyer:
> On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> It can affect code reviews. OTOH that's something that reviewer and
>> submitter can agree to without affecting other people's work.
>
> If your review tools won't let you review changes in the format you prefer,
> that's an issue with the review tools, not the version control system.

Did you ever work with git, or any SCM that allows history edits?

Because that wasn't a question of review tools at all, and while I can 
understand the discomfort around editing history, it is not something 
that one can reliably judge from hearsay and theory, you need to have 
seen it in action.

Regards,
Jo

From mwm at mired.org  Sun Nov 15 17:54:48 2015
From: mwm at mired.org (Mike Meyer)
Date: Sun, 15 Nov 2015 17:54:48 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <5648C5E1.604@durchholz.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
Message-ID: <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>

Yes, I work with git on a regular basis. I'm not likely to have been asked
to compress my commits if I hadn't done so.

You talked about issues during a code review. I've never seen a review
process that was really affected by the source code control system. There
review tools, on the other hand, are sorry of crucial to them.

On Sun, Nov 15, 2015, 11:50 Joachim Durchholz <jo at durchholz.org> wrote:

> Am 15.11.2015 um 16:52 schrieb Mike Meyer:
> > On Sun, Nov 15, 2015 at 9:46 AM Joachim Durchholz <jo at durchholz.org>
> wrote:
> >
> >> It can affect code reviews. OTOH that's something that reviewer and
> >> submitter can agree to without affecting other people's work.
> >
> > If your review tools won't let you review changes in the format you
> prefer,
> > that's an issue with the review tools, not the version control system.
>
> Did you ever work with git, or any SCM that allows history edits?
>
> Because that wasn't a question of review tools at all, and while I can
> understand the discomfort around editing history, it is not something
> that one can reliably judge from hearsay and theory, you need to have
> seen it in action.
>
> Regards,
> Jo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151115/ee0e113a/attachment.html>

From jo at durchholz.org  Sun Nov 15 18:09:54 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 15 Nov 2015 19:09:54 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
Message-ID: <5648CA72.4070606@durchholz.org>

Am 15.11.2015 um 18:54 schrieb Mike Meyer:
> Yes, I work with git on a regular basis. I'm not likely to have been asked
> to compress my commits if I hadn't done so.

Oh. Right. My apologies.

> You talked about issues during a code review. I've never seen a review
> process that was really affected by the source code control system.

If a history rewrite is tacked on at the end of a review process, that 
means another round of review.
I agree that the SCM tool and the way it's being used wouldn't affect 
individual reviews, it's the overall process that can be affected (you 
could avoid that by doing the history rewrite as early as possible, 
preferrably before starting formal review if the project has that).

From hjgtuyl at chello.nl  Sun Nov 15 19:14:51 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Sun, 15 Nov 2015 20:14:51 +0100
Subject: [Haskell-cafe] wxHaskell can now be run multiple times in GHCi
Message-ID: <op.x75o25rhpz0j5l@alquantor>


L.S.,

Good news for people who want to develop wxHaskell programs by  
experimenting in GHCi:
wxHaskell programs can now be run multiple times in GHCi (GHC 7.10.2, 32  
bit).

Running a wxHaskell program in the 64 bit version of the interpreter  
results in the message:
   addDLL: could not load DLL
This is caused by a GHC bug and is reported in GHC bug ticket 3242 [0], it  
should be solved in GHC 8.0.1

(The 32 bit GHCi crashes when exited, after running a wxHaskell program,  
but this is not a problem for application developers.)

Regards,
Henk-Jan van Tuyl


[0] https://ghc.haskell.org/trac/ghc/ticket/3242


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From ivan.miljenovic at gmail.com  Sun Nov 15 20:57:19 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Mon, 16 Nov 2015 07:57:19 +1100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAB2YT57_-LjR5=5aCfDqvHgrAfSq7Q6jvrHMCXnww24ogQgNVA@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <CAB2YT57_-LjR5=5aCfDqvHgrAfSq7Q6jvrHMCXnww24ogQgNVA@mail.gmail.com>
Message-ID: <CA+u6gbxKZDzcvLMmE2321EESuR48f3+rC2rdkFAY8thM5Yy-Kw@mail.gmail.com>

On 16 November 2015 at 04:27, Geraldus <heraldhoi at gmail.com> wrote:
> Well, thank you all, pals!  I'll try darcs in near future.
>
> As for me I try to make each commit to present a project's state which
> compiles; I like when commit have a description with easy to follow diffs
> (so all staged chages should be logically connected).  Sometimes I'm
> squashing minor commits into larger one.
>
> The worst disadvantage is that I got used to `magit` very much.  Is there
> anyone who tried (or thought at least) to implement something similar for
> Darcs?

There's darcsum, which gives you the interactive hunk selection for
creating a patch.  But it doesn't have the ability to push/pull inside
of Emacs, so you still need a terminal open for that.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From trebla at vex.net  Mon Nov 16 00:06:19 2015
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sun, 15 Nov 2015 19:06:19 -0500
Subject: [Haskell-cafe] The last decade: what has changed,
 was has stayed the same?
In-Reply-To: <56463D68.6020600@durchholz.org>
References: <56463D68.6020600@durchholz.org>
Message-ID: <56491DFB.9010104@vex.net>

On 2015-11-13 02:43 PM, Joachim Durchholz wrote:
> After learning the bare language, how long does it take a competent 
> programmer to become confident in the performance of his Haskell code?
>
> After learning the bare language, how long does it take a competent 
> programmer to know when and when not to use strictness 
> annotations/operators?

These two questions unify into one; choosing the right strictness is 
part of making an efficient program.

Confidence is a treacherous end; by the Dunning-Kruger effect, it only 
takes a month for one to be fully confident and totally wrong. (Under 
one week if the person has been competent in past things so they think 
they're infallible in all future things.)

It is more objective and productive to ask: how long does it take to be 
measurably successful?

I think it took me five years. But it was a hobbyist, intermittent, 
on-and-off kind of five years; my day job was procrastinating my PhD 
thesis and teaching formal methods in the imperative setting. (Then 
again, does anyone learn Haskell full-time?)

It was also an unaided kind of five years. (I learned much of the 
Core->Cmm->asm translation by brute-force experimentation. It was uphill 
both ways.) The following aids are available now but not back then. If 
you start today, it may take you less time and puzzlement:

http://www.vex.net/~trebla/haskell/lazy.xhtml  (I wrote it after I 
really figured out lazy evaluation, so of course it didn't exist when I 
was learning)
https://hackhands.com/guide-lazy-evaluation-haskell/
https://github.com/takenobu-hs/haskell-ghc-illustrated

> I'm seeing a lot of typesystem golf happening.
> Is this teachable to the average competent programmer?
> Is it relevant to everyday programming such as business logic, 
> database access, or webpage generation? (If no, for what programming 
> endeavours is it relevant?)

I am not fond of most of their advanced type-level games which are 
far-fetched encodings of dependent types in a non-dependent type system. 
They remind me of how I felt enlightened for five minutes when I first 
realized how to simulate malloc and free in BASIC. It lasted for only 
five minutes because it was false enlightenment. The true enlightenment 
should be: This is why you ditch BASIC for Pascal or C.

But a very elementary use of GADTs and phantom types improves safety of 
databasee access a lot.

At a low level, of course you still have the very unsafe and very vulnerable

raw_query :: ByteString -> IO [[ByteString]]
-- I omit a Connection parameter for this sketch
-- also perhaps it should be IO (Either SQLError [[ByteString]])

But you can say you don't use it directly; you use a safer, higher level 
wrapper, less vulnerable to type errors.

The higher level can go like this:

{-# LANGUAGE GADTs #-}

import Data.ByteString (ByteString)
import qualified Data.ByteString.Char8 as B
-- Apology: Char8 interface for SQL syntax and column names only.
-- Not going to inflict this on all data.

data Selectee a where
     Column :: ByteString -> Selectee a
     Plus :: Selectee Int -> Selectee Int -> Selectee Int
     Len :: Selectee ByteString -> Selectee Int

name_column, email_column :: Selectee ByteString

name_column = Column (B.pack "name")
email_column = Column (B.pack "email")

concretize :: Selectee a -> ByteString
concretize (Column c) = c
concretize (Len e) = B.concat [B.pack "len(", concretize e, B.pack ")"]
concretize (Plus e1 e2) = B.concat [B.pack "(", concretize e1, B.pack 
")+(", concretize e2, B.pack ")"]

-- select1 is a select with single-column answer
-- It's single-column, and I hardcode the table name, for this sketch.
select1 :: SQLtype a => Selectee a -> IO [a]
select1 s = do
     map (sqlread . head) <$> raw_query query
   where
     query = B.concat [B.pack "select ", concretize s, B.pack " from 
addressbook"]

class SQLtype a where
     sqlread :: ByteString -> a

instance SQLtype Int where
     sqlread s = case B.readInt s of Just (n, _) -> n

example = select1 (Len name_column `Plus` Len email_column)
-- select len(name)+len(email) from addressbook


From eir at cis.upenn.edu  Mon Nov 16 00:32:30 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 15 Nov 2015 19:32:30 -0500
Subject: [Haskell-cafe] Type-level lazy bool operations
In-Reply-To: <CAHe9v2LUcDy0hRf-GH4XuHV46VMK3fSR782ZcMbV3ApKcVxoBA@mail.gmail.com>
References: <CAHe9v2LUcDy0hRf-GH4XuHV46VMK3fSR782ZcMbV3ApKcVxoBA@mail.gmail.com>
Message-ID: <0E8C14F3-F5E6-4A10-862F-1EE0D5501C79@cis.upenn.edu>

GHC offers no well-defined semantics for type-level reduction. In other words, "yes" to your last question: the order of type-level reduction is totally undefined and arbitrary. Right now, it's basically whatever GHC thinks might be the most efficient way to fully reduce a type. This should probably be cleaned up at some point, but probably not in the very near future. That said, there are hacks that can be used to increase laziness in types. If you have a test case where `If` is behaving too strictly, post a bug report, and I'll see what I can do.

As for &&, the extra rules are to allow more reductions than the first two, alone, would yield. For example, we know that (a && False) should reduce to False, no matter what `a` is. For example, the type (forall a. Proxy a -> Proxy (a && False)) is equal to (forall a. Proxy a -> False). Without that third equation, this fact would not be true. The fourth and fifth equations are similar.

I hope this is helpful!

Richard

On Nov 15, 2015, at 8:13 AM, Dmitry Olshansky <olshanskydr at gmail.com> wrote:

> Hello, cafe!
> 
> There are some type-level boolean operation (If, &&, ||, Not) in Data.Type.Bool.
> Are they lazy enough?
> 
> I faced with problem and it seems that the reason is non-lazy "If".
> I.e. both (on-True and on-False) types are trying to be calculated.
> Does it work in this way really? Could it be changed?
> 
> Then, looking into source I see such definition for (&&)
> 
> -- | Type-level "and"
> type family a && b where
>  'False && a      = 'False
>  'True  && a      = a
>  a      && 'False = 'False
>  a      && 'True  = a
>  a      && a      = a
> 
> Why we need the last three rules? Does it mean that an order of type
> calculation is totaly undefined?
> 
> Dmitry
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


From jo at durchholz.org  Mon Nov 16 07:58:56 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 16 Nov 2015 08:58:56 +0100
Subject: [Haskell-cafe] The last decade: what has changed,
 was has stayed the same?
In-Reply-To: <56491DFB.9010104@vex.net>
References: <56463D68.6020600@durchholz.org> <56491DFB.9010104@vex.net>
Message-ID: <56498CC0.4060008@durchholz.org>

Thanks Albert!

Am 16.11.2015 um 01:06 schrieb Albert Y. C. Lai:
> On 2015-11-13 02:43 PM, Joachim Durchholz wrote:
>> After learning the bare language, how long does it take a competent
>> programmer to become confident in the performance of his Haskell code?
>>
>> After learning the bare language, how long does it take a competent
>> programmer to know when and when not to use strictness
>> annotations/operators?
>
> These two questions unify into one; choosing the right strictness is
> part of making an efficient program.

I meant the first question to be "how well can I predict the performance 
of my code".

The second question was "if performance is insufficient, how well can 
people wield the tool that they have for it".
If the optimizer is good enough, the second question would rarely matter 
enough.

> Confidence is a treacherous end; by the Dunning-Kruger effect, it only
> takes a month for one to be fully confident and totally wrong. (Under
> one week if the person has been competent in past things so they think
> they're infallible in all future things.)

Oh, a competent programmer can see whether he's under Dunning-Kruger or 
not: If haskell-cafe is talking about issues and problems he hasn't seen 
yet, he isn't good enough yet. That's easy enough if you're training to 
watch out for these things.

> It is more objective and productive to ask: how long does it take to be
> measurably successful?

That's a bit too open-ended because everybody's definition of "success" 
varies. Some people feel successful if their code compiles, others feel 
successful only if they can control cache locality across asymmetric MP 
cores.

It's still an interesting question.

> The following aids are available now but not back then. If
> you start today, it may take you less time and puzzlement:
>
> http://www.vex.net/~trebla/haskell/lazy.xhtml  (I wrote it after I
> really figured out lazy evaluation, so of course it didn't exist when I
> was learning)
> https://hackhands.com/guide-lazy-evaluation-haskell/
> https://github.com/takenobu-hs/haskell-ghc-illustrated

I'll take a look at these. I'm a bit sceptical that I'll be able to 
become competent just by reading them though :-)

>> I'm seeing a lot of typesystem golf happening.
>> Is this teachable to the average competent programmer?
>> Is it relevant to everyday programming such as business logic,
>> database access, or webpage generation? (If no, for what programming
>> endeavours is it relevant?)
>
> I am not fond of most of their advanced type-level games which are
> far-fetched encodings of dependent types in a non-dependent type system.
> They remind me of how I felt enlightened for five minutes when I first
> realized how to simulate malloc and free in BASIC. It lasted for only
> five minutes because it was false enlightenment. The true enlightenment
> should be: This is why you ditch BASIC for Pascal or C.

Heh. I can understand that sentiment. My knee-jerk reaction to the first 
experiments (encoding integers in the type system to get stuff like 
square matrices typed) was "gee, we should really unify all this stuff 
in general assertions about types&values and have the compiler check 
these as far as possible!" (Unfortunately, that would not be Haskell 
anymore.)

Still, not being competent with Haskell in any way, I need to listen to 
divergent views. (I regret having written "typesystem golf", it can be 
seen as derogatory and shapes the answers.)

> But a very elementary use of GADTs and phantom types improves safety of
> databasee access a lot.

Yeah, that's really important. I'm pretty much in the same boat with you 
on that issue; the usefulness of a type system trick (or any language 
trick) needs to be multiplied by the percentage of people able to 
understand and use it in practice.

> At a low level, of course you still have the very unsafe and very
> vulnerable
>
> raw_query :: ByteString -> IO [[ByteString]]
> -- I omit a Connection parameter for this sketch
> -- also perhaps it should be IO (Either SQLError [[ByteString]])

You can also have warnings. Or errors AND a result.
(I happen to know that after half a decade of doing Oracle via JDBC.)

> But you can say you don't use it directly; you use a safer, higher level
> wrapper, less vulnerable to type errors.

Everybody is doing that :-)
Including the Java guys.

Some of the Java guys are even doing pretty declarative designs even if 
imperative. Try a look at Jooq, it's built to deal with database 
incompatibilities AND be easy to use: http://jooq.org/
(Disclaimer: It was on my shortlist once, but never made it into 
production use for me, so I don't know how well the approach holds up in 
real use.)

Thanks!
Jo

(Hope somebody takes the time to look at the other aspects of the 
question...)

From malcolm.wallace at me.com  Mon Nov 16 10:40:46 2015
From: malcolm.wallace at me.com (malcolm.wallace)
Date: Mon, 16 Nov 2015 10:40:46 +0000 (GMT)
Subject: [Haskell-cafe] haskell-src-exts maintenance
Message-ID: <c5afd10e-3e2a-4474-a9f8-b5b335240ba6@me.com>

We too have been waiting a long time for a refreshed release of HSE. ?If Matthew has already made the?edits, and we are?simply awaiting the package's release to Hackage, perhaps Matthew should go ahead make that release himself, and petition the Hackage admins?to accept it, in view?of the official maintainers' long silence?
Regards,
    Malcolm

On 12 Nov, 2015,at 05:37 PM, Matthew Pickering <matthewtpickering at gmail.com> wrote:

Peter,

Please can you do the release. I completed the work updating HSE
several months ago, a much better version of HSE has been waiting on
the master branch since then. I thank you for providing helpful review
for the patches I submitted but since then I have sent three emails
asking about the release. After the second you promised to do a
release at the end of October but that never happened.

It is a shame that the user's of HSE have had to live with many long
standing bugs when they have been fixed for months.

If you can not do it for whatever reason then please can you add me as
a maintainer on hackage and the github repo so that users can get an
updated version of HSE.

Best wishes,

Matt



On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson
<jonsson.peter.a at gmail.com> wrote:
I?m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole.

I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn?t follow up on that so there was probably some miscommunication between the two of us.

I?ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don?t want to rush things out through the door at any cost though?I believe HSE?s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released.

Best Wishes,

Peter

On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell at gmail.com> wrote:

As a very heavy HSE user (HLint and Hoogle), who has had a reasonably
close working relationship with all of Niklas (my SoC mentor and my
SoC mentee), Roman and Peter (a fellow supercompiler developer) and
Matt (currently hacking on HLint), I thought I should weigh in.

The current state of HSE is a little forlorn - there are 22 open pull
requests, everything from reducing algorithm complexity (an accidental
n^3), fixing the default encoding (should be UTF8) and lots of actual
parser fixes. A lot of this is good stuff, and the high level of
external contributions is a really good sign. But they need to be
merged and reviewed, and it seems the bandwidth just isn't there at
the moment. Given Matt's comments on the existing tickets, and the
triage he's already performing on the repo, I have high hopes that
Matt could provide a bit more of the time and attention. Peter,
perhaps a co-maintainer would be good for a little while?

If it's not soon then please could you add myself and Christian to the
maintainers so that we can perform some short term maintenance. My
immediate plan of action would be

1. Immediately cut a 1.17 release from the master branch as it
contains much better parsing of lifted constructors which are becoming
more prevalent.
2. Review and merge recent pull requests.
3. Update the parser as far as possible with missing features.
4. Release 1.18 with these improvements within 1 month.

Awesome! Although as a preference I'd go for as much of 2 as you can
in a couple of days before doing 1 - a lot of the patches are simple
and valuable, and a 2 day wait isn't going to be too problematic.

Thanks, Neil

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/f7de09db/attachment.html>

From alexander at plaimi.net  Mon Nov 16 10:55:46 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Mon, 16 Nov 2015 11:55:46 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
Message-ID: <5649B632.6000009@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Pertaining to darcs: is there a nice way to verify integrity yet? In
git you can OpenPGP sign commits and tags.

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJWSbYxAAoJENQqWdRUGk8B2hwQANwgvk66ku+lV2K1qKxLpQ4o
LB6SBgbMSmH75pzfXUQ6+FDyx+1169vOgScmhi5nyOCii1BEHab3lUOr6fzKvq5H
Ph4azgm1I7tmjEBcmdoVqoNhpKDiCJC+2nf7s3VoSjWJ392+7W9F7UuQ/Ze6pLLu
uX6Hwdors7+zGvmxN5YEL20Mr5BXOrkdvJV+eiyM0WmWEcftCDyrTfyysQ8sjM+K
P2SPIxdawwJ3lN14rvcgtGDk0Wd8aJrPxJNPKcttDBCeICzNsKPriaMSqHGWzvZi
3L3iEi49iwchC5AVKA+syKzPiT8OAlSb3TK2O+6ajfuzefghX8490cuHF0YxE6ks
ZDY6GMB0NiUkvQOzoUfAu1Fu0voNLSruY1WJf/2KpAfWz0LYvCjiwCjing2L2IMV
PnKWzgw9zuPTm0sh9KxRHOGNHxjyHW5HR58dsyaLrD+Sy9U6LGjcdVDXkrzl4CxK
+0n2qq9btqdRdw0Dk3//mjO4yTlfWhEnMarSp4MvawvG4TY/gik+ueTtJZnGrWKW
jSJ/b7Ck6EkOHDYLl8O11I6MjjxapcJ2kMm0ENxiUflhV24/JVH1+cUyCyq0UnfH
KwNiqhGjCApGiTndJKrUybLRSxy16iHygivbHPoRZqNHVkcMwrmcmswW1K7AqzPp
WfN5oapy2xCUQQ/MMGrf
=dwOz
-----END PGP SIGNATURE-----

From roma at ro-che.info  Mon Nov 16 10:56:31 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 16 Nov 2015 12:56:31 +0200
Subject: [Haskell-cafe] haskell-src-exts maintenance
In-Reply-To: <c5afd10e-3e2a-4474-a9f8-b5b335240ba6@me.com>
References: <c5afd10e-3e2a-4474-a9f8-b5b335240ba6@me.com>
Message-ID: <5649B65F.4080808@ro-che.info>

I just added Matthew as a maintainer on hackage and github (with Peter's
approval), so he is now able to make the release.

On 11/16/2015 12:40 PM, malcolm.wallace wrote:
> We too have been waiting a long time for a refreshed release of HSE.  If
> Matthew has already made the edits, and we are simply awaiting the
> package's release to Hackage, perhaps Matthew should go ahead make that
> release himself, and petition the Hackage admins to accept it, in
> view of the official maintainers' long silence?
> 
> Regards,
>     Malcolm
> 
> 
> On 12 Nov, 2015,at 05:37 PM, Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
> 
>> Peter,
>>
>> Please can you do the release. I completed the work updating HSE
>> several months ago, a much better version of HSE has been waiting on
>> the master branch since then. I thank you for providing helpful review
>> for the patches I submitted but since then I have sent three emails
>> asking about the release. After the second you promised to do a
>> release at the end of October but that never happened.
>>
>> It is a shame that the user's of HSE have had to live with many long
>> standing bugs when they have been fixed for months.
>>
>> If you can not do it for whatever reason then please can you add me as
>> a maintainer on hackage and the github repo so that users can get an
>> updated version of HSE.
>>
>> Best wishes,
>>
>> Matt
>>
>>
>>
>> On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson
>> <jonsson.peter.a at gmail.com> wrote:
>>> I?m not even going to bother to CC haskell-cafe since that will just
>>> bounce or go into a black hole.
>>>
>>> I exchanged a couple of mails with David (Lemmih) and my impression
>>> was that he was going to act upon some things but I didn?t follow up
>>> on that so there was probably some miscommunication between the two
>>> of us.
>>>
>>> I?ve merged some things and reviewed some patches. I agree with Neil
>>> that stable things should be merged and the yearly release of HSE
>>> should be made. I don?t want to rush things out through the door at
>>> any cost though?I believe HSE?s users are better served by something
>>> that is a strict improvement and contains more features than the last
>>> release compared to something that has even more features but is a
>>> bit shaky and requires a new major version of HSE in just a month or
>>> two which would force the client code to be re-tested and re-released.
>>>
>>> Best Wishes,
>>>
>>> Peter
>>>
>>>> On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell at gmail.com> wrote:
>>>>
>>>> As a very heavy HSE user (HLint and Hoogle), who has had a reasonably
>>>> close working relationship with all of Niklas (my SoC mentor and my
>>>> SoC mentee), Roman and Peter (a fellow supercompiler developer) and
>>>> Matt (currently hacking on HLint), I thought I should weigh in.
>>>>
>>>> The current state of HSE is a little forlorn - there are 22 open pull
>>>> requests, everything from reducing algorithm complexity (an accidental
>>>> n^3), fixing the default encoding (should be UTF8) and lots of actual
>>>> parser fixes. A lot of this is good stuff, and the high level of
>>>> external contributions is a really good sign. But they need to be
>>>> merged and reviewed, and it seems the bandwidth just isn't there at
>>>> the moment. Given Matt's comments on the existing tickets, and the
>>>> triage he's already performing on the repo, I have high hopes that
>>>> Matt could provide a bit more of the time and attention. Peter,
>>>> perhaps a co-maintainer would be good for a little while?
>>>>
>>>>> If it's not soon then please could you add myself and Christian to the
>>>>> maintainers so that we can perform some short term maintenance. My
>>>>> immediate plan of action would be
>>>>>
>>>>> 1. Immediately cut a 1.17 release from the master branch as it
>>>>> contains much better parsing of lifted constructors which are becoming
>>>>> more prevalent.
>>>>> 2. Review and merge recent pull requests.
>>>>> 3. Update the parser as far as possible with missing features.
>>>>> 4. Release 1.18 with these improvements within 1 month.
>>>>
>>>> Awesome! Although as a preference I'd go for as much of 2 as you can
>>>> in a couple of days before doing 1 - a lot of the patches are simple
>>>> and valuable, and a 2 day wait isn't going to be too problematic.
>>>>
>>>> Thanks, Neil
>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/47bf5b00/attachment.sig>

From johannes.waldmann at htwk-leipzig.de  Mon Nov 16 11:38:02 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 16 Nov 2015 12:38:02 +0100
Subject: [Haskell-cafe] model checking for (subset of) concurrent Haskell?
Message-ID: <5649C01A.3010903@htwk-leipzig.de>

For model checking concurrent and distributed imperative programs,
there's the Promela language, and the Spin model checker
( http://spinroot.com ) than can explore/enumerate
a finite state space of a system and decide validity of LTL formulae.

Is there something similar for Haskell models of concurrency?
Ideally, some subset of Haskell (containing enough of
Control.Concurrent.*) as an alternative for Promela.

It should even be possible to put the model checking
in an alternative implementation of respective monad
(STM, IO for MVars) so the whole thing is an embedded DSL.

somewhat related: this project is about a verified model checker:
https://cava.in.tum.de/ (ML code generated from Isabelle)
but my interest is in model-checking concurrent programs
in functional notation.

- J.W.

From mike at barrucadu.co.uk  Mon Nov 16 12:33:12 2015
From: mike at barrucadu.co.uk (Michael Walker)
Date: Mon, 16 Nov 2015 12:33:12 +0000
Subject: [Haskell-cafe] model checking for (subset of) concurrent
	Haskell?
In-Reply-To: <5649C01A.3010903@htwk-leipzig.de>
References: <5649C01A.3010903@htwk-leipzig.de>
Message-ID: <CAOOzCW6JZVgjSTNDjEr0dwLdbvOKXwUoUrfOkjjYf2A9Y+G_fA@mail.gmail.com>

Hi Johannes,

I released an initial version of a tool for the systematic testing of
concurrent Haskell programs a couple of months ago[1]. I've never been
quite certain where the boundary between model checking and testing
is, but I think it's fair to say that what I've got is a bounded model
checker.

I presented a paper on it at the Haskell Symposium this year[2][3],
but since then it has been improved significantly, both in terms of
the concurrency features supported, and performance. The version on
Hackage is very outdated now, but I hope to get a new release out
reasonably soon.

> Is there something similar for Haskell models of concurrency?
> Ideally, some subset of Haskell (containing enough of
> Control.Concurrent.*) as an alternative for Promela.

I didn't go for LTL, rather a more unit test-like approach[4] where
you examine the final output of the program.

> It should even be possible to put the model checking
> in an alternative implementation of respective monad
> (STM, IO for MVars) so the whole thing is an embedded DSL.

My approach is based on a typeclass abstraction, with a class for
concurrency[5] and a class for STM[6]. Naturally, this means you can
just write some Haskell polymorphic in the monad but constrained by
the class, and then either run it "for real" using IO or STM, or test
it using the testing instances.

The current developmental version is on GitHub[7], and I'm writing up
a technical report on it (draft online[8]).

[1] https://hackage.haskell.org/package/dejafu
[2] http://www.barrucadu.co.uk/publications/dejafu-hs15.pdf
[3] https://youtu.be/jQCDa6WoFeY?list=PLnqUlCo055hV5dPC-4VWeXzhI8ooeTsVy
[4] http://barrucadu.github.io/dejafu/Test-DejaFu.html
[5] http://barrucadu.github.io/dejafu/Control-Monad-Conc-Class.html
[6] http://barrucadu.github.io/dejafu/Control-Monad-STM-Class.html
[7] https://github.com/barrucadu/dejafu
[8] http://misc.barrucadu.co.uk/pub/techreport.pdf

-- 
Michael Walker (http://www.barrucadu.co.uk)

From sean at functionaljobs.com  Mon Nov 16 17:00:01 2015
From: sean at functionaljobs.com (Functional Jobs)
Date: Mon, 16 Nov 2015 12:00:01 -0500
Subject: [Haskell-cafe] New Functional Programming Job Opportunities
Message-ID: <564a0bc3ea025@functionaljobs.com>

Here are some functional programming job opportunities that were posted
recently:

Haskell Developer (ON SITE) at CJ Affiliate by Conversant
https://functionaljobs.com/jobs/8867-haskell-developer-on-site-at-cj-affiliate-by-conversant

Software Engineer - Functional Programmer - Erlang at Change Healthcare
https://functionaljobs.com/jobs/8866-software-engineer-functional-programmer-erlang-at-change-healthcare

Cheers,
Sean Murphy
FunctionalJobs.com


From simon at joyful.com  Mon Nov 16 17:24:48 2015
From: simon at joyful.com (Simon Michael)
Date: Mon, 16 Nov 2015 09:24:48 -0800
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CA+u6gbxKZDzcvLMmE2321EESuR48f3+rC2rdkFAY8thM5Yy-Kw@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <CAB2YT57_-LjR5=5aCfDqvHgrAfSq7Q6jvrHMCXnww24ogQgNVA@mail.gmail.com>
 <CA+u6gbxKZDzcvLMmE2321EESuR48f3+rC2rdkFAY8thM5Yy-Kw@mail.gmail.com>
Message-ID: <n2d3h1$4ca$1@ger.gmane.org>

On 11/15/15 12:57 PM, Ivan Lazar Miljenovic wrote:
> On 16 November 2015 at 04:27, Geraldus <heraldhoi at gmail.com> wrote:
>> The worst disadvantage is that I got used to `magit` very much.  Is there
>> anyone who tried (or thought at least) to implement something similar for
>> Darcs?
> 
> There's darcsum, which gives you the interactive hunk selection for
> creating a patch.  But it doesn't have the ability to push/pull inside
> of Emacs, so you still need a terminal open for that.

It should be a very easy thing to add. darcsum needs a
maintainer/developer, contact me if you're interested.


From mwm at mired.org  Mon Nov 16 17:36:32 2015
From: mwm at mired.org (Mike Meyer)
Date: Mon, 16 Nov 2015 17:36:32 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <5648CA72.4070606@durchholz.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
 <5648CA72.4070606@durchholz.org>
Message-ID: <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>

On Sun, Nov 15, 2015 at 12:10 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Am 15.11.2015 um 18:54 schrieb Mike Meyer:
>


> > You talked about issues during a code review. I've never seen a review
> > process that was really affected by the source code control system.
>
> If a history rewrite is tacked on at the end of a review process, that
> means another round of review.
> I agree that the SCM tool and the way it's being used wouldn't affect
> individual reviews, it's the overall process that can be affected (you
> could avoid that by doing the history rewrite as early as possible,
> preferrably before starting formal review if the project has that).
>

Um, I don't see how choice of a DVCS affects when you do history rewrites.
Yes, the DVCS can make them harder if it doesn't support them, but that's
case of picking a tool that doesn't support your workflow, which I think we
all agree is a bad idea.

And you saying history rewrites trigger another round of code reviews just
reinforces my worries that such rewrites might be quietly introducing
issues that need to be worried about, and hence the best way to avoid that
extra round of reviews is to not do history rewrites.

Like I said originally, this is a philosophy issue: do you believe the
point of the code review is to preserve history as it actually happened, or
as you wish it had happened? Your repository is yours, and I don't have
issues with you using it for whatever you want to - you're a step ahead of
a lot of places in that you have one at all! It's when you start wanting to
change the way I use mine - by, for instance, asking me to edit it's
history on a pull request instead of doing it when you merge the request -
that I have issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/30bacda9/attachment.html>

From jo at durchholz.org  Mon Nov 16 18:10:56 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 16 Nov 2015 19:10:56 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
 <5648CA72.4070606@durchholz.org>
 <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>
Message-ID: <564A1C30.5060900@durchholz.org>

Am 16.11.2015 um 18:36 schrieb Mike Meyer:
> On Sun, Nov 15, 2015 at 12:10 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> Am 15.11.2015 um 18:54 schrieb Mike Meyer:
>>
>
>
>>> You talked about issues during a code review. I've never seen a review
>>> process that was really affected by the source code control system.
>>
>> If a history rewrite is tacked on at the end of a review process, that
>> means another round of review.
>> I agree that the SCM tool and the way it's being used wouldn't affect
>> individual reviews, it's the overall process that can be affected (you
>> could avoid that by doing the history rewrite as early as possible,
>> preferrably before starting formal review if the project has that).
>
> Um, I don't see how choice of a DVCS affects when you do history rewrites.

Oh, they do. Some SCMs are written with a specific workflow in mind and 
will become difficult if you use a different one; SVN is a case in 
point, I hear Mercurial is geared towards specific workflows, too, but 
then that's just hearsay.
Others allow many different workflows and you choose. The above 
paragraph was about what choices you have with git.

> And you saying history rewrites trigger another round of code reviews just
> reinforces my worries that such rewrites might be quietly introducing
> issues that need to be worried about, and hence the best way to avoid that
> extra round of reviews is to not do history rewrites.

You didn't see the alternative of doing history rewrites just locally, 
before the patch hits any official repo.

> Like I said originally, this is a philosophy issue: do you believe the
> point of the code review is to preserve history as it actually happened, or
> as you wish it had happened?

False alternatives.

It's not about history, it's about a log of changes. Which changes - 
that's the project's choice, it could be fully history of everything or 
it could be a carefully crafted change log that serves entirely 
different purposes than recording history.

I still do not understand why you think that history outweighs all other 
considerations.

 > Your repository is yours, and I don't have
> issues with you using it for whatever you want to - you're a step ahead of
> a lot of places in that you have one at all! It's when you start wanting to
> change the way I use mine - by, for instance, asking me to edit it's
> history on a pull request instead of doing it when you merge the request -
> that I have issues.

*shrug* if it's your project, it's your decision.
If you're contributing to somebody else's project, it's their decision 
whether they want to accept the full history, including fixup commits 
and intermingled parallel work, or whether they want small, 
topic-centered commits that have been pulled together from the local, 
historic stream of workspace commits.

I haven't seen you argue what purpose a full history might actually 
have, so I still can't say what value you see in the "full history" 
approach, but ah well - sometimes it's hard to verbalize such feelings, 
so I'm not going to insist on an explanation.
I just hope that you can accept that other people greatly prefer a log 
which has been geared towards better reviewability. After all, we can't 
simply adopt your view just because it's "philosophy" - philosophy can 
help to validate and verify that a given workflow does what it's 
supposed to, but philosophy cannot define goals and desirables.

Regards,
Jo

From mwm at mired.org  Mon Nov 16 18:32:39 2015
From: mwm at mired.org (Mike Meyer)
Date: Mon, 16 Nov 2015 18:32:39 +0000
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <564A1C30.5060900@durchholz.org>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
 <5648CA72.4070606@durchholz.org>
 <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>
 <564A1C30.5060900@durchholz.org>
Message-ID: <CAD=7U2A1OtCsBHQ92EKmuYnoJ5yetsMoq96YimMv1z5xVt4btQ@mail.gmail.com>

On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz <jo at durchholz.org> wrote:

> Am 16.11.2015 um 18:36 schrieb Mike Meyer:
> I haven't seen you argue what purpose a full history might actually
> have, so I still can't say what value you see in the "full history"
> approach, but ah well - sometimes it's hard to verbalize such feelings,
>

Accuracy. Having watched the soviets change their history texts with each
regime, it bothers me to see history changed. If people actually read
and/or otherwise examined these "carefully crafted change logs" on a
regular basis, I might feel otherwise. But I never look at them unless I'm
chasing a bug, and as far as I can tell, nobody else does either. So
spending time editing history is not only mostly wasted effort, it may well
cause problems for the only use. I don't have any actual proof that this is
the case, but I haven't seen any for any other position, either. If you've
got it, I'd certainly be interested in reading it.


> I just hope that you can accept that other people greatly prefer a log
> which has been geared towards better reviewability.
>

Oh, I don't have a problem doing that. But I expect the same courtesy in
return. In particular, If I choose to donate my work to your project,
you'll not ask me to change my clone of your repo to meet your
expectations, but modify the change log as you pull it to meet your
standards. If that's a hoop you insist contributors jump through, that's
cool. I'll stop submitting them. It's not like I lack things to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/d8d06dbb/attachment.html>

From jo at durchholz.org  Mon Nov 16 19:24:23 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 16 Nov 2015 20:24:23 +0100
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2A1OtCsBHQ92EKmuYnoJ5yetsMoq96YimMv1z5xVt4btQ@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
 <5648CA72.4070606@durchholz.org>
 <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>
 <564A1C30.5060900@durchholz.org>
 <CAD=7U2A1OtCsBHQ92EKmuYnoJ5yetsMoq96YimMv1z5xVt4btQ@mail.gmail.com>
Message-ID: <564A2D67.9090203@durchholz.org>

Am 16.11.2015 um 19:32 schrieb Mike Meyer:
> On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz <jo at durchholz.org> wrote:
>
>> Am 16.11.2015 um 18:36 schrieb Mike Meyer:
>> I haven't seen you argue what purpose a full history might actually
>> have, so I still can't say what value you see in the "full history"
>> approach, but ah well - sometimes it's hard to verbalize such feelings,
>>
>
> Accuracy. Having watched the soviets change their history texts with each
> regime, it bothers me to see history changed.

I can understand the sentiment, but neither reasons nor consequences 
seem comparable.
The Soviets edited history to falsify it.
SCM history editing is to make it easier to understand, not to falsify it.

Actually the work of any historian is a rewrite if you will.

 > If people actually read
> and/or otherwise examined these "carefully crafted change logs" on a
> regular basis, I might feel otherwise.

Believe me, they do.
Been there, done that. Particularly to find out why underdocumented 
parts of the code were introduced, what parts of it were intentional and 
what parts accidental, and whom to ask about specific parts of the code. 
You really need to know that for any major clean-up in a code base that 
has become messy, as is inevitable over time.
Having an extensive history of merge commits pushed that job from "hard" 
to "not doable" for me, and more than once.

Regards,
Jo

From carter.schonwald at gmail.com  Tue Nov 17 01:16:29 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 16 Nov 2015 20:16:29 -0500
Subject: [Haskell-cafe] model checking for (subset of) concurrent
	Haskell?
In-Reply-To: <5649C01A.3010903@htwk-leipzig.de>
References: <5649C01A.3010903@htwk-leipzig.de>
Message-ID: <CAHYVw0xXa0S5pmXB976g4Gq_pF7RNdkk=toqmE7kQs5Z4X73EQ@mail.gmail.com>

Please let me know what you find!
I may very well be putting some effort into an ltl Haskell model checker
for work in the near future myself.

On Monday, November 16, 2015, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> For model checking concurrent and distributed imperative programs,
> there's the Promela language, and the Spin model checker
> ( http://spinroot.com ) than can explore/enumerate
> a finite state space of a system and decide validity of LTL formulae.
>
> Is there something similar for Haskell models of concurrency?
> Ideally, some subset of Haskell (containing enough of
> Control.Concurrent.*) as an alternative for Promela.
>
> It should even be possible to put the model checking
> in an alternative implementation of respective monad
> (STM, IO for MVars) so the whole thing is an embedded DSL.
>
> somewhat related: this project is about a verified model checker:
> https://cava.in.tum.de/ (ML code generated from Isabelle)
> but my interest is in model-checking concurrent programs
> in functional notation.
>
> - J.W.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/688ba3a7/attachment.html>

From amindfv at gmail.com  Tue Nov 17 04:52:18 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 16 Nov 2015 23:52:18 -0500
Subject: [Haskell-cafe] Darcs vs Git
In-Reply-To: <CAD=7U2A1OtCsBHQ92EKmuYnoJ5yetsMoq96YimMv1z5xVt4btQ@mail.gmail.com>
References: <CAB2YT55cF0cNXvEUKGg7Bdbpov+rZ6rD9shzdNKSyM6FdYb2YA@mail.gmail.com>
 <20151114194309.GA8829@casa.casa>
 <CAD=7U2Bo8ZQGkHLvWk2ndHB3SH0kGNswsQmex_X_r7MEj_MPUg@mail.gmail.com>
 <56479EFA.5040101@durchholz.org>
 <CAD=7U2AyeOHNqEU6DzdPgTKroMZRkb-e4W+OcX66pacOQjEvcw@mail.gmail.com>
 <CA+u6gbwCoUrM8=agC1PyfJU9bB42ZUr=G-bw83m9xd477_V+uQ@mail.gmail.com>
 <n299cg$lu0$1@ger.gmane.org>
 <CAD=7U2Cns=v+0_4zb-y=kTNmjdWmW1AGWfajqupKRNDWrCOX4Q@mail.gmail.com>
 <n2a6o3$iai$1@ger.gmane.org> <5648A8C8.7070204@durchholz.org>
 <CAD=7U2CYiYw7b9gERLkbY1fr3y9N3twB=ruuLyrcnKwQnHBEQg@mail.gmail.com>
 <5648C5E1.604@durchholz.org>
 <CAD=7U2AJ+2Vq=nx_6dU34AuU4oOzB+FvZ1ps4N5eH+p6Y7Ybog@mail.gmail.com>
 <5648CA72.4070606@durchholz.org>
 <CAD=7U2By=-czPzpzDpZ878S8Gj1HTunjL5zQQFy5zLebCmDgsQ@mail.gmail.com>
 <564A1C30.5060900@durchholz.org>
 <CAD=7U2A1OtCsBHQ92EKmuYnoJ5yetsMoq96YimMv1z5xVt4btQ@mail.gmail.com>
Message-ID: <80B164DF-3E33-4805-BB1B-BDE3E2FB44E9@gmail.com>



> El 16 nov 2015, a las 13:32, Mike Meyer <mwm at mired.org> escribi?:
> 
>> On Mon, Nov 16, 2015 at 12:11 PM Joachim Durchholz <jo at durchholz.org> wrote:
>> Am 16.11.2015 um 18:36 schrieb Mike Meyer:
>> I haven't seen you argue what purpose a full history might actually
>> have, so I still can't say what value you see in the "full history"
>> approach, but ah well - sometimes it's hard to verbalize such feelings,
> 
> Accuracy. Having watched the soviets change their history texts with each regime, it bothers me to see history changed. If people actually read and/or otherwise examined these "carefully crafted change logs" on a regular basis, I might feel otherwise. But I never look at them unless I'm chasing a bug, and as far as I can tell, nobody else does either. So spending time editing history is not only mostly wasted effort, it may well cause problems for the only use. I don't have any actual proof that this is the case, but I haven't seen any for any other position, either. If you've got it, I'd certainly be interested in reading it.
>  
>> I just hope that you can accept that other people greatly prefer a log
>> which has been geared towards better reviewability. 
> 
> Oh, I don't have a problem doing that. But I expect the same courtesy in return. In particular, If I choose to donate my work to your project, you'll not ask me to change my clone of your repo to meet your expectations, but modify the change log as you pull it to meet your standards. If that's a hoop you insist contributors jump through, that's cool. I'll stop submitting them. It's not like I lack things to do.

"git merge --squash" is what you can use to satisfy both the person who wants a clean commit and the person who wants an accurate history log -- you can use it to create a single commit that's the sum of all changes on another branch, and now you're only creating a new branch instead of rewriting the old one.

tom


> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151116/026275a1/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Tue Nov 17 08:52:27 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 17 Nov 2015 09:52:27 +0100
Subject: [Haskell-cafe] turn off "thread blocked indefinitely in an STM
	transaction"?
Message-ID: <564AEACB.9060301@htwk-leipzig.de>

I find the following mildly annoying:

Prelude> import Control.Concurrent.STM
Prelude Control.Concurrent.STM> atomically retry
*** Exception: thread blocked indefinitely in an STM transaction

Is there a way to not raise this exception, and block the thread?

I don't see this behaviour (raising the exception)
mentioned in the API docs nor in the defining paper
(Composable memory transactions, PPoPP'05) that is referenced there.

I understand it might come in handy for debugging,
but sometimes (e.g., for teaching)
I might really want a transaction that never commits.

For instance, I am forkIO'ing some worker threads
and the main program really should do absolutely nothing.
So I thought I could just block the main thread.

I can make some work-around with

forM [1..n] $ \ p ->
      ( if p < n then void . forkIO else id ) $ forever $ do

but that feels clumsy (since asymmetric).

- J.W.

From jules at jellybean.co.uk  Tue Nov 17 08:11:49 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue, 17 Nov 2015 08:11:49 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <CAKA2JgKiqz90-PajfWh8YQ=e2qSX9AZvQdr3BWyj7pLcuBXfLA@mail.gmail.com>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
 <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
 <2775EC12-0298-45CE-ACC3-04C5FB7125C9@jellybean.co.uk>
 <CAKA2JgKiqz90-PajfWh8YQ=e2qSX9AZvQdr3BWyj7pLcuBXfLA@mail.gmail.com>
Message-ID: <050D393C-877C-4EFA-96E8-EEBCDBD8CEC2@jellybean.co.uk>

(Apologies for coming back after 2 weeks)

On 4 Nov 2015, at 19:41, Michael Snoyman <michael at snoyman.com> wrote:

> 
> 
> On Wed, Nov 4, 2015 at 9:28 AM, Jules Bean <jules at jellybean.co.uk> wrote:
> 
> On 4 Nov 2015, at 13:04, Michael Snoyman <michael at snoyman.com> wrote:
> 
>> This got me curious, so I just added a `sourceToList` function to master:
>> 
>> https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a
> 
> Having spent a day thinking this over?
> 
> Nothing with the type `Source m a -> m [a]` can work for my second example - the one where I use runExceptionT to discharge the MonadThrow constraint. This is because once you use runExceptionT you have pushed yourself into the situation where in case of error there is no ?return value?. 
> 
> 
> I don't think that the Writer example above is demonstrating what you're saying, since you're using imprecise exceptions (`error`) instead of MonadThrow. You could do the same thing with sourceToList and get that result.

There was another example where I don?t use imprecise exceptions, but I use ExceptionT:

> source123Throw :: MonadThrow m => Source m Int
> source123Throw = do
> yield 1
> yield 2
> yield 3
> throwM MyError

*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything)
[1,2,3]

The point here is the order of nesting runWriter(T) and runException(T). If you do it this way around the type is `([a],Either Exception ())` and you can just inspect the first element of the tuple to check the list without checking for an error - which allows it to be streaming. 


`Source m a -> m [a]` can only take this second form.

Jules




From jules at jellybean.co.uk  Tue Nov 17 09:13:30 2015
From: jules at jellybean.co.uk (Jules Bean)
Date: Tue, 17 Nov 2015 09:13:30 +0000
Subject: [Haskell-cafe] Streaming a Conduit into a lazy list
In-Reply-To: <CAKA2JgKiqz90-PajfWh8YQ=e2qSX9AZvQdr3BWyj7pLcuBXfLA@mail.gmail.com>
References: <74A47D3E-C908-4E74-B4A1-782943491F45@jellybean.co.uk>
 <CAKA2JgLVihMCPRvNM+dRr=871=wf7yO6SSQm6cq3+_MQ0pAReA@mail.gmail.com>
 <CAKA2JgJHXvpAvR0KFrnOS6Dnwp9h27aAbAfxf7X3OsDtTDYbbw@mail.gmail.com>
 <2775EC12-0298-45CE-ACC3-04C5FB7125C9@jellybean.co.uk>
 <CAKA2JgKiqz90-PajfWh8YQ=e2qSX9AZvQdr3BWyj7pLcuBXfLA@mail.gmail.com>
Message-ID: <E16ECF84-C347-448E-BA62-22350F3494A7@jellybean.co.uk>

(Apologies for coming back after 2 weeks)

On 4 Nov 2015, at 19:41, Michael Snoyman <michael at snoyman.com> wrote:

> 
> 
> On Wed, Nov 4, 2015 at 9:28 AM, Jules Bean <jules at jellybean.co.uk> wrote:
> 
> On 4 Nov 2015, at 13:04, Michael Snoyman <michael at snoyman.com> wrote:
> 
>> This got me curious, so I just added a `sourceToList` function to master:
>> 
>> https://github.com/snoyberg/conduit/commit/289f671cb7669c4aec78d8e77f01f2ace165d73a
> 
> Having spent a day thinking this over?
> 
> Nothing with the type `Source m a -> m [a]` can work for my second example - the one where I use runExceptionT to discharge the MonadThrow constraint. This is because once you use runExceptionT you have pushed yourself into the situation where in case of error there is no ?return value?. 
> 
> 
> I don't think that the Writer example above is demonstrating what you're saying, since you're using imprecise exceptions (`error`) instead of MonadThrow. You could do the same thing with sourceToList and get that result.

There was another example where I don?t use imprecise exceptions, but I use ExceptionT:

> source123Throw :: MonadThrow m => Source m Int
> source123Throw = do
> yield 1
> yield 2
> yield 3
> throwM MyError

*Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything)
[1,2,3]

The point here is the order of nesting runWriter(T) and runException(T). If you do it this way around the type is `([a],Either Exception ())` and you can just inspect the first element of the tuple to check the list without checking for an error - which allows it to be streaming. 


`Source m a -> m [a]` can only take this second form.

Jules




From agocorona at gmail.com  Tue Nov 17 09:27:58 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 17 Nov 2015 10:27:58 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
 <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
Message-ID: <CAArEJmbeM7Q7LKdMDWX5de34Cj+EmgGGL91L2MkcaFo-zzwzYQ@mail.gmail.com>

Hi Will,
Right, I'm not an expert on low level things, but yes, each memory page can
cache a different vector and even can work faster. Specially if the
algoritm uses a few fields of a large structure. I was wrong on that.

But anyway, Unboxed  need more native support to give Haskell more
credibility in performance critical problems.  Now it has some conversion
overhead  for user defined data.  That may be optimized away but the whole
thing is second class, via an instance instead of a language feature.

Maybe  automatic deriving Unboxed instances can be the right compromise

2015-11-14 18:53 GMT+01:00 Will Yager <will.yager at gmail.com>:

> This is why CPUs have many independent cache lines. Unpacking a vector
> into multiple vectors is usually fine for performance. I have seen it
> actually increase performance, because it simplifies addressing.
>
> -Will
>
> On Nov 14, 2015, at 05:30, Alberto G. Corona <agocorona at gmail.com> wrote:
>
>
> This is nice in some cases, but does most of the time does not. this does
> not solve the problem of CPU cache since the fields in the data are at
> least lenght (Vector)  away. I mean that if the vector is moderately long,
> if the first field is in the cache, the second or third etc may not be.
> Usually the fields of any data are handled together.
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151117/6d85ba20/attachment.html>

From agocorona at gmail.com  Tue Nov 17 09:38:41 2015
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 17 Nov 2015 10:38:41 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAHYVw0yjoY4qsvo508gUP=8WY1Y8otM9oFDOg89dVakRJrT1Rg@mail.gmail.com>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
 <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
 <CAHYVw0yjoY4qsvo508gUP=8WY1Y8otM9oFDOg89dVakRJrT1Rg@mail.gmail.com>
Message-ID: <CAArEJmaygFje=dmbNRRksAfEsQ74YS8ST2AzJO0+QyKW2M5Chw@mail.gmail.com>

Hi Carter

Now that the Strict pragma is being implemented, perhaps it is time to
retake that work.

I have leksah IDE installed. it is a haskell application. What I can verify
with my performance meter on Windows is that merely scrolling text, the
lekssah  produces much more page faults than any non Haskell application.

2015-11-15 1:45 GMT+01:00 Carter Schonwald <carter.schonwald at gmail.com>:

> Indeed! There's no one true best format.
> There was some work to add native support for c structs to the Haskell
> ffi, as storable format for non recursive records, but there's some really
> gnarly subtleties with respect to alignment and packing that come up that
> likely are fundamentally impossible to characterize in a simple algorithmic
> fashion that will serve everyone well.
>
>
> On Saturday, November 14, 2015, Will Yager <will.yager at gmail.com> wrote:
>
>> This is why CPUs have many independent cache lines. Unpacking a vector
>> into multiple vectors is usually fine for performance. I have seen it
>> actually increase performance, because it simplifies addressing.
>>
>> -Will
>>
>> On Nov 14, 2015, at 05:30, Alberto G. Corona <agocorona at gmail.com> wrote:
>>
>>
>> This is nice in some cases, but does most of the time does not. this does
>> not solve the problem of CPU cache since the fields in the data are at
>> least lenght (Vector)  away. I mean that if the vector is moderately long,
>> if the first field is in the cache, the second or third etc may not be.
>> Usually the fields of any data are handled together.
>>
>>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151117/91af2459/attachment.html>

From skosyrev at ptsecurity.com  Tue Nov 17 09:50:42 2015
From: skosyrev at ptsecurity.com (Kosyrev Serge)
Date: Tue, 17 Nov 2015 12:50:42 +0300
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <CAArEJmbeM7Q7LKdMDWX5de34Cj+EmgGGL91L2MkcaFo-zzwzYQ@mail.gmail.com>	(Alberto
 G. Corona's message of "Tue, 17 Nov 2015 10:27:58 +0100")
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
 <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
 <CAArEJmbeM7Q7LKdMDWX5de34Cj+EmgGGL91L2MkcaFo-zzwzYQ@mail.gmail.com>
Message-ID: <87lh9xc5u5.fsf@andromedae.feelingofgreen.ru>

"Alberto G. Corona " <agocorona at gmail.com> writes:
> Hi Will,
> Right, I'm not an expert on low level things, but yes, each memory
> page can cache a different vector and even can work faster. Specially
> if the algoritm uses a few fields of a large structure. I was wrong on
> that.
>
> But anyway, Unboxed need more native support to give Haskell more
> credibility in performance critical problems. Now it has some
> conversion overhead for user defined data. That may be optimized away
> but the whole thing is second class, via an instance instead of a
> language feature.
>
> Maybe automatic deriving Unboxed instances can be the right compromise

Given how the imagination immediately suggests that:

  1. performance nuances dictated by the context might suggest different
     preferences for Unboxed encodings..

  2. and, on the other hand, given the undesirability of always engaging
     oneself into full-blown instance definition -- for various reasons..

..it suggests that a language feature would be helpful, that would allow
to gradually inform the derivation GHC makes, without fully engaging into
specifying complete details.

Can we imagine that a derivation could proceed, for example, from:

  - a /subset/ of minimal typeclass definition, or alternatively
  - direct parameters

..?

Also, a set of deeper questions could be asked, if you can forgive me this
daydreaming..

If we follow the spirit of self-defined languages (won't name them):

 1. does it make sense to "open up" the process of derivation?

 2. what prevents us from describing derivations as a functional transformation?

 3. what is the possible language for these -- TH? something else?


-- 
? ???????e? / respectfully,
??????? ??????

From janis.voigtlaender at gmail.com  Tue Nov 17 10:04:06 2015
From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=)
Date: Tue, 17 Nov 2015 11:04:06 +0100
Subject: [Haskell-cafe] the last mile in haskell performance
In-Reply-To: <87lh9xc5u5.fsf@andromedae.feelingofgreen.ru>
References: <CAArEJmYrQcbygfbXJfSEa4iXzE7B-NHTAFjroh+U_OAjgEacZw@mail.gmail.com>
 <5644D2CA.7000102@kane.cx>
 <CAArEJmZRrJgOuiecVgnawJdTv1MJbK=mLNhEgZCyxxs8ohsjDA@mail.gmail.com>
 <CAKA2JgKmJ0PtEpWfs51L6RqWFToOz5dXxa0zR1oYwJTwrAbhtA@mail.gmail.com>
 <CAArEJmbd2MiPHrO3y-3ak02DTzFtdHLAnKahf65KM33Kp7EyOA@mail.gmail.com>
 <CAArEJmYRECM=rRgp=WPwc4OUhK2e9YnqojJjAUA=ByWysFFQmw@mail.gmail.com>
 <3A79DD87-6F47-4FFD-BADB-663D3242EB3B@gmail.com>
 <CAArEJmbeM7Q7LKdMDWX5de34Cj+EmgGGL91L2MkcaFo-zzwzYQ@mail.gmail.com>
 <87lh9xc5u5.fsf@andromedae.feelingofgreen.ru>
Message-ID: <CAGkFuyDr1vwJ-qkpQ08J2j8QLpOXZNUJ1yK+SexfEWi0zaMw_A@mail.gmail.com>

Also, a set of deeper questions could be asked, if you can forgive me this
daydreaming..

If we follow the spirit of self-defined languages (won?t name them):

   1.

   does it make sense to ?open up? the process of derivation?
   2.

   what prevents us from describing derivations as a functional
   transformation?
   3.

   what is the possible language for these ? TH? something else?

https://wiki.haskell.org/GHC.Generics?
?

2015-11-17 10:50 GMT+01:00 Kosyrev Serge <skosyrev at ptsecurity.com>:

> "Alberto G. Corona " <agocorona at gmail.com> writes:
> > Hi Will,
> > Right, I'm not an expert on low level things, but yes, each memory
> > page can cache a different vector and even can work faster. Specially
> > if the algoritm uses a few fields of a large structure. I was wrong on
> > that.
> >
> > But anyway, Unboxed need more native support to give Haskell more
> > credibility in performance critical problems. Now it has some
> > conversion overhead for user defined data. That may be optimized away
> > but the whole thing is second class, via an instance instead of a
> > language feature.
> >
> > Maybe automatic deriving Unboxed instances can be the right compromise
>
> Given how the imagination immediately suggests that:
>
>   1. performance nuances dictated by the context might suggest different
>      preferences for Unboxed encodings..
>
>   2. and, on the other hand, given the undesirability of always engaging
>      oneself into full-blown instance definition -- for various reasons..
>
> ..it suggests that a language feature would be helpful, that would allow
> to gradually inform the derivation GHC makes, without fully engaging into
> specifying complete details.
>
> Can we imagine that a derivation could proceed, for example, from:
>
>   - a /subset/ of minimal typeclass definition, or alternatively
>   - direct parameters
>
> ..?
>
> Also, a set of deeper questions could be asked, if you can forgive me this
> daydreaming..
>
> If we follow the spirit of self-defined languages (won't name them):
>
>  1. does it make sense to "open up" the process of derivation?
>
>  2. what prevents us from describing derivations as a functional
> transformation?
>
>  3. what is the possible language for these -- TH? something else?
>
>
> --
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151117/52c1ff3c/attachment.html>

From silvio.frischi at gmail.com  Tue Nov 17 11:25:14 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Tue, 17 Nov 2015 12:25:14 +0100
Subject: [Haskell-cafe] turn off "thread blocked indefinitely in an STM
 transaction"?
In-Reply-To: <564AEACB.9060301@htwk-leipzig.de>
References: <564AEACB.9060301@htwk-leipzig.de>
Message-ID: <564B0E9A.2010400@gmail.com>

> Is there a way to not raise this exception, and block the thread?

You can always prevent these blocked indefinitely exceptions by making a
stable pointer to the threadId. This works because using ThreadId an
Exception could be thrown to that thread, which would cause it to
continue (and not block indefinitely).

https://ghc.haskell.org/trac/ghc/ticket/10759

Cheers

Silvio

From johannes.waldmann at htwk-leipzig.de  Tue Nov 17 12:06:10 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 17 Nov 2015 13:06:10 +0100
Subject: [Haskell-cafe] turn off "thread blocked indefinitely in an STM
	transaction"?
Message-ID: <564B1832.3000304@htwk-leipzig.de>

Ah, neat. I get the idea. But does it work here?

import Control.Concurrent.STM
import Foreign.StablePtr
main =  atomically retry >>= newStablePtr

ghc -threaded -rtsopts -O2 sp.hs

./sp +RTS -N
sp: thread blocked indefinitely in an STM transaction

- J.

From roma at ro-che.info  Tue Nov 17 12:15:41 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 17 Nov 2015 14:15:41 +0200
Subject: [Haskell-cafe] turn off "thread blocked indefinitely in an STM
 transaction"?
In-Reply-To: <564B1832.3000304@htwk-leipzig.de>
References: <564B1832.3000304@htwk-leipzig.de>
Message-ID: <564B1A6D.1070709@ro-che.info>

On 11/17/2015 02:06 PM, Johannes Waldmann wrote:
> Ah, neat. I get the idea. But does it work here?
> 
> import Control.Concurrent.STM
> import Foreign.StablePtr
> main =  atomically retry >>= newStablePtr
> 
> ghc -threaded -rtsopts -O2 sp.hs
> 
> ./sp +RTS -N
> sp: thread blocked indefinitely in an STM transaction


StablePtr needs to contain the ThreadId of the current thread.

  myThreadId >>= newStablePtr
  atomically retry

In your example, newStablePtr won't even be called until retry has been
interrupted.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151117/1e875db0/attachment.sig>

From johannes.waldmann at htwk-leipzig.de  Tue Nov 17 12:25:25 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 17 Nov 2015 13:25:25 +0100
Subject: [Haskell-cafe] turn off "thread blocked indefinitely in an STM
	transaction"?
Message-ID: <564B1CB5.6040201@htwk-leipzig.de>

myThreadId >>= newStablePtr ; atomically retry

Yes, that works. Thanks.

From michael at schmong.org  Tue Nov 17 20:47:20 2015
From: michael at schmong.org (Michael Litchard)
Date: Tue, 17 Nov 2015 12:47:20 -0800
Subject: [Haskell-cafe] reactive-banana project examples
Message-ID: <CAEzeKYpDSRoPWsTRzf3-CqGYdphkE7-ANPEXA1fVNcGj11SdtA@mail.gmail.com>

Could I get some pointers to projects using reactive-banana. I'm looking
for projects that have code testing their Behaviors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151117/51f4e12e/attachment.html>

From gershomb at gmail.com  Wed Nov 18 02:01:28 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 17 Nov 2015 21:01:28 -0500
Subject: [Haskell-cafe] Call For Presentations: Compose 2016, New York,
	Feb 4-5
Message-ID: <CAM8RHpEfmN2k0v2FcrFCpzV9adskw7WsBL2MW6HsjpsYx2fFew@mail.gmail.com>

Compose is a conference for typed functional programmers, focused
specifically on Haskell, OCaml, F#, and related technologies. It will
be held in New York on Thursday and Friday, Feb 4-5, 2016.
Registration will be open shortly.

http://www.composeconference.org/

To get a sense of Compose, you can check out the great talks from the
2015 conference: http://www.composeconference.org/2015/summary/

Below is our call for presentations. We recognize the deadline is
tight, so feel free to submit proposals and ideas on the less-polished
side.

http://www.composeconference.org/2016/cfp/

* * *

The audience for Compose is Haskell, OCaml, F#, or SML developers who
are looking to increase their skills or learn new technologies and
libraries. Presentations should be aimed at teaching or introducing
new ideas or tools. We are also interested in presentations aiming at
taking complex concepts, such as program derivation, and putting them
into productive use. However proposals on anything that you suspect
our audience may find interesting are welcome. The following are some
of the types of talks we would welcome:

Library/Tool Talks ? Exploring the uses of a powerful toolkit or
library, be it for parsing, testing, data access and analysis, or
anything else.

Production Systems ? Experience reports on deploying functional
techniques in real systems; insights revealed, mistakes made, lessons
learned.

Theory made Practical ? Just because it?s locked away in papers
doesn?t mean it?s hard! Accessible lectures on classic results and why
they matter to us today. Such talks can include simply introducing the
principles of a field of research so as to help the audience read up
on it in the future; from abstract machines to program derivation to
branch-and-bound algorithms, the sky?s the limit.

We also welcome proposals for more formal tutorials. Tutorials should
be aimed at a smaller audience of beginner-to-novice understanding,
and ideally include hands-on exercises.

The due date for submissions is December 14, 2015. We will send out
notice of acceptance by December 24th. We prefer that submissions be
via the EasyChair website
(https://easychair.org/conferences/?conf=compose2016). Please suggest
a title, and describe the topic you intend to speak on. Talks can be
either 30 or 45 minutes, please indicate how much time you would
prefer to take.

Additional information may be included on both your expertise and the
interesting elements of your topic, going on what might be included in
a public abstract. Furthermore, if your abstract doesn't feel
"final"?don't worry! We'll work with you to polish it up. If you want
to discuss your proposal(s) before submitting, or to further nail down
what you intend to speak on, please feel free to contact us at
info at composeconference.org. We're happy to work with you, even if you
are a new or inexperienced speaker, to help your talk be great.

* * *

Diversity

We would like to put an emphasis on soliciting a diverse set of
speakers - anything you can do to distribute information about this
CFP and encourage submissions from under-represented groups would be
greatly appreciated. We welcome your contributions and encourage you
to apply!

Best,
Gershom

From K.Bleijenberg at lijbrandt.nl  Wed Nov 18 09:25:03 2015
From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg)
Date: Wed, 18 Nov 2015 10:25:03 +0100
Subject: [Haskell-cafe] Partition int 180. Out of memory
Message-ID: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>

I want to partition the integer n=180 with terms >=5

I.e.  n=15 => [[5,5,5],[8,7],[9,6],[10,5],[15]]

The function part does this. memopart does it with memoization a lot faster.

mempart works fine on my machine until n=120. For n=130 I get 'out of
memory'. For other reasons I work on Win64 with ghc32.

To save memory I replaced Int with Word8. I also replaced [Word8] with
B.ByteString (memopartB). But no luck. I still get 'out of memory' for
n=130.

I run the program with: part +RTS -M4294967295  (429... is according to ghc
the max memory I can use)

 

Any ideas how to solve this? 

What is the most memory efficient replacement for a list?

 

module Main (

   main,part,memopart   

)

 

where

 

import Data.Int 

import System.Time

import qualified Data.ByteString.Lazy as B

import Data.Word

import Data.List (intercalate)

 

part :: Int -> [[Int]]

part 0 = [[]]

part n = [x:y | x <- [5..n], y <- part (n-x),  [x] >= take 1 y]

 

partB :: Word8 -> [B.ByteString]

partB 0 = [B.empty]

partB n = [B.cons x y | x <- [5..n], y <- partB (n-x), B.singleton x >= y]

 

memopart a = memo !! a  where

    memo = [[]] : [[x:y | x <- [5..n], y <- memo !! (n-x), [x] >= take 1 y]
| n <- [5..]]

 

memopartB :: Int -> [B.ByteString]    

memopartB a = memo !! a  where             

                  memo :: [[B.ByteString]]

                  memo = [B.empty] : [[B.cons x y | x <- [5 :: Word8 .. n ::
Word8], y <- memo !! minusWord8 n x, B.singleton x >= y] | n <- [5 :: Word8
..]]

                  minusWord8 :: Word8 -> Word8 -> Int

                  minusWord8 c d = (fromIntegral c :: Int) - (fromIntegral
d:: Int)

    

main = do

         startTime <- getClockTime

         -- print $ length $ memopart 50

         putStrLn $ showPartBRes $ memopartB 120

         stopTime  <- getClockTime

         putStrLn ("Time: " ++ timeDiffToString (diffClockTimes stopTime
startTime))

         

showPartBRes :: [B.ByteString] -> String

showPartBRes res = intercalate ", " $ map showB  res

                   where showB :: B.ByteString -> String

                         showB arr = '[' : intercalate "," (B.foldr (\w acc
-> show w : acc) [] arr) ++ "]"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151118/e5adf210/attachment.html>

From matthewtpickering at gmail.com  Wed Nov 18 13:45:00 2015
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 18 Nov 2015 13:45:00 +0000
Subject: [Haskell-cafe] ANN: haskell-src-exts 1.17
Message-ID: <CALuQ0m-47v8RHj8u6cYDdwj-XLFqatWjK+1NSwu=gSwH1Z+e=g@mail.gmail.com>

Dear list,

I am pleased to report that Peter has just released a new version of
haskell-src-exts. I include the release notes below. This release
fixes a large number of long standing bugs so I urge all users to
update their projects to use this new version.

If haskell-src-exts fails to parse a program which GHC accepts then
please report an issue to the issue tracker.

Best wishes,

Matt

---------

I am pleased to announce the release of haskell-src-exts-1.17.0!

Hackage: https://hackage.haskell.org/package/haskell-src-exts-1.17.0
GitHub: https://github.com/haskell-suite/haskell-src-exts

This release brings bugfixes, as well as the following language
features:
* Type wildcards and expression holes (#252).
* Pattern Synonyms (#197).

The full changelog is available at
https://github.com/haskell-suite/haskell-src-exts/blob/1.17.0/CHANGELOG

This release is brought to you by:
Matthew Pickering
Michael Walker
Simon Marlow
Neil Mitchell
JP Moresmau
????? ????????????
phischu
Michael Sloan
m00nlight
Niklas Broberg
Stijn van Drongelen
Jakub Kozlowski
Leonid Onokhov

Matthew Pickering is a force of nature who deserves a special mention
for all his contributions to this release.

Peter

From erantapaa at gmail.com  Wed Nov 18 15:49:20 2015
From: erantapaa at gmail.com (Erik Rantapaa)
Date: Wed, 18 Nov 2015 07:49:20 -0800 (PST)
Subject: [Haskell-cafe] Partition int 180. Out of memory
In-Reply-To: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>
References: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>
Message-ID: <94aa9686-096b-4816-8a32-5568e4b81793@googlegroups.com>



On Wednesday, November 18, 2015 at 3:25:12 AM UTC-6, Kees Bleijenberg wrote:
>
> I want to partition the integer n=180 with terms >=5
>
> I.e.  n=15 => [[5,5,5],[8,7],[9,6],[10,5],[15]]
>

For an alternate way to produce partitions, have a look at how the combinat 
package does it:

https://hackage.haskell.org/package/combinat-0.2.8.1/docs/src/Math-Combinat-Partitions-Integer.html#line-308

In particular, in this part:

    _partitions' (!h ,!w) d =  [ i:xs | i <- [1..min d h] , xs <- _partitions' (i,w-1) (d-i) ]


if you change `i <- [1..min d h]` to ` i <- [5..min d h]` it appears you 
will get the partitions which have size at least 5.

After you make the change, call the function like this: _partitions' 
(180,180) 180

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151118/7d032654/attachment.html>

From will.yager at gmail.com  Wed Nov 18 20:07:39 2015
From: will.yager at gmail.com (William Yager)
Date: Wed, 18 Nov 2015 14:07:39 -0600
Subject: [Haskell-cafe] Partition int 180. Out of memory
In-Reply-To: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>
References: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>
Message-ID: <CAG8oi1Mq254Os1f0dZbNu=da+wa4VodifKXrT_zXT0wpY6ADiQ@mail.gmail.com>

Data.Vector.Unboxed and Data.Vector.Storable.

Sometimes you have to be clever with memoization on these data structures,
because every element in the vector is strict in the whole vector. There
are some functions to help with this (like constructN).

--Will

On Wed, Nov 18, 2015 at 3:25 AM, Kees Bleijenberg <
K.Bleijenberg at lijbrandt.nl> wrote:

>
> What is the most memory efficient replacement for a list?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151118/11f02751/attachment.html>

From awick at galois.com  Thu Nov 19 01:22:45 2015
From: awick at galois.com (Adam Wick)
Date: Thu, 19 Nov 2015 01:22:45 +0000
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
Message-ID: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>

Howdy -

Galois is pleased to announce an initial release of haskell-tor.
Haskell-tor is intended to be a full-featured, drop-in implementation of
the Tor onion routing protocol. This release provides full support for
resolving names and building connections via anonymized channels, as well
as (less tested) support for running relay and exit nodes.

There are still many tasks left to do, however, if you're interested in
learning about and working on a Tor implementation, including support for
hidden services, proper flow control, directory support, etc. So if you're
interested, jump in! We welcome your patches.

You can find haskell-tor on:

GitHub: https://github.com/GaloisInc/haskell-tor
Hackage: https://hackage.haskell.org/package/haskell-tor

Haskell-tor is HaLVM-ready.


- Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151119/1290ca86/attachment.html>

From raichoo at googlemail.com  Thu Nov 19 08:21:04 2015
From: raichoo at googlemail.com (raichoo)
Date: Thu, 19 Nov 2015 09:21:04 +0100
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
In-Reply-To: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
References: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
Message-ID: <CAJaUxexFP8KSHuwVuDXMuYOkwmuLESnKrMZ7DtW60cp2VJaeFg@mail.gmail.com>

Amazing \o/
I was hoping for this to be announced after hearing you talk about this in
a HalVM talk.
I'm really excited about this and HalVM!

Kind regards,
raichoo

On Thu, Nov 19, 2015 at 2:22 AM, Adam Wick <awick at galois.com> wrote:

> Howdy -
>
> Galois is pleased to announce an initial release of haskell-tor.
> Haskell-tor is intended to be a full-featured, drop-in implementation of
> the Tor onion routing protocol. This release provides full support for
> resolving names and building connections via anonymized channels, as well
> as (less tested) support for running relay and exit nodes.
>
> There are still many tasks left to do, however, if you're interested in
> learning about and working on a Tor implementation, including support for
> hidden services, proper flow control, directory support, etc. So if you're
> interested, jump in! We welcome your patches.
>
> You can find haskell-tor on:
>
> GitHub: https://github.com/GaloisInc/haskell-tor
> Hackage: https://hackage.haskell.org/package/haskell-tor
>
> Haskell-tor is HaLVM-ready.
>
>
> - Adam
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151119/ca9c07e3/attachment.html>

From K.Bleijenberg at lijbrandt.nl  Thu Nov 19 09:06:54 2015
From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg)
Date: Thu, 19 Nov 2015 10:06:54 +0100
Subject: [Haskell-cafe] Partition int 180. Out of memory
In-Reply-To: <94aa9686-096b-4816-8a32-5568e4b81793@googlegroups.com>
References: <000001d121e3$0156e5e0$0404b1a0$@lijbrandt.nl>
 <94aa9686-096b-4816-8a32-5568e4b81793@googlegroups.com>
Message-ID: <001801d122a9$a2f508c0$e8df1a40$@lijbrandt.nl>

Hi Erik,

Complicated stuff. Your proposal worked. It took (on my compter )341 secs to compute the 612.743.290 partitions.
Thanks!

Kees

-----------------------
On Wednesday, November 18, 2015 at 3:25:12 AM UTC-6, Kees Bleijenberg wrote:
I want to partition the integer n=180 with terms >=5
I.e.  n=15 => [[5,5,5],[8,7],[9,6],[10,5],[15]]

For an alternate way to produce partitions, have a look at how the combinat package does it:

https://hackage.haskell.org/package/combinat-0.2.8.1/docs/src/Math-Combinat-Partitions-Integer.html#line-308

In particular, in this part:

    _partitions' (!h ,!w) d =  [ i:xs | i <- [1..min d h] , xs <- _partitions' (i,w-1) (d-i) ]

if you change `i <- [1..min d h]` to ` i <- [5..min d h]` it appears you will get the partitions which have size at least 5.

After you make the change, call the function like this: _partitions' (180,180) 180



From martin.drautzburg at web.de  Thu Nov 19 17:18:49 2015
From: martin.drautzburg at web.de (martin)
Date: Thu, 19 Nov 2015 18:18:49 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
Message-ID: <564E0479.3060203@web.de>

Hello all,

I wrote a Logger which, under certain conditions, prepends log-entries to a log and a Monoid instance of it. But as soon
as I mappend two Loggers my performance drops by 50%. This even happens when I mappend  mempty as shown below in --<2--.
I understand that the system has to do *something*, but it seems to cost a bit much. Without the strictness annotation
in --<1-- the performance degradation is even more dramatic (orders of magnitude).

The profile tells me that more that 50% of the time is spent in mappend.

COST CENTRE  MODULE    %time %alloc

mappend.\    Logger     50.6   35.8
logCount'.f  Logger     18.7   40.3
logCount'    Logger      5.4    0.0

Why is that so, and can I do anything about it?  I am willing to change the overall design if required.


This is the code

-- | A writer does the formatting
newtype Wtr a log = Wtr {runWtr :: a -> log}

-- | A looger is a writer plus an internal state
data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)}

instance Monoid (Logger a log) where
        mempty = Lgr (\_ l -> (l,mempty))
        mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') = runLogger lgr1 a l      --<1--
                                              !(log2',!lgr2') = runLogger lgr2 a log1'  --<1--
                                          in (log2', mappend lgr1' lgr2')


and this is how I test it

-- | Count calls __s__ and write log when s has reached nxt and then every dn calls
logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log -> Logger a log
logCount' dn nxt s wtr = Lgr f
        where
            f a l = if s == nxt
                       then (runWtr wtr (s,a)  <> l, logCount'  dn (nxt+dn) (s+1) wtr)
                       else (l,                      logCount'  dn nxt      (s+1) wtr)


-- | Count calls and write log every dn calls
logCount dn = logCount' dn dn 0


-- testLogger :: Logger Int Int [String] -> [String]
testLogger lgr xs = fst $ foldl' f ([],lgr) xs
        where
            f (log', lgr') x = runLogger lgr' x log'

ex_wtr :: Wtr (Int,a) [String]
ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)]

ex_wtr2 :: Wtr Int [String]
ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)]

ex_inputs :: [Int]
ex_inputs = [1..10000000]

ex_logger = mempty <> logCount 300000 ex_wtr <> mempty                 --<2--
-- ex_logger = logCount 300000 ex_wtr


ex_main = do
    timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs

main = ex_main

From hjgtuyl at chello.nl  Thu Nov 19 17:25:47 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Thu, 19 Nov 2015 18:25:47 +0100
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
In-Reply-To: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
References: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
Message-ID: <op.x8cyo9dypz0j5l@alquantor>

On Thu, 19 Nov 2015 02:22:45 +0100, Adam Wick <awick at galois.com> wrote:

:
> Galois is pleased to announce an initial release of haskell-tor.
> Haskell-tor is intended to be a full-featured, drop-in implementation of
> the Tor onion routing protocol. This release provides full support for
> resolving names and building connections via anonymized channels, as well
> as (less tested) support for running relay and exit nodes.
>
> There are still many tasks left to do, however, if you're interested in
> learning about and working on a Tor implementation, including support for
> hidden services, proper flow control, directory support, etc. So if  
> you're
> interested, jump in! We welcome your patches.
:

The package cannot be installed on a Windows computer, as it indirectly  
depends on the package unix; I get the messages:
   cabal: Error: some packages failed to install:
   hans-2.6.0.0 depends on unix-2.7.1.0 which failed to install.
   haskell-tor-0.1.0.0 depends on unix-2.7.1.0 which failed to install.

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From roma at ro-che.info  Thu Nov 19 18:15:13 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 19 Nov 2015 20:15:13 +0200
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564E0479.3060203@web.de>
References: <564E0479.3060203@web.de>
Message-ID: <564E11B1.5070900@ro-che.info>

My guess is that you have accumulating thunks inside your (Int,a) tuple.
Be sure to force them (by using a strict pair type, bang patterns, or
however else).

On 11/19/2015 07:18 PM, martin wrote:
> Hello all,
> 
> I wrote a Logger which, under certain conditions, prepends log-entries to a log and a Monoid instance of it. But as soon
> as I mappend two Loggers my performance drops by 50%. This even happens when I mappend  mempty as shown below in --<2--.
> I understand that the system has to do *something*, but it seems to cost a bit much. Without the strictness annotation
> in --<1-- the performance degradation is even more dramatic (orders of magnitude).
> 
> The profile tells me that more that 50% of the time is spent in mappend.
> 
> COST CENTRE  MODULE    %time %alloc
> 
> mappend.\    Logger     50.6   35.8
> logCount'.f  Logger     18.7   40.3
> logCount'    Logger      5.4    0.0
> 
> Why is that so, and can I do anything about it?  I am willing to change the overall design if required.
> 
> 
> This is the code
> 
> -- | A writer does the formatting
> newtype Wtr a log = Wtr {runWtr :: a -> log}
> 
> -- | A looger is a writer plus an internal state
> data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)}
> 
> instance Monoid (Logger a log) where
>         mempty = Lgr (\_ l -> (l,mempty))
>         mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') = runLogger lgr1 a l      --<1--
>                                               !(log2',!lgr2') = runLogger lgr2 a log1'  --<1--
>                                           in (log2', mappend lgr1' lgr2')
> 
> 
> and this is how I test it
> 
> -- | Count calls __s__ and write log when s has reached nxt and then every dn calls
> logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log -> Logger a log
> logCount' dn nxt s wtr = Lgr f
>         where
>             f a l = if s == nxt
>                        then (runWtr wtr (s,a)  <> l, logCount'  dn (nxt+dn) (s+1) wtr)
>                        else (l,                      logCount'  dn nxt      (s+1) wtr)
> 
> 
> -- | Count calls and write log every dn calls
> logCount dn = logCount' dn dn 0
> 
> 
> -- testLogger :: Logger Int Int [String] -> [String]
> testLogger lgr xs = fst $ foldl' f ([],lgr) xs
>         where
>             f (log', lgr') x = runLogger lgr' x log'
> 
> ex_wtr :: Wtr (Int,a) [String]
> ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)]
> 
> ex_wtr2 :: Wtr Int [String]
> ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)]
> 
> ex_inputs :: [Int]
> ex_inputs = [1..10000000]
> 
> ex_logger = mempty <> logCount 300000 ex_wtr <> mempty                 --<2--
> -- ex_logger = logCount 300000 ex_wtr
> 
> 
> ex_main = do
>     timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs
> 
> main = ex_main
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151119/9e37394b/attachment.sig>

From gagliardi.curtis at gmail.com  Thu Nov 19 18:58:07 2015
From: gagliardi.curtis at gmail.com (Curtis Gagliardi)
Date: Thu, 19 Nov 2015 10:58:07 -0800
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
In-Reply-To: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
References: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
Message-ID: <CAM_nd56Sz5LB4puXZVjJYTWMfSDZ4Y8oem503eJ=M4dq96L_+g@mail.gmail.com>

Very excited about this.  I want to contribute but am new to tor (internals
at least, been runing a relay for a long time).   Do any of those strike
you as lower hanging fruit than the others that might be a good place to
start?  Do you have any recommended resources or is the path pretty much
read the tor spec and implement it?

On Wed, Nov 18, 2015 at 5:22 PM, Adam Wick <awick at galois.com> wrote:

> Howdy -
>
> Galois is pleased to announce an initial release of haskell-tor.
> Haskell-tor is intended to be a full-featured, drop-in implementation of
> the Tor onion routing protocol. This release provides full support for
> resolving names and building connections via anonymized channels, as well
> as (less tested) support for running relay and exit nodes.
>
> There are still many tasks left to do, however, if you're interested in
> learning about and working on a Tor implementation, including support for
> hidden services, proper flow control, directory support, etc. So if you're
> interested, jump in! We welcome your patches.
>
> You can find haskell-tor on:
>
> GitHub: https://github.com/GaloisInc/haskell-tor
> Hackage: https://hackage.haskell.org/package/haskell-tor
>
> Haskell-tor is HaLVM-ready.
>
>
> - Adam
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151119/448fcc78/attachment.html>

From martin.drautzburg at web.de  Thu Nov 19 20:02:04 2015
From: martin.drautzburg at web.de (martin)
Date: Thu, 19 Nov 2015 21:02:04 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564E11B1.5070900@ro-che.info>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
Message-ID: <564E2ABC.3030206@web.de>

I just tried both strict pairs and seq, and it didn't change anything. Also, wouldn't then THUNKS consume a lot of
memory in my heap profile? I forgot to mention that this is not the case. Max heap is around 35k and the top-consumer
is ARR_WORDS. THUNK is below 1k.

I am going though 10,000,000 iterations and if anything would pile up, it would consume at least one byte per iteration,
wouldn't it? But I can't see 10 MBytes anywhere. It looks as if the time is really spent on *computing* something.

Am 11/19/2015 um 07:15 PM schrieb Roman Cheplyaka:
> My guess is that you have accumulating thunks inside your (Int,a) tuple.
> Be sure to force them (by using a strict pair type, bang patterns, or
> however else).
> 
> On 11/19/2015 07:18 PM, martin wrote:
>> Hello all,
>>
>> I wrote a Logger which, under certain conditions, prepends log-entries to a log and a Monoid instance of it. But as soon
>> as I mappend two Loggers my performance drops by 50%. This even happens when I mappend  mempty as shown below in --<2--.
>> I understand that the system has to do *something*, but it seems to cost a bit much. Without the strictness annotation
>> in --<1-- the performance degradation is even more dramatic (orders of magnitude).
>>
>> The profile tells me that more that 50% of the time is spent in mappend.
>>
>> COST CENTRE  MODULE    %time %alloc
>>
>> mappend.\    Logger     50.6   35.8
>> logCount'.f  Logger     18.7   40.3
>> logCount'    Logger      5.4    0.0
>>
>> Why is that so, and can I do anything about it?  I am willing to change the overall design if required.
>>
>>
>> This is the code
>>
>> -- | A writer does the formatting
>> newtype Wtr a log = Wtr {runWtr :: a -> log}
>>
>> -- | A looger is a writer plus an internal state
>> data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)}
>>
>> instance Monoid (Logger a log) where
>>         mempty = Lgr (\_ l -> (l,mempty))
>>         mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') = runLogger lgr1 a l      --<1--
>>                                               !(log2',!lgr2') = runLogger lgr2 a log1'  --<1--
>>                                           in (log2', mappend lgr1' lgr2')
>>
>>
>> and this is how I test it
>>
>> -- | Count calls __s__ and write log when s has reached nxt and then every dn calls
>> logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log -> Logger a log
>> logCount' dn nxt s wtr = Lgr f
>>         where
>>             f a l = if s == nxt
>>                        then (runWtr wtr (s,a)  <> l, logCount'  dn (nxt+dn) (s+1) wtr)
>>                        else (l,                      logCount'  dn nxt      (s+1) wtr)
>>
>>
>> -- | Count calls and write log every dn calls
>> logCount dn = logCount' dn dn 0
>>
>>
>> -- testLogger :: Logger Int Int [String] -> [String]
>> testLogger lgr xs = fst $ foldl' f ([],lgr) xs
>>         where
>>             f (log', lgr') x = runLogger lgr' x log'
>>
>> ex_wtr :: Wtr (Int,a) [String]
>> ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)]
>>
>> ex_wtr2 :: Wtr Int [String]
>> ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)]
>>
>> ex_inputs :: [Int]
>> ex_inputs = [1..10000000]
>>
>> ex_logger = mempty <> logCount 300000 ex_wtr <> mempty                 --<2--
>> -- ex_logger = logCount 300000 ex_wtr
>>
>>
>> ex_main = do
>>     timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs
>>
>> main = ex_main
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
> 
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


From johannes.waldmann at htwk-leipzig.de  Thu Nov 19 21:27:34 2015
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Thu, 19 Nov 2015 22:27:34 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
Message-ID: <564E3EC6.1020801@htwk-leipzig.de>

Because of AMP, I have to rewrite slides and example code
for my lectures, and I don't like it.

In fact I probably won't do it, and will advise students
to return to ghc-7.8 - but then, how does that look?


Really, my answer to

  [1] 3.5 Beginner friendliness
  How often did you say ... "A Monad is always an Applicative"

is: never. (for "is a Functor" - often. In fact, always)


Now, I don't want to bring on another general discussion of AMP -
instead I'd like to hear from people who use monads
in teaching (e.g., to define semantic domains)
about how they sell "Applicative m =>"  to their students.
(The intersection of AMPers and teachers is non-empty?)


- Johannes


[1] https://wiki.haskell.org/Functor-Applicative-Monad_Proposal


From atzeus at gmail.com  Thu Nov 19 22:54:14 2015
From: atzeus at gmail.com (Atze van der Ploeg)
Date: Thu, 19 Nov 2015 23:54:14 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564E2ABC.3030206@web.de>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
Message-ID: <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>

Maybe it is due to using lists and ++? Thats a well know inefficiency.
On Nov 19, 2015 9:06 PM, "martin" <martin.drautzburg at web.de> wrote:

> I just tried both strict pairs and seq, and it didn't change anything.
> Also, wouldn't then THUNKS consume a lot of
> memory in my heap profile? I forgot to mention that this is not the case.
> Max heap is around 35k and the top-consumer
> is ARR_WORDS. THUNK is below 1k.
>
> I am going though 10,000,000 iterations and if anything would pile up, it
> would consume at least one byte per iteration,
> wouldn't it? But I can't see 10 MBytes anywhere. It looks as if the time
> is really spent on *computing* something.
>
> Am 11/19/2015 um 07:15 PM schrieb Roman Cheplyaka:
> > My guess is that you have accumulating thunks inside your (Int,a) tuple.
> > Be sure to force them (by using a strict pair type, bang patterns, or
> > however else).
> >
> > On 11/19/2015 07:18 PM, martin wrote:
> >> Hello all,
> >>
> >> I wrote a Logger which, under certain conditions, prepends log-entries
> to a log and a Monoid instance of it. But as soon
> >> as I mappend two Loggers my performance drops by 50%. This even happens
> when I mappend  mempty as shown below in --<2--.
> >> I understand that the system has to do *something*, but it seems to
> cost a bit much. Without the strictness annotation
> >> in --<1-- the performance degradation is even more dramatic (orders of
> magnitude).
> >>
> >> The profile tells me that more that 50% of the time is spent in mappend.
> >>
> >> COST CENTRE  MODULE    %time %alloc
> >>
> >> mappend.\    Logger     50.6   35.8
> >> logCount'.f  Logger     18.7   40.3
> >> logCount'    Logger      5.4    0.0
> >>
> >> Why is that so, and can I do anything about it?  I am willing to change
> the overall design if required.
> >>
> >>
> >> This is the code
> >>
> >> -- | A writer does the formatting
> >> newtype Wtr a log = Wtr {runWtr :: a -> log}
> >>
> >> -- | A looger is a writer plus an internal state
> >> data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)}
> >>
> >> instance Monoid (Logger a log) where
> >>         mempty = Lgr (\_ l -> (l,mempty))
> >>         mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') =
> runLogger lgr1 a l      --<1--
> >>                                               !(log2',!lgr2') =
> runLogger lgr2 a log1'  --<1--
> >>                                           in (log2', mappend lgr1'
> lgr2')
> >>
> >>
> >> and this is how I test it
> >>
> >> -- | Count calls __s__ and write log when s has reached nxt and then
> every dn calls
> >> logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log ->
> Logger a log
> >> logCount' dn nxt s wtr = Lgr f
> >>         where
> >>             f a l = if s == nxt
> >>                        then (runWtr wtr (s,a)  <> l, logCount'  dn
> (nxt+dn) (s+1) wtr)
> >>                        else (l,                      logCount'  dn nxt
>     (s+1) wtr)
> >>
> >>
> >> -- | Count calls and write log every dn calls
> >> logCount dn = logCount' dn dn 0
> >>
> >>
> >> -- testLogger :: Logger Int Int [String] -> [String]
> >> testLogger lgr xs = fst $ foldl' f ([],lgr) xs
> >>         where
> >>             f (log', lgr') x = runLogger lgr' x log'
> >>
> >> ex_wtr :: Wtr (Int,a) [String]
> >> ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)]
> >>
> >> ex_wtr2 :: Wtr Int [String]
> >> ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)]
> >>
> >> ex_inputs :: [Int]
> >> ex_inputs = [1..10000000]
> >>
> >> ex_logger = mempty <> logCount 300000 ex_wtr <> mempty
>  --<2--
> >> -- ex_logger = logCount 300000 ex_wtr
> >>
> >>
> >> ex_main = do
> >>     timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs
> >>
> >> main = ex_main
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151119/15a180f6/attachment.html>

From tmorris at tmorris.net  Thu Nov 19 23:59:24 2015
From: tmorris at tmorris.net (Tony Morris)
Date: Fri, 20 Nov 2015 09:59:24 +1000
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <564E3EC6.1020801@htwk-leipzig.de>
References: <564E3EC6.1020801@htwk-leipzig.de>
Message-ID: <CAJf6UsgEs6+MpcLaUTkdz--f5CHTxknn6rs7gR8cRuL8q0i_kg@mail.gmail.com>

I have had to work around AMP not existing since 2006 in teaching. Thank
goodness it is finally here and my students are no longer confused.

That's how.

On Fri, Nov 20, 2015 at 7:27 AM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Because of AMP, I have to rewrite slides and example code
> for my lectures, and I don't like it.
>
> In fact I probably won't do it, and will advise students
> to return to ghc-7.8 - but then, how does that look?
>
>
> Really, my answer to
>
>   [1] 3.5 Beginner friendliness
>   How often did you say ... "A Monad is always an Applicative"
>
> is: never. (for "is a Functor" - often. In fact, always)
>
>
> Now, I don't want to bring on another general discussion of AMP -
> instead I'd like to hear from people who use monads
> in teaching (e.g., to define semantic domains)
> about how they sell "Applicative m =>"  to their students.
> (The intersection of AMPers and teachers is non-empty?)
>
>
> - Johannes
>
>
> [1] https://wiki.haskell.org/Functor-Applicative-Monad_Proposal
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/c8c27be4/attachment.html>

From targen at gmail.com  Fri Nov 20 01:30:47 2015
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Thu, 19 Nov 2015 21:00:47 -0430
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <564E3EC6.1020801@htwk-leipzig.de>
References: <564E3EC6.1020801@htwk-leipzig.de>
Message-ID: <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>

On Thu, Nov 19, 2015 at 4:57 PM, Johannes Waldmann
<johannes.waldmann at htwk-leipzig.de> wrote:
> Now, I don't want to bring on another general discussion of AMP -

That?s a curious way to frame your e-mail if this indeed is not your
intent, but alright.

> instead I'd like to hear from people who use monads
> in teaching (e.g., to define semantic domains)
> about how they sell "Applicative m =>"  to their students.

I have almost always taught monads as if Applicative was a superclass of
Monad.  The strategy with which I?ve had most success is to begin
describing functors as a general notion of typed computational
contexts that are polymorphic in the type of the value produced by the
computation, and that may have effects in the context of the
computation that go beyond merely computing a value.  The word
?effect? is sadly suggestive of IO, and perhaps using terms like
?semantic domain? instead of ?computational context? and ?effect? may
be more universal, but it turns out to be effective.  I avoid using IO
as an example of a functor until the very end of the lessons on the
topic of monads in an attempt to counter that unfortunate suggestion
of imperative interpretation; I also avoid mentioning ?return? until
the very end.

After explaining Functors with examples on Identity, Maybe, Either,
Reader and lists, we move on to the notion of an Applicative with the
same examples, and finally the notion of a Monad with the same
examples.  The three classes are distinguished by their expanding
APIs, and it?s helpful, if you have enough time for the lesson, to
show types that are Functor but not Applicative (e.g. ?(,) e?).  I
haven?t found a helpful example of an Applicative that is not a Monad
that is practical for a lesson.

After that, I present interesting terms to specify complex computation
using ?fmap?, ?<$>?, ?<*>?, ?pure? and ?>>=?/?=<<?, and finally, I
introduce do notation as a nice way of writing chained monadic
computations, usually with examples based on ?Data.Map.lookup?.
Finally, I mention ?return? exists as an alias of ?pure? (even though
it really is part of the class ? I wish that it wasn?t and it?s hard
to explain why it?s even there in the first place) and caution against
using it as the imperative pun may mislead their intuition (my Haskell
students are in their third year of the CS program, and they?ve done a
lot of imperative programming by then).

We usually cover IO in a later, separate session.  A couple other
times we?ve tried doing IO first and the Functor/Applicative/Monad
hierarchy later, but students seemed to end up more confused with that
strategy (anecdotically, of course).

> (The intersection of AMPers and teachers is non-empty?)

I used to have to explain the superclass should have been there but
wasn?t for historical reasons, and that led to some time being wasted,
and some extra, unnecessary confusion.  That?s fixed now, and that
particularly difficult lesson is now a bit less confusing.  I?m very
happy that this was finally fixed, and not having to explain that
awful old situation frees up some time so I can present more examples
of monad instances and monadic computations, and explain them in
greater depth.

From mail at joachim-breitner.de  Fri Nov 20 08:22:47 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 20 Nov 2015 09:22:47 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
Message-ID: <1448007767.1537.5.camel@joachim-breitner.de>

Hi,

thanks for your mail! I am circulating it to my Haskell teaching
colleagues, who are facing the same challenges as Johannes.

Am Donnerstag, den 19.11.2015, 21:00 -0430 schrieb Manuel G?mez:
> The three classes are distinguished by their expanding
> APIs, and it?s helpful, if you have enough time for the lesson, to
> show types that are Functor but not Applicative (e.g. ?(,) e?).

There is the instance
    Monoid a => Applicative ((,) a)
Do you touch upon that, or pretend it is not there?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/7c972111/attachment.sig>

From epsilonhalbe at gmail.com  Fri Nov 20 09:21:07 2015
From: epsilonhalbe at gmail.com (Martin Heuschober)
Date: Fri, 20 Nov 2015 10:21:07 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <1448007767.1537.5.camel@joachim-breitner.de>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <1448007767.1537.5.camel@joachim-breitner.de>
Message-ID: <CAPNZE+oDDZABNWPwpQ=aY6vtL5k0jvsAbZ-QW=fo=U1p1c+maw@mail.gmail.com>

I just recently had a presentation at my local usergroup
(Lambdaheads/Vienna) where I introduced the problem of `null` values and
the functional solution of using functor, applicative and monad to solve
this.

The slides are available -
https://github.com/epsilonhalbe/Talks/tree/master/20151021-LH-Func - if you
have comments on them, I'd be glad to hear, during the meetup we had quite
a discussion about it, but in the end I think everyone agreed that those
abstractions are handy and quite natural in their origination.

the tldr of it is:
that in functional languages, one major point of doing things is function
composition and to introduce new functions (in this case operators) to
solve the problem when domains do not match properly, i.e. to put the
complicated part in the composition and not bother the programmer with it.

I think the "excuse" for `return` existing is historical which I think is
no bad thing to say when teaching, because it makes students aware that
everything is being improved over time and that they might be the ones
helping.

Cheers Martin

2015-11-20 9:22 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:

> Hi,
>
> thanks for your mail! I am circulating it to my Haskell teaching
> colleagues, who are facing the same challenges as Johannes.
>
> Am Donnerstag, den 19.11.2015, 21:00 -0430 schrieb Manuel G?mez:
> > The three classes are distinguished by their expanding
> > APIs, and it?s helpful, if you have enough time for the lesson, to
> > show types that are Functor but not Applicative (e.g. ?(,) e?).
>
> There is the instance
>     Monoid a => Applicative ((,) a)
> Do you touch upon that, or pretend it is not there?
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/f233ebe6/attachment.html>

From martin.drautzburg at web.de  Fri Nov 20 09:18:46 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 20 Nov 2015 10:18:46 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
 <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
Message-ID: <564EE576.8020903@web.de>

(++) is only used in the Wtrs themselves, but these are only called when I am actually logging something, which is only
a handful of lines. Adding an mempty Logger does not change the number of lines written but does change the execution
time. So I don't think this is it.

I have the feeling the slowdown originates from mappend being called each time an x is consumed, i.e. the Logger which
results from mappending individual Loggers gets constructed over and over again. With this design it has to be this way,
because my Loggers carry an internal state (the criteria when to log and when not to) which can change. However in most
cases the state does not change. I guess my design does "not know" this and blindly re-executes mappend over and over.
But I don't know how design it differently.


Am 11/19/2015 um 11:54 PM schrieb Atze van der Ploeg:
> Maybe it is due to using lists and ++? Thats a well know inefficiency.
> 
> On Nov 19, 2015 9:06 PM, "martin" <martin.drautzburg at web.de <mailto:martin.drautzburg at web.de>> wrote:
> 
>     I just tried both strict pairs and seq, and it didn't change anything. Also, wouldn't then THUNKS consume a lot of
>     memory in my heap profile? I forgot to mention that this is not the case. Max heap is around 35k and the top-consumer
>     is ARR_WORDS. THUNK is below 1k.
> 
>     I am going though 10,000,000 iterations and if anything would pile up, it would consume at least one byte per iteration,
>     wouldn't it? But I can't see 10 MBytes anywhere. It looks as if the time is really spent on *computing* something.
> 
>     Am 11/19/2015 um 07:15 PM schrieb Roman Cheplyaka:
>     > My guess is that you have accumulating thunks inside your (Int,a) tuple.
>     > Be sure to force them (by using a strict pair type, bang patterns, or
>     > however else).
>     >
>     > On 11/19/2015 07:18 PM, martin wrote:
>     >> Hello all,
>     >>
>     >> I wrote a Logger which, under certain conditions, prepends log-entries to a log and a Monoid instance of it. But
>     as soon
>     >> as I mappend two Loggers my performance drops by 50%. This even happens when I mappend  mempty as shown below in
>     --<2--.
>     >> I understand that the system has to do *something*, but it seems to cost a bit much. Without the strictness
>     annotation
>     >> in --<1-- the performance degradation is even more dramatic (orders of magnitude).
>     >>
>     >> The profile tells me that more that 50% of the time is spent in mappend.
>     >>
>     >> COST CENTRE  MODULE    %time %alloc
>     >>
>     >> mappend.\    Logger     50.6   35.8
>     >> logCount'.f  Logger     18.7   40.3
>     >> logCount'    Logger      5.4    0.0
>     >>
>     >> Why is that so, and can I do anything about it?  I am willing to change the overall design if required.
>     >>
>     >>
>     >> This is the code
>     >>
>     >> -- | A writer does the formatting
>     >> newtype Wtr a log = Wtr {runWtr :: a -> log}
>     >>
>     >> -- | A looger is a writer plus an internal state
>     >> data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)}
>     >>
>     >> instance Monoid (Logger a log) where
>     >>         mempty = Lgr (\_ l -> (l,mempty))
>     >>         mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') = runLogger lgr1 a l      --<1--
>     >>                                               !(log2',!lgr2') = runLogger lgr2 a log1'  --<1--
>     >>                                           in (log2', mappend lgr1' lgr2')
>     >>
>     >>
>     >> and this is how I test it
>     >>
>     >> -- | Count calls __s__ and write log when s has reached nxt and then every dn calls
>     >> logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log -> Logger a log
>     >> logCount' dn nxt s wtr = Lgr f
>     >>         where
>     >>             f a l = if s == nxt
>     >>                        then (runWtr wtr (s,a)  <> l, logCount'  dn (nxt+dn) (s+1) wtr)
>     >>                        else (l,                      logCount'  dn nxt      (s+1) wtr)
>     >>
>     >>
>     >> -- | Count calls and write log every dn calls
>     >> logCount dn = logCount' dn dn 0
>     >>
>     >>
>     >> -- testLogger :: Logger Int Int [String] -> [String]
>     >> testLogger lgr xs = fst $ foldl' f ([],lgr) xs
>     >>         where
>     >>             f (log', lgr') x = runLogger lgr' x log'
>     >>
>     >> ex_wtr :: Wtr (Int,a) [String]
>     >> ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)]
>     >>
>     >> ex_wtr2 :: Wtr Int [String]
>     >> ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)]
>     >>
>     >> ex_inputs :: [Int]
>     >> ex_inputs = [1..10000000]
>     >>
>     >> ex_logger = mempty <> logCount 300000 ex_wtr <> mempty                 --<2--
>     >> -- ex_logger = logCount 300000 ex_wtr
>     >>
>     >>
>     >> ex_main = do
>     >>     timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs
>     >>
>     >> main = ex_main
>     >> _______________________________________________
>     >> Haskell-Cafe mailing list
>     >> Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     >>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Haskell-Cafe mailing list
>     > Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     >
> 
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Fri Nov 20 09:31:28 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 20 Nov 2015 09:31:28 +0000
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564EE576.8020903@web.de>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
 <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
 <564EE576.8020903@web.de>
Message-ID: <20151120093128.GA13789@weber>

On Fri, Nov 20, 2015 at 10:18:46AM +0100, martin wrote:
> (++) is only used in the Wtrs themselves, but these are only called when I am actually logging something, which is only
> a handful of lines. Adding an mempty Logger does not change the number of lines written but does change the execution
> time. So I don't think this is it.

Surely every call logs *something* even if it's []?

From hesselink at gmail.com  Fri Nov 20 09:31:48 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Fri, 20 Nov 2015 10:31:48 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
Message-ID: <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>

On 20 November 2015 at 02:30, Manuel G?mez <targen at gmail.com> wrote:
> I haven?t found a helpful example of an Applicative that is not a Monad
> that is practical for a lesson.

There's ZipList [0], which depending on the type of audience might be
doable. There's also Const [1], but that needs a Monoid constraint,
and since you said you considered ((,) e) as not having an
Applicative, which it does have with a Monoid constraint, perhaps
Const isn't suitable to you for that reason. There are more
interesting examples here [2].

Erik

[0] https://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
[1] http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#v:Const
[2] http://stackoverflow.com/questions/7220436/good-examples-of-not-a-functor-functor-applicative-monad

From oleg.grenrus at iki.fi  Fri Nov 20 10:02:13 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 20 Nov 2015 12:02:13 +0200
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
Message-ID: <B9B02F1D-3FBF-43E0-B1F8-D5AB622FE756@iki.fi>


> On 20 Nov 2015, at 11:31, Erik Hesselink <hesselink at gmail.com> wrote:
> 
> On 20 November 2015 at 02:30, Manuel G?mez <targen at gmail.com> wrote:
>> I haven?t found a helpful example of an Applicative that is not a Monad
>> that is practical for a lesson.
> 
> There's ZipList [0], which depending on the type of audience might be
> doable. There's also Const [1], but that needs a Monoid constraint,
> and since you said you considered ((,) e) as not having an
> Applicative, which it does have with a Monoid constraint, perhaps
> Const isn't suitable to you for that reason. There are more
> interesting examples here [2].
> 
> Erik
> 
> [0] https://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#t:ZipList
> [1] http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Applicative.html#v:Const
> [2] http://stackoverflow.com/questions/7220436/good-examples-of-not-a-functor-functor-applicative-monad
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

There are also (which I find actually useful):

-  `Concurrently = Concurrently (IO a)` which is Monad only IO effects are commutative. [3]
    - one can argue that Applicative and Monad instances aren?t compatible
- `Errors` [4], which could be specialised to `Either (NonEmpty err) a` and `ap` would gather all errors!
    - and of course `Lift` using which `Errors` is defined.

[3] https://hackage.haskell.org/package/async-2.0.2/docs/Control-Concurrent-Async.html#t:Concurrently <https://hackage.haskell.org/package/async-2.0.2/docs/Control-Concurrent-Async.html#t:Concurrently>
[4] https://hackage.haskell.org/package/transformers-0.4.3.0/docs/Control-Applicative-Lift.html#t:Errors <https://hackage.haskell.org/package/transformers-0.4.3.0/docs/Control-Applicative-Lift.html#t:Errors>

- Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/7814cb65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/7814cb65/attachment.sig>

From mail at joachim-breitner.de  Fri Nov 20 10:15:43 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 20 Nov 2015 11:15:43 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <B9B02F1D-3FBF-43E0-B1F8-D5AB622FE756@iki.fi>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
 <B9B02F1D-3FBF-43E0-B1F8-D5AB622FE756@iki.fi>
Message-ID: <1448014543.1537.13.camel@joachim-breitner.de>

Hi,

Am Freitag, den 20.11.2015, 12:02 +0200 schrieb Oleg Grenrus:
> - `Errors` [4], which could be specialised to `Either (NonEmpty err)
> a` and `ap` would gather all errors!

this is actually a pretty nice and convincing example: ?A effectful
computation (e.g. a stateless parser) that may fail in various spots
with errors, where the type system can guarantee that _all_ errors will
be reported (and not just the first found).??

Obviously a Monad cannot provide this guarantee, and obviously, there
are applications where this is impossible, so this nicely shows the
usefulness of Applicative as a separate abstraction.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/5052e8c2/attachment.sig>

From martin.drautzburg at web.de  Fri Nov 20 10:19:35 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 20 Nov 2015 11:19:35 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <20151120093128.GA13789@weber>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
 <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
 <564EE576.8020903@web.de> <20151120093128.GA13789@weber>
Message-ID: <564EF3B7.2060608@web.de>

Am 11/20/2015 um 10:31 AM schrieb Tom Ellis:
> On Fri, Nov 20, 2015 at 10:18:46AM +0100, martin wrote:
>> (++) is only used in the Wtrs themselves, but these are only called when I am actually logging something, which is only
>> a handful of lines. Adding an mempty Logger does not change the number of lines written but does change the execution
>> time. So I don't think this is it.
> 
> Surely every call logs *something* even if it's []?

Not really. If nothing gets logged, then my loggers return the original log. There is no (++) involved, not even a ([]
++ log). The cost should only be the cost of checking the condition.

logCount' :: Monoid log => Int -> Int -> Int ->  Wtr (Int,a) log -> Logger a log
logCount' dn nxt s wtr = Lgr f
        where
            f a l = if s == nxt
                    then (runWtr wtr (s,a)  <> l, logCount'  dn (nxt+dn) (s+1) wtr)
                    else (l,                      logCount'  dn nxt      (s+1) wtr)


From roma at ro-che.info  Fri Nov 20 10:33:06 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 20 Nov 2015 12:33:06 +0200
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564EF3B7.2060608@web.de>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
 <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
 <564EE576.8020903@web.de> <20151120093128.GA13789@weber>
 <564EF3B7.2060608@web.de>
Message-ID: <564EF6E2.2000404@ro-che.info>

On 11/20/2015 12:19 PM, martin wrote:
> Am 11/20/2015 um 10:31 AM schrieb Tom Ellis:
>> On Fri, Nov 20, 2015 at 10:18:46AM +0100, martin wrote:
>>> (++) is only used in the Wtrs themselves, but these are only called when I am actually logging something, which is only
>>> a handful of lines. Adding an mempty Logger does not change the number of lines written but does change the execution
>>> time. So I don't think this is it.
>>
>> Surely every call logs *something* even if it's []?
> 
> Not really. If nothing gets logged, then my loggers return the original log. There is no (++) involved, not even a ([]
> ++ log). The cost should only be the cost of checking the condition.

Even for mempty, you're still recursively mappending the "tails" of the
loggers. How about introducing a designated constructor for mempty to
avoid that recursive mappend? (The same constructor will be used when a
logger is "done" and is known not to produce any further output.)

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/5668dcde/attachment-0001.sig>

From martin.drautzburg at web.de  Fri Nov 20 11:14:34 2015
From: martin.drautzburg at web.de (martin)
Date: Fri, 20 Nov 2015 12:14:34 +0100
Subject: [Haskell-cafe] Why is my mappend so slow?
In-Reply-To: <564EF6E2.2000404@ro-che.info>
References: <564E0479.3060203@web.de> <564E11B1.5070900@ro-che.info>
 <564E2ABC.3030206@web.de>
 <CAGigdofCALToodoE3LhmXw3U+4kojqBW6EivMDCsZTi7+7ULMA@mail.gmail.com>
 <564EE576.8020903@web.de> <20151120093128.GA13789@weber>
 <564EF3B7.2060608@web.de> <564EF6E2.2000404@ro-che.info>
Message-ID: <564F009A.80704@web.de>

Am 11/20/2015 um 11:33 AM schrieb Roman Cheplyaka:
> On 11/20/2015 12:19 PM, martin wrote:
>> Am 11/20/2015 um 10:31 AM schrieb Tom Ellis:
>>> On Fri, Nov 20, 2015 at 10:18:46AM +0100, martin wrote:
>>>> (++) is only used in the Wtrs themselves, but these are only called when I am actually logging something,
>>>> which is only a handful of lines. Adding an mempty Logger does not change the number of lines written but
>>>> does change the execution time. So I don't think this is it.
>>> 
>>> Surely every call logs *something* even if it's []?
>> 
>> Not really. If nothing gets logged, then my loggers return the original log. There is no (++) involved, not even
>> a ([] ++ log). The cost should only be the cost of checking the condition.
> 
> Even for mempty, you're still recursively mappending the "tails" of the loggers. How about introducing a designated
> constructor for mempty to avoid that recursive mappend? (The same constructor will be used when a logger is "done"
> and is known not to produce any further output.)

This is probably the root cause, and your sugestion would probably solve the slowness of (<> mempty) and (mempty <>).

But for a Logger which just produces no output "for now" it still wouldn't help, would it? E.g. if I want to log every
n invocations, then a Logger will produce output at invocation n and then no output for invocations n+1 .. 2n -1, and
produce output at 2n again. It can never become an mempty.

This is actually the original problem which triggered it all. But my current design is overly costly. I cannnot seem
to express "if the condition does not hold, do nothing" propery.


From tonymorris at gmail.com  Fri Nov 20 12:20:03 2015
From: tonymorris at gmail.com (Tony Morris)
Date: Fri, 20 Nov 2015 22:20:03 +1000
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <1448014543.1537.13.camel@joachim-breitner.de>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
 <B9B02F1D-3FBF-43E0-B1F8-D5AB622FE756@iki.fi>
 <1448014543.1537.13.camel@joachim-breitner.de>
Message-ID: <564F0FF3.1060306@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 20/11/15 20:15, Joachim Breitner wrote:
> Hi,
> 
> Am Freitag, den 20.11.2015, 12:02 +0200 schrieb Oleg Grenrus:
>> - `Errors` [4], which could be specialised to `Either (NonEmpty
>> err) a` and `ap` would gather all errors!
> 
> this is actually a pretty nice and convincing example: ?A
> effectful computation (e.g. a stateless parser) that may fail in
> various spots with errors, where the type system can guarantee that
> _all_ errors will be reported (and not just the first found).?
> 

It's a pretty nice example of further splitting of the type-class
hierarchy, since if given,

instance Monoid a => Applicative (Either a) where
  -- we gather all the errors

then we could not have Either (NonEmpty err), since (NonEmpty err)
does not have a Monoid, only a binary, associative operation (Semigroup)
.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWTw/vAAoJEFkczQCvdvv0T4cH/28/pj2xqaRDHAGtoLF5mnLA
phbQ9J3mbbdmTQLlx5Rp77VCBV2BvjLe4gu+sCz+Qb/cvXo9lsCpJUCZFMP6CMSF
HMLD6hxZqCTyKu0/47Lmrh6AvkWFQ/YG2N99ZK4el3omoRXsBbGTxwOUBAPm5jZZ
94X6Q5jFoHOqCmeL1I7GTyx4IhnzOeMb2vTJvaiDbNUelu34ZzyzPLpaLA5uxnoC
G3MZNUeHX3USPzhg2KOwno6NNmHO8E8p90TiUWriLCjr8x6VqYj+5tNx6IVamA61
0nIE2BQo/D6n8Zr+LxWmVKoaC1QK/K5wGONmIcZRDCl6IW1aGD4XkuHcWGhnQqg=
=A8/9
-----END PGP SIGNATURE-----

From mail at joachim-breitner.de  Fri Nov 20 12:33:45 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 20 Nov 2015 13:33:45 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <564F0FF3.1060306@gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
 <B9B02F1D-3FBF-43E0-B1F8-D5AB622FE756@iki.fi>
 <1448014543.1537.13.camel@joachim-breitner.de> <564F0FF3.1060306@gmail.com>
Message-ID: <1448022825.1537.21.camel@joachim-breitner.de>

Hi,

Am Freitag, den 20.11.2015, 22:20 +1000 schrieb Tony Morris:
> It's a pretty nice example of further splitting of the type-class
> hierarchy, since if given,
> 
> instance Monoid a => Applicative (Either a) where
> ? -- we gather all the errors
> 
> then we could not have Either (NonEmpty err), since (NonEmpty err)
> does not have a Monoid, only a binary, associative operation
> (Semigroup)

I believe that there are plans to move Semigroup into Base. Eventually,
there will be a transition to Monoid having Semigroup as a superclass?,
and I guess then the instance can be changed to?
    instance Monoid a => Applicative (Either a) where
and that worry is gone.

Greetings,
Joachim

??https://ghc.haskell.org/trac/ghc/ticket/10365?and
??https://ghc.haskell.org/trac/ghc/wiki/Proposal/SemigroupMonoid


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/7b772512/attachment.sig>

From strake888 at gmail.com  Fri Nov 20 15:51:49 2015
From: strake888 at gmail.com (M Farkas-Dyck)
Date: Fri, 20 Nov 2015 07:51:49 -0800
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
Message-ID: <CAL3m8eCf1jR6Hw=sp5220GiXCxjuq3ORDM6WKyOW9Y3SrnFJpw@mail.gmail.com>

On 19/11/2015, Manuel G?mez <targen at gmail.com> wrote:
> I haven?t found a helpful example of an Applicative that is not a Monad
> that is practical for a lesson.

I like this one: https://hackage.haskell.org/package/regex-applicative

From cma at bitemyapp.com  Fri Nov 20 16:15:48 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 20 Nov 2015 10:15:48 -0600
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAL3m8eCf1jR6Hw=sp5220GiXCxjuq3ORDM6WKyOW9Y3SrnFJpw@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAL3m8eCf1jR6Hw=sp5220GiXCxjuq3ORDM6WKyOW9Y3SrnFJpw@mail.gmail.com>
Message-ID: <CADnndOpmC46z6h6upJ7m4sEHEMy2CaOxH8pX+8=E34p=zyxmQg@mail.gmail.com>

I'm partial to hackage.haskell.org/package/validation myself :)

On Fri, Nov 20, 2015 at 9:51 AM, M Farkas-Dyck <strake888 at gmail.com> wrote:

> On 19/11/2015, Manuel G?mez <targen at gmail.com> wrote:
> > I haven?t found a helpful example of an Applicative that is not a Monad
> > that is practical for a lesson.
>
> I like this one: https://hackage.haskell.org/package/regex-applicative
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/637f4c1d/attachment.html>

From johnw at newartisans.com  Fri Nov 20 17:44:00 2015
From: johnw at newartisans.com (John Wiegley)
Date: Fri, 20 Nov 2015 09:44:00 -0800
Subject: [Haskell-cafe] ANN: linearscan, linearscan-hoopl 1.0.0
Message-ID: <m2r3jky3a7.fsf@newartisans.com>

linearscan[1] is a linear scan register allocator[2], written in Coq[3], and
extracted to Haskell, as a library for Haskell programs that need to allocate
registers. It may also be used directly from Coq.

This project is the result of a year-long effort, funded by BAE Systems[4], to
explore the application of dependent-types and mathematical verification to a
typical engineering task. During the course of construction, several hundred
theorems about the code were proven -- although exhaustive coverage was not,
in the end, achievable given our time constraints. To remedy this, and as a
test of the extraction to Haskell, an optional runtime verifier was built to
certify the resulting allocations.

Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that
version[7]. linearscan further relies on another library, coq-haskell[8], that
I created to facilitate inter-operation between Haskell and Coq.

For those using Hoopl[9] to represent program graphs, incorporating linearscan
is quite easy: provide an instance of NodeAlloc using the linearscan-hoopl[10]
library. Examples of doing so are provided in the test suite for that library.

The allocation algorithm implemented by this library was first written in Java
by Hanspeter M?ssenb?ck and Michael Pfeiffer[11], and later improved upon by
Christian Wimmer[12], whose master's thesis provided the specification for our
implementation.

John Wiegley
BAE Systems

Footnotes: 
[1]  http://hackage.haskell.org/package/linearscan

[2]  http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf

[3]  https://coq.inria.fr/

[4]  http://www.baesystems.com/en-us/our-company/inc-businesses/electronic-systems/research-advanced-development/about-r-and-ad

[5]  https://coq.inria.fr/news/125.html

[6]  http://ssr.msr-inria.inria.fr/

[7]  http://ssr.msr-inria.inria.fr/FTP/

[8]  https://github.com/jwiegley/coq-haskell

[9]  https://hackage.haskell.org/package/hoopl

[10]  http://hackage.haskell.org/package/linearscan-hoopl

[11]  http://dl.acm.org/citation.cfm?id=647478.727924

[12]  http://www.christianwimmer.at/Publications/Wimmer04a/


From ky3 at atamo.com  Fri Nov 20 17:53:10 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Sat, 21 Nov 2015 00:53:10 +0700
Subject: [Haskell-cafe] On Hiatus Until January 2016: Haskell Weekly News
Message-ID: <CAPY+ZdQSY25Ob0XKrGkcxBkosnE8szkuj5jDLsK55E6sQc8j6A@mail.gmail.com>

Regrettably, I must announce that Haskell Weekly News will go on hiatus
until the new year.

I recognize that the last issue was back in September. It's been said that
"The more a man possesses over and above what he uses, the more careworn he
becomes." In my case, mundane possessions have indeed insisted on being
attended to.

I wish every reader a fine holiday season.

-- Kim-Ee
Editor of Haskell Weekly News
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151121/72805695/attachment.html>

From manny at fpcomplete.com  Fri Nov 20 19:49:49 2015
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 20 Nov 2015 19:49:49 +0000
Subject: [Haskell-cafe] ANN: stack-0.1.8.0
Message-ID: <CACGj5vK3EE00BLDbVnrZQqAa927KLkg4dGeYQJOOhsWMy7b-3g@mail.gmail.com>

New version released of Stack, a build tool.

See README
<https://github.com/commercialhaskell/stack/tree/release#how-to-install>
for installation and upgrade instructions.

There are now Windows installers available: download them here
<https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md#windows>.
In addition, new Fedora 23 packages are available here
<https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md#fedora>
.

Note that, starting with v0.1.8.0, releases of Stack will always have an
even-numbered second-to-last version component. Odd second-to-last version
components are reserved for unstable builds.

Major changes:

   - GHCJS can now be used with stackage snapshots via the new compiler
   field.
   - Docker integration works with non-FP Complete generated images
   #531 <https://github.com/commercialhaskell/stack/issues/531>

Other enhancements:

   - Added an allow-newer config option
   #922 <https://github.com/commercialhaskell/stack/issues/922>
   #770 <https://github.com/commercialhaskell/stack/issues/770>
   - When a Hackage revision invalidates a build plan in a snapshot, trust
   the
   snapshot #770 <https://github.com/commercialhaskell/stack/issues/770>
   - Added a stack config set resolver RESOLVER command. Part of work on
   #115 <https://github.com/commercialhaskell/stack/issues/115>
   - stack setup can now install GHCJS on windows. See
   #1145 <https://github.com/commercialhaskell/stack/issues/1145> and
   #749 <https://github.com/commercialhaskell/stack/issues/749>
   - stack hpc report command added, which generates reports for HPC tix
   files
   - stack ghci now accepts all the flags accepted by stack build. See
   #1186 <https://github.com/commercialhaskell/stack/issues/1186>
   - stack ghci builds the project before launching GHCi. If the build
   fails,
   optimistically launch GHCi anyway. Use stack ghci --no-build option to
   disable #1065 <https://github.com/commercialhaskell/stack/issues/1065>
   - stack ghci now detects and warns about various circumstances where it
   is
   liable to fail. See
   #1270 <https://github.com/commercialhaskell/stack/issues/1270>
   - Added require-docker-version configuration option
   - Packages will now usually be built along with their tests and
   benchmarks. See
   #1166 <https://github.com/commercialhaskell/stack/issues/1166>
   - Relative local-bin-path paths will be relative to the project?s root
   directory, not the current working directory.
   #1340 <https://github.com/commercialhaskell/stack/issues/1340>
   - stack clean now takes an optional [PACKAGE] argument for use in
   multi-package projects. See
   #583 <https://github.com/commercialhaskell/stack/issues/583>
   - Ignore cabal_macros.h as a dependency
   #1195 <https://github.com/commercialhaskell/stack/issues/1195>
   - Pad timestamps and show local time in ?verbose output
   #1226 <https://github.com/commercialhaskell/stack/issues/1226>
   - GHCi: Import all modules after loading them
   #995 <https://github.com/commercialhaskell/stack/issues/995>
   - Add subcommand aliases: repl for ghci, and runhaskell for runghc
   #1241 <https://github.com/commercialhaskell/stack/issues/1241>
   - Add typo recommendations for unknown package identifiers
   #158 <https://github.com/commercialhaskell/stack/issues/158>
   - Add stack path --local-hpc-root option
   - Overhaul dependencies? haddocks copying
   #1231 <https://github.com/commercialhaskell/stack/issues/1231>
   - Support for extra-package-dbs in ?stack ghci?
   #1229 <https://github.com/commercialhaskell/stack/pull/1229>
   - stack new disallows package names with ?words? consisting solely of
   numbers
   #1336 <https://github.com/commercialhaskell/stack/issues/1336>
   - stack build --fast turns off optimizations

Bug fixes:

   - Fix: Haddocks not copied for dependencies
   #1105 <https://github.com/commercialhaskell/stack/issues/1105>
   - Fix: Global options did not work consistently after subcommand
   #519 <https://github.com/commercialhaskell/stack/issues/519>
   - Fix: ?stack ghci? doesn?t notice that a module got deleted
   #1180 <https://github.com/commercialhaskell/stack/issues/1180>
   - Rebuild when cabal file is changed
   - Fix: Paths in GHC warnings not canonicalized, nor those for packages in
   subdirectories or outside the project root
   #1259 <https://github.com/commercialhaskell/stack/issues/1259>
   - Fix: unlisted files in tests and benchmarks trigger extraneous second
   build
   #838 <https://github.com/commercialhaskell/stack/issues/838>

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/52dd1135/attachment.html>

From heraldhoi at gmail.com  Fri Nov 20 20:22:59 2015
From: heraldhoi at gmail.com (Geraldus)
Date: Fri, 20 Nov 2015 20:22:59 +0000
Subject: [Haskell-cafe] ANN: stack-0.1.8.0
In-Reply-To: <CACGj5vK3EE00BLDbVnrZQqAa927KLkg4dGeYQJOOhsWMy7b-3g@mail.gmail.com>
References: <CACGj5vK3EE00BLDbVnrZQqAa927KLkg4dGeYQJOOhsWMy7b-3g@mail.gmail.com>
Message-ID: <CAB2YT56nTq6=NTLTDJ6R0QXR4xCfzobZ9+TJfs4StsLPr_Ojsw@mail.gmail.com>

Amazing!  Good stuff!  Thanks everybody!

??, 21 ????. 2015 ?. ? 0:50, Emanuel Borsboom <manny at fpcomplete.com>:

> New version released of Stack, a build tool.
>
> See README
> <https://github.com/commercialhaskell/stack/tree/release#how-to-install>
> for installation and upgrade instructions.
>
> There are now Windows installers available: download them here
> <https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md#windows>.
> In addition, new Fedora 23 packages are available here
> <https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md#fedora>
> .
>
> Note that, starting with v0.1.8.0, releases of Stack will always have an
> even-numbered second-to-last version component. Odd second-to-last version
> components are reserved for unstable builds.
>
> Major changes:
>
>    - GHCJS can now be used with stackage snapshots via the new compiler
>    field.
>    - Docker integration works with non-FP Complete generated images
>    #531 <https://github.com/commercialhaskell/stack/issues/531>
>
> Other enhancements:
>
>    - Added an allow-newer config option
>    #922 <https://github.com/commercialhaskell/stack/issues/922>
>    #770 <https://github.com/commercialhaskell/stack/issues/770>
>    - When a Hackage revision invalidates a build plan in a snapshot,
>    trust the
>    snapshot #770 <https://github.com/commercialhaskell/stack/issues/770>
>    - Added a stack config set resolver RESOLVER command. Part of work on
>    #115 <https://github.com/commercialhaskell/stack/issues/115>
>    - stack setup can now install GHCJS on windows. See
>    #1145 <https://github.com/commercialhaskell/stack/issues/1145> and
>    #749 <https://github.com/commercialhaskell/stack/issues/749>
>    - stack hpc report command added, which generates reports for HPC tix
>    files
>    - stack ghci now accepts all the flags accepted by stack build. See
>    #1186 <https://github.com/commercialhaskell/stack/issues/1186>
>    - stack ghci builds the project before launching GHCi. If the build
>    fails,
>    optimistically launch GHCi anyway. Use stack ghci --no-build option to
>    disable #1065 <https://github.com/commercialhaskell/stack/issues/1065>
>    - stack ghci now detects and warns about various circumstances where
>    it is
>    liable to fail. See
>    #1270 <https://github.com/commercialhaskell/stack/issues/1270>
>    - Added require-docker-version configuration option
>    - Packages will now usually be built along with their tests and
>    benchmarks. See
>    #1166 <https://github.com/commercialhaskell/stack/issues/1166>
>    - Relative local-bin-path paths will be relative to the project?s root
>    directory, not the current working directory.
>    #1340 <https://github.com/commercialhaskell/stack/issues/1340>
>    - stack clean now takes an optional [PACKAGE] argument for use in
>    multi-package projects. See
>    #583 <https://github.com/commercialhaskell/stack/issues/583>
>    - Ignore cabal_macros.h as a dependency
>    #1195 <https://github.com/commercialhaskell/stack/issues/1195>
>    - Pad timestamps and show local time in ?verbose output
>    #1226 <https://github.com/commercialhaskell/stack/issues/1226>
>    - GHCi: Import all modules after loading them
>    #995 <https://github.com/commercialhaskell/stack/issues/995>
>    - Add subcommand aliases: repl for ghci, and runhaskell for runghc
>    #1241 <https://github.com/commercialhaskell/stack/issues/1241>
>    - Add typo recommendations for unknown package identifiers
>    #158 <https://github.com/commercialhaskell/stack/issues/158>
>    - Add stack path --local-hpc-root option
>    - Overhaul dependencies? haddocks copying
>    #1231 <https://github.com/commercialhaskell/stack/issues/1231>
>    - Support for extra-package-dbs in ?stack ghci?
>    #1229 <https://github.com/commercialhaskell/stack/pull/1229>
>    - stack new disallows package names with ?words? consisting solely of
>    numbers
>    #1336 <https://github.com/commercialhaskell/stack/issues/1336>
>    - stack build --fast turns off optimizations
>
> Bug fixes:
>
>    - Fix: Haddocks not copied for dependencies
>    #1105 <https://github.com/commercialhaskell/stack/issues/1105>
>    - Fix: Global options did not work consistently after subcommand
>    #519 <https://github.com/commercialhaskell/stack/issues/519>
>    - Fix: ?stack ghci? doesn?t notice that a module got deleted
>    #1180 <https://github.com/commercialhaskell/stack/issues/1180>
>    - Rebuild when cabal file is changed
>    - Fix: Paths in GHC warnings not canonicalized, nor those for packages
>    in
>    subdirectories or outside the project root
>    #1259 <https://github.com/commercialhaskell/stack/issues/1259>
>    - Fix: unlisted files in tests and benchmarks trigger extraneous
>    second build
>    #838 <https://github.com/commercialhaskell/stack/issues/838>
>
> ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-stack+unsubscribe at googlegroups.com.
> To post to this group, send email to haskell-stack at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/haskell-stack/CACGj5vK3EE00BLDbVnrZQqAa927KLkg4dGeYQJOOhsWMy7b-3g%40mail.gmail.com
> <https://groups.google.com/d/msgid/haskell-stack/CACGj5vK3EE00BLDbVnrZQqAa927KLkg4dGeYQJOOhsWMy7b-3g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/6183a170/attachment.html>

From dave at zednenem.com  Fri Nov 20 20:31:31 2015
From: dave at zednenem.com (David Menendez)
Date: Fri, 20 Nov 2015 15:31:31 -0500
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
References: <564E3EC6.1020801@htwk-leipzig.de>
 <CAJWnFaMzpW2P=edwwHko_UbGDNcgwePE83MoLTQUfvPYtjxC1w@mail.gmail.com>
 <CAPeieQHF1x5cuid3t+V3B2GrqX0RWGT=o2xBEQj-c4UR3g3TzQ@mail.gmail.com>
Message-ID: <CAOv7PyqfomFcRGBTzg0X6Ctpq2WUKac=2nBuxkJyyViE1h-dqw@mail.gmail.com>

On Fri, Nov 20, 2015 at 4:31 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> On 20 November 2015 at 02:30, Manuel G?mez <targen at gmail.com> wrote:
> > I haven?t found a helpful example of an Applicative that is not a Monad
> > that is practical for a lesson.
>
> There's ZipList [0], which depending on the type of audience might be
> doable. There's also Const [1], but that needs a Monoid constraint,
> and since you said you considered ((,) e) as not having an
> Applicative, which it does have with a Monoid constraint, perhaps
> Const isn't suitable to you for that reason. There are more
> interesting examples here [2].
>

An easy way to find applicative functors that are not monads is through
composition. Composing two applicative functors gives a kind of two-stage
computation, where the outer functor can affect the inner one, but can?t
depend on anything in the inner functor.

So, Compose (State s) Maybe a = s -> (Maybe a, s) will use state to create
a partial value, but whether the final value is Nothing cannot affect the
stateful part of the computation. So definitelyFail <*> modifyState will
modify the state, even though an earlier part of the computation failed.

In contrast, MaybeT (State s) a = s -> (Maybe a, s) allows communication
between the stages, so returning Nothing will abort the rest of the
computation. I.e, definitelyFail <*> modifyState will not modify the state.

If that?s too confusing for students, an example like IO (Parser a) may be
better. This cleanly separates the creation of the parser from its
execution, but giving it a monad instance would require giving the IO stage
access to the parser?s input and output.

-- 
Dave Menendez <dave at zednenem.com>
<http://www.eyrie.org/~zednenem/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/16720bf1/attachment.html>

From johnw at newartisans.com  Fri Nov 20 21:13:51 2015
From: johnw at newartisans.com (John Wiegley)
Date: Fri, 20 Nov 2015 13:13:51 -0800
Subject: [Haskell-cafe] [Coq-Club] ANN: linearscan,
	linearscan-hoopl 1.0.0
In-Reply-To: <CANhxKcq6x2z0_E8s-vUTTkgBcScm894YQWaVLga4a4tAGSJWqg@mail.gmail.com>
 (Beta Ziliani's message of "Fri, 20 Nov 2015 17:03:33 -0300")
References: <m2r3jky3a7.fsf@newartisans.com>
 <CANhxKcq6x2z0_E8s-vUTTkgBcScm894YQWaVLga4a4tAGSJWqg@mail.gmail.com>
Message-ID: <m2mvu8s7ao.fsf@newartisans.com>

>>>>> Beta Ziliani <bziliani at famaf.unc.edu.ar> writes:

> I'd be interested to know what was the outcome of the project from the point
> of view of BEA Systems. Is there any report about it?

>From BAE's point of view, we gained some industrial perspective. Separately, I
have prepared an experience report that is currently seeking a venue.

John

From trebla at vex.net  Fri Nov 20 21:41:08 2015
From: trebla at vex.net (Albert Y. C. Lai)
Date: Fri, 20 Nov 2015 16:41:08 -0500
Subject: [Haskell-cafe] AMP - how do you motivate this in teaching?
In-Reply-To: <564E3EC6.1020801@htwk-leipzig.de>
References: <564E3EC6.1020801@htwk-leipzig.de>
Message-ID: <564F9374.6060409@vex.net>

On 2015-11-19 04:27 PM, Johannes Waldmann wrote:
> Now, I don't want to bring on another general discussion of AMP -
> instead I'd like to hear from people who use monads
> in teaching (e.g., to define semantic domains)
> about how they sell "Applicative m =>"  to their students.
> (The intersection of AMPers and teachers is non-empty?)

(I do not teach Haskell. But I teach other things, and I explain Haskell 
things in local Haskell meetups.)

I'm pretty sure we can all agree to start with Functor. This gives us 
fmap so we can apply a 1-ary function to 1 action.

But we are greedy, we also want to apply a 2-ary function to 2 actions. 
Functor alone can't do this. We need at least liftA2. And then we wonder 
about 3-ary, 4-ary...

It turns out that pure and (<*>) cover them all. To apply a 5-ary 
function to 5 actions, we can write the very regular

pure f <*> as <*> bs <*> cs <*> ds <*> es

(Given lambda calculus and Functor, the following suites have equivalent 
ability, so each suite could define Applicative: {pure, liftA2}, {pure, 
liftA2 (,)}, {pure, (<*>)}.)

It also turns out that you can already write sequenceA (you didn't use 
all of Monad to get sequence) and traverse (you didn't use all of Monad 
to get mapM).

So this is how I would motivate Applicative given Functor. I received 
the gift of 1-ary application, but then I get greedy and want n-ary 
application and the silver axe and the golden axe...

The final transition, from Applicative to Monad, is driven by a whole 
new level of greed. I received the gift of n-ary application and a 
silver axe and a golden axe; now I want a smart axe. Here is what I mean:

In the compound action

fs <*> xs

the sub-action fs cannot behave dependently on what "return value" the 
sub-action xs "returns". (Likewise for the other way round.) That data 
dependency is provided by Monad's (>>=) or (=<<). One operand can now 
peak at the "return value" of the other sub-action, and do some 
Turing-smart processing, before it decides what action to take.

This is my version of what other people call successively expanding API.

From jgalt at centromere.net  Fri Nov 20 22:18:53 2015
From: jgalt at centromere.net (John Galt)
Date: Fri, 20 Nov 2015 17:18:53 -0500
Subject: [Haskell-cafe] ANN: cacophony 0.4.0, pipes-cacophony 0.1.2
Message-ID: <20151120171853.477c2a69@centromere.net>

cacophony[1] is a library which implements the Noise[2] protocol.
Noise is a framework for cryptographic protocols based on ECDH key
agreement authored by Trevor Perrin.

pipes-cacophony[3] builds on cacophony to provide pipes that facilitate
key agreement and secure messaging (in conjunction with, for example,
pipes-network).

-- 
John

[1] http://hackage.haskell.org/package/cacophony
[2] https://github.com/trevp/noise/blob/master/noise.md
[3] http://hackage.haskell.org/package/pipes-cacophony

From jykang22 at gmail.com  Sat Nov 21 02:35:54 2015
From: jykang22 at gmail.com (Jeon-Young Kang)
Date: Fri, 20 Nov 2015 21:35:54 -0500
Subject: [Haskell-cafe] RDF with Haskell
Message-ID: <CALWtiK-tfQtdBufz0uuDjzB+rfkBav13LXt1AX7-T5C_K9dGxw@mail.gmail.com>

I am a newbie learning Haskell.

I'd like to import RDF in Haskell as well as to do SPARQL.

I went through RDF4H, Swish, and so on.

But it is still difficult to understand them for me.

Anyone can suggest me to learn that? or recommend any kinds of books or
tutorials?

Sincerely,
Jeon-Young

-- 
Department of Geography
State University of New York at Buffalo

jykang22 at gmail.com

Jeon-Young Kang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151120/ef6634f1/attachment.html>

From olf at aatal-apotheke.de  Sat Nov 21 13:07:07 2015
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 21 Nov 2015 14:07:07 +0100
Subject: [Haskell-cafe] AMP - how do you motivate this in 	teaching?
Message-ID: <DDEB35D2-6D1A-4DB8-A279-6ADD5ABF0E73@aatal-apotheke.de>

Albert's explanation is the best so far, IMHO. 

liftA2 is by far the most useful and reasonable function in Control.Applicative. Realizing that it can be made the definition of Applicative is what made me friends with that typeclass. 

As an algebraicist, to me Control.Monad.join is what distinguishes Monad from Applicative, although Albert's explanation is more accessible new programmers. I tend to explain monads by example of container monads mimicking powerset features, and join has a natural interpretation there. 

-- Olaf

From rick at rickmurphy.org  Sat Nov 21 13:37:11 2015
From: rick at rickmurphy.org (rick)
Date: Sat, 21 Nov 2015 08:37:11 -0500
Subject: [Haskell-cafe] RDF with Haskell
In-Reply-To: <CALWtiK-tfQtdBufz0uuDjzB+rfkBav13LXt1AX7-T5C_K9dGxw@mail.gmail.com>
References: <CALWtiK-tfQtdBufz0uuDjzB+rfkBav13LXt1AX7-T5C_K9dGxw@mail.gmail.com>
Message-ID: <56507387.10209@rickmurphy.org>

Hello Jeon-Young:

You may find some interest in this [1] small project circa 2011.

I also wrote this post [2] on what I learned.

1. https://github.com/rickmurphy/hafr

2.
http://phaneron.rickmurphy.org/2011/12/high-assurance-functional-rdf-in-haskell/

--
Rick

On 11/20/2015 09:35 PM, Jeon-Young Kang wrote:
> I am a newbie learning Haskell.
> 
> I'd like to import RDF in Haskell as well as to do SPARQL.
> 
> I went through RDF4H, Swish, and so on.
> 
> But it is still difficult to understand them for me.
> 
> Anyone can suggest me to learn that? or recommend any kinds of books
> or tutorials?
> 
> Sincerely,
> Jeon-Young
> 
> -- 
> Department of Geography
> State University of New York at Buffalo
> 
> jykang22 at gmail.com <mailto:jykang22 at gmail.com>
>  
> Jeon-Young Kang
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


-- 
Rick

From mihai.maruseac at gmail.com  Sat Nov 21 18:13:36 2015
From: mihai.maruseac at gmail.com (Mihai Maruseac)
Date: Sat, 21 Nov 2015 13:13:36 -0500
Subject: [Haskell-cafe] NNOUNCE: Haskell Communities and Activities Report
 (29th ed., November 2015)
Message-ID: <CAOMsUM+7WcK0s9OXyYM2L76S1eoqUOPqtVW=_1We4fHt+H7D4Q@mail.gmail.com>

On behalf of all the contributors, we are pleased to announce that the

           Haskell Communities and Activities Report
                (29th edition, November 2015)

is now available, in PDF and HTML formats:

  http://haskell.org/communities/11-2015/report.pdf
  http://haskell.org/communities/11-2015/html/report.html

Many thanks go to all the people that contributed to this report,
both directly, by sending in descriptions, and indirectly, by doing
all the interesting things that are reported. We hope you will find
it as interesting a read as we did.

If you have not encountered the Haskell Communities and Activities
Reports before, you may like to know that the first of these reports
was published in November 2001. Their goal is to improve the
communication between the increasingly diverse groups, projects, and
individuals working on, with, or inspired by Haskell. The idea behind
these reports is simple:

  Every six months, a call goes out to all of you enjoying Haskell to
  contribute brief summaries of your own area of work. Many of you
  respond (eagerly, unprompted, and sometimes in time for the actual
  deadline) to the call. The editors collect all the contributions
  into a single report and feed that back to the community.

When we try for the next update, six months from now, you might want
to report on your own work, project, research area or group as well.
So, please put the following into your diaries now:

========================================
                     End of March 2015:
           target deadline for contributions to the
             May 2015 edition of the HCAR Report
========================================

Unfortunately, many Haskellers working on interesting projects are so
busy with their work that they seem to have lost the time to follow
the Haskell related mailing lists and newsgroups, and have trouble even
finding time to report on their work. If you are a member, user or
friend of a project so burdened, please find someone willing to make
time to report and ask them to "register" with the editors for a simple
e-mail reminder in March (you could point us to them as well, and we
can then politely ask if they want to contribute, but it might work
better if you do the initial asking). Of course, they will still have to
find the ten to fifteen minutes to draw up their report, but maybe we
can increase our coverage of all that is going on in the community.

Feel free to circulate this announcement further in order to
reach people who might otherwise not see it. Enjoy!

Mihai Maruseac
<hcar at haskell.org>

-- 
Mihai Maruseac (MM)
"If you can't solve a problem, then there's an easier problem you can
solve: find it." -- George Polya

From jykang22 at gmail.com  Sat Nov 21 19:12:24 2015
From: jykang22 at gmail.com (Jeon-Young Kang)
Date: Sat, 21 Nov 2015 14:12:24 -0500
Subject: [Haskell-cafe] Warning: Tab Character
Message-ID: <CALWtiK-ASPyCnVB+wL_Fubu9YqsGM3YO6cMyippL4M-snHRd_A@mail.gmail.com>

Hello everyone.


I am a newbie of Haskell, using Textmate on mac.


I got the following warning. How can I fix it?


Warning:

    Tab character

Ok, modules loaded: Main.


Sincerely,
Young
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151121/e10e0fdc/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Nov 21 19:30:35 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 21 Nov 2015 19:30:35 +0000
Subject: [Haskell-cafe] Warning: Tab Character
In-Reply-To: <CALWtiK-ASPyCnVB+wL_Fubu9YqsGM3YO6cMyippL4M-snHRd_A@mail.gmail.com>
References: <CALWtiK-ASPyCnVB+wL_Fubu9YqsGM3YO6cMyippL4M-snHRd_A@mail.gmail.com>
Message-ID: <20151121193035.GN17156@weber>

On Sat, Nov 21, 2015 at 02:12:24PM -0500, Jeon-Young Kang wrote:
> I got the following warning. How can I fix it?
> 
> Warning:
> 
>     Tab character

I guess you replace the tab characters that appear in your source files with
spaces.

Tom

From jykang22 at gmail.com  Sat Nov 21 19:59:16 2015
From: jykang22 at gmail.com (Jeon-Young Kang)
Date: Sat, 21 Nov 2015 14:59:16 -0500
Subject: [Haskell-cafe] Warning: Tab Character
In-Reply-To: <20151121193035.GN17156@weber>
References: <CALWtiK-ASPyCnVB+wL_Fubu9YqsGM3YO6cMyippL4M-snHRd_A@mail.gmail.com>
 <20151121193035.GN17156@weber>
Message-ID: <CALWtiK-jtXz3fBiCnWWbzjNyXUmkuLOdGDvQPPd_O72Nyf2ZCQ@mail.gmail.com>

thanks for your suggestion.

On Sat, Nov 21, 2015 at 2:30 PM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Sat, Nov 21, 2015 at 02:12:24PM -0500, Jeon-Young Kang wrote:
> > I got the following warning. How can I fix it?
> >
> > Warning:
> >
> >     Tab character
>
> I guess you replace the tab characters that appear in your source files
> with
> spaces.
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



-- 
Department of Geography
State University of New York at Buffalo

jykang22 at gmail.com

Jeon-Young Kang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151121/9c17e6d9/attachment.html>

From iustin at k1024.org  Sun Nov 22 02:03:33 2015
From: iustin at k1024.org (Iustin Pop)
Date: Sun, 22 Nov 2015 03:03:33 +0100
Subject: [Haskell-cafe] ANN: prefix-units 0.2.0
Message-ID: <20151122020333.GA23397@teal.hq.k1024.org>

Hi all,

New version of my small library prefix-units (for parsing and formatting
things like "10K"). Changes:

* Incompatible API change to cleanup some initial design decisions:
  the two level `FormatOption`/`FormatMode` model is removed, the
  fixed unit of `FormatOption` is moved to a new constructor
  `FormatMode`, and `FormatOption` is removed entirely. This should be
  a simpler API, at the cost of breaking compatibility.
* Fixed issue #3 (No support for negative numbers).
* Worked around issue #1 (Add 'base' unit) by adding a mode that
  disables scaling; it should have the same effect without introducing
  an artificial unit.

Feedback welcome, either via email or at
https://github.com/iustin/prefix-units.

happy hacking,
iustin

From leo at halfaya.org  Sun Nov 22 04:40:05 2015
From: leo at halfaya.org (John Leo)
Date: Sat, 21 Nov 2015 20:40:05 -0800
Subject: [Haskell-cafe] type operators and colon in GHC
Message-ID: <CAHYM_Vk=TipkZ+OnaPccka0OM3yEkYb9Uv-naSEf_VYGR6fVDA@mail.gmail.com>

According to sections 7.4.3 and 7.4.4 of the latest Haskell documentation
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html

you can define (7.4.3) an infix type constructor as long as it begins with
a colon, for example
data a :*: b = Foo a b

and furthermore (7.4.4) you can define an infix operator without having to
use a colon if you enable the TypeOperators extension:
data a * b = Foo a b

However if I try the former without using TypeOperators I get this compiler
error in 7.10.2:
    Illegal declaration of a type or class operator ?:*:?
      Use TypeOperators to declare operators in type and declarations

Using TypeOperators fixes this, but then * without colon also works so I
don't see the point of using colon anymore.

My guess is this was some some kind of historical distinction which is no
longer valid and the documentation needs to be updated.  Is this true, or
am I missing something?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151121/11a7efdd/attachment.html>

From clintonmead at gmail.com  Mon Nov 23 03:15:05 2015
From: clintonmead at gmail.com (Clinton Mead)
Date: Mon, 23 Nov 2015 14:15:05 +1100
Subject: [Haskell-cafe] Running GHC LLVM output through LLVM bitcode linker
	first
Message-ID: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>

Is there a way to run the LLVM code (both generated by Haskell and provided
by the user) though the LLVM bitcode linker to perform intermodule
optimizations (like inlining)

http://llvm.org/docs/CommandGuide/llvm-link.html

Here's some example code:

-- Main.hs --

{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE GHCForeignImportPrim #-}
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE UnliftedFFITypes #-}
{-# LANGUAGE BangPatterns #-}

import GHC.Exts(Word(W#))
import GHC.Prim(Word#)

foreign import ccall llvmid :: Word# -> Word#

main = do
  line1 <- getLine
  let !(W# x1) = read line1
  let !r1 = llvminc x1
  print (W# r1)


-- funcs.ll --

define fastcc i64 @llvminc(i64 inreg %x) {
  %r = add i64 %x, 1
  ret i64 %r
}

When I compile like the following:

ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll

I get an executable that performs correctly, but when I look at the
assembly output in Main.s I get the following:

callq suspendThread
movq %rax, %rbp
movq %rbx, %rdi
callq llvminc
movq %rax, %rbx
movq %rbp, %rdi
callq resumeThread

This leads me to believe that this is being done like a c call through
registers, but not inlined, though I'm not sure about this. I also suspect
sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker
and then sending the resulting one bitcode to the LLVM compiler would
perform these intramodule optimisations.

Is there anyway to get GHC to use the LLVM bitcode linker to link all the
LLVM files (both user provided and resulting from GHC compilation) though
the LLVM bitcode linker first before the system linker?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/f6f1570f/attachment.html>

From jo at durchholz.org  Mon Nov 23 07:53:07 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 23 Nov 2015 08:53:07 +0100
Subject: [Haskell-cafe] Is there an overview of backend technologies for
	Haskell?
Message-ID: <5652C5E3.1060509@durchholz.org>

Hi to all,

I'm wondering how the various backend technologies are regarded.
What trade-offs are involved (e.g. spineless-tagless vs. generating 
machine code, seems to be very, very different), what options there 
might be, what the choice would be if a compiler were to be written from 
scratch, that kind of stuff.
The first two pages of a web search for "Haskell backends" returned only 
references to GHC's LLVM backend. Which was interesting but not an 
overview :-)
URLs welcome.

Regards,
Jo

From roma at ro-che.info  Mon Nov 23 07:58:37 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 23 Nov 2015 09:58:37 +0200
Subject: [Haskell-cafe] Is there an overview of backend technologies for
 Haskell?
In-Reply-To: <5652C5E3.1060509@durchholz.org>
References: <5652C5E3.1060509@durchholz.org>
Message-ID: <5652C72D.5060006@ro-che.info>

One interesting comparison paper is Making a Fast Curry:
Push/Enter vs. Eval/Apply for Higher-order Languages
http://community.haskell.org/~simonmar/papers/eval-apply.pdf

On 11/23/2015 09:53 AM, Joachim Durchholz wrote:
> Hi to all,
> 
> I'm wondering how the various backend technologies are regarded.
> What trade-offs are involved (e.g. spineless-tagless vs. generating
> machine code, seems to be very, very different), what options there
> might be, what the choice would be if a compiler were to be written from
> scratch, that kind of stuff.
> The first two pages of a web search for "Haskell backends" returned only
> references to GHC's LLVM backend. Which was interesting but not an
> overview :-)
> URLs welcome.
> 
> Regards,
> Jo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/b66a47fa/attachment.sig>

From karel.gardas at centrum.cz  Mon Nov 23 08:08:11 2015
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 23 Nov 2015 09:08:11 +0100
Subject: [Haskell-cafe] Is there an overview of backend technologies for
 Haskell?
In-Reply-To: <5652C5E3.1060509@durchholz.org>
References: <5652C5E3.1060509@durchholz.org>
Message-ID: <5652C96B.4@centrum.cz>


Intel Labs Haskell Research Compiler based on GHC may also be 
interesting for your 
http://www.leafpetersen.com/leaf/publications/hs2013/hrc-paper.pdf

Karel

On 11/23/15 08:53 AM, Joachim Durchholz wrote:
> Hi to all,
>
> I'm wondering how the various backend technologies are regarded.
> What trade-offs are involved (e.g. spineless-tagless vs. generating
> machine code, seems to be very, very different), what options there
> might be, what the choice would be if a compiler were to be written from
> scratch, that kind of stuff.
> The first two pages of a web search for "Haskell backends" returned only
> references to GHC's LLVM backend. Which was interesting but not an
> overview :-)
> URLs welcome.
>
> Regards,
> Jo
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


From atze at uu.nl  Mon Nov 23 08:19:53 2015
From: atze at uu.nl (Atze Dijkstra)
Date: Mon, 23 Nov 2015 09:19:53 +0100
Subject: [Haskell-cafe] [NL-FP 2016] 2nd CFP: Dutch Functional Programming
	Day 2016
Message-ID: <0178C1C2-0FEF-4FCE-A414-8F42A2649EED@uu.nl>

[My apologies for multiple received copies of the same message]

2nd Call for Participation:

Dear all,

The next Dutch Functional Programming day (NL-FP 2016) will be held on

 Friday, January 8, 2016

at the Utrecht University, The Netherlands.

You are invited to participate and to give a presentation. At the end of the day we will have a joint dinner.

On the web page http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome <http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome> for the day you?ll find preliminary information which will be further filled in due time. Registration is by letting me know via email (with a subject header that begins with  [NL-FP 2016]) whether you want to (1) participate, (2) join dinner, (3) give a presentation (please include title + abstract), also see the webpage for additional details. If you intend to participate, please let me know as soon as possible because we like to know how many people we can expect.


Hope to meet you all in Utrecht at the next FP Day!

Best regards,



                - Atze -

Atze Dijkstra, Department of Information and Computing Sciences. /|\
Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze <http://www.cs.uu.nl/~atze> . /--|  \
Fax : +31-30-2513971 .... | Email: atze at uu.nl <mailto:atze at uu.nl> ............... /   |___\



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/96cb9573/attachment.html>

From ben at smart-cactus.org  Mon Nov 23 10:07:00 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 Nov 2015 11:07:00 +0100
Subject: [Haskell-cafe] Running GHC LLVM output through LLVM bitcode
	linker first
In-Reply-To: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>
References: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>
Message-ID: <87wpt9uj0b.fsf@smart-cactus.org>

Clinton Mead <clintonmead at gmail.com> writes:

> Is there a way to run the LLVM code (both generated by Haskell and provided
> by the user) though the LLVM bitcode linker to perform intermodule
> optimizations (like inlining)
>
> http://llvm.org/docs/CommandGuide/llvm-link.html
>
> Here's some example code:
>
> -- Main.hs --
>
> {-# LANGUAGE MagicHash #-}
> {-# LANGUAGE UnboxedTuples #-}
> {-# LANGUAGE GHCForeignImportPrim #-}
> {-# LANGUAGE ForeignFunctionInterface #-}
> {-# LANGUAGE UnliftedFFITypes #-}
> {-# LANGUAGE BangPatterns #-}
>
> import GHC.Exts(Word(W#))
> import GHC.Prim(Word#)
>
> foreign import ccall llvmid :: Word# -> Word#
>
Are you sure this code compiled? The above should read `llvminc`.

Moreover, if you really want this call to be efficient you should mark
it as unsafe [1]. This will eliminate the `suspendThread`/`resumeThread`
calls, which add significant cost. After doing this is appears that the
call is only one extra `movq`,

	  movq	7(%rbx), %rdi
	  callq	llvminc

>
> When I compile like the following:
>
> ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll
>
> I get an executable that performs correctly, but when I look at the
> assembly output in Main.s I get the following:
>
> callq suspendThread
> movq %rax, %rbp
> movq %rbx, %rdi
> callq llvminc
> movq %rax, %rbx
> movq %rbp, %rdi
> callq resumeThread
>
> This leads me to believe that this is being done like a c call through
> registers, but not inlined, though I'm not sure about this. I also suspect
> sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker
> and then sending the resulting one bitcode to the LLVM compiler would
> perform these intramodule optimisations.
>
> Is there anyway to get GHC to use the LLVM bitcode linker to link all the
> LLVM files (both user provided and resulting from GHC compilation) though
> the LLVM bitcode linker first before the system linker?

In general I'm not sure that this would be safe. In particular, GHC's
calling convention is much different than that expected by LLVM's
link-time optimizer and while `llvminc` would be safe to inline here (as
it's a ccall), I'm not sure that this is the case in general.

What are you trying to do that requires such optimal code generation? If
you want to put a call like this in an inner loop you'd likely be better
off either writing the entire loop in LLVM or adding a new primop to
GHC.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/c5eb5b94/attachment.sig>

From fis at etc-network.de  Mon Nov 23 11:12:29 2015
From: fis at etc-network.de (Matthias Fischmann)
Date: Mon, 23 Nov 2015 12:12:29 +0100
Subject: [Haskell-cafe] Haskell job in Berlin
Message-ID: <20151123111229.GK5052@lig>


Hei everybody,

We are looking for people to join our Haskell team at liquid democracy e.V. in Berlin.  Details:

| https://liqd.net/job_haskell.html

cheers,
matthias

From oleg at okmij.org  Mon Nov 23 12:33:07 2015
From: oleg at okmij.org (Oleg)
Date: Mon, 23 Nov 2015 21:33:07 +0900
Subject: [Haskell-cafe] Type-level lazy bool operations
Message-ID: <20151123123307.GA2557@Magus.sf-private>


Dmitry Olshansky wrote:
> There are some type-level boolean operation (If, &&, ||, Not) in
> Data.Type.Bool.  Are they lazy enough?
>
> I faced with problem and it seems that the reason is non-lazy "If".
> I.e. both (on-True and on-False) types are trying to be calculated.
> Does it work in this way really? Could it be changed?

Just a remark: if (type-level) computations are pure, then whether
they are done lazily or in any other way should not matter. The
evaluation strategy invariance is the main characteristic, if not the
definition, of purity.

Type-level computations are not pure however: they may have an effect
of divergence, or generating a type-error. Thus we really need a
type-level If, which evaluates only one of the two conditional
branches but never both. It can be easily implemented using the
standard approach of delaying evaluation with a thunk. Please see

        http://okmij.org/ftp/Haskell/TTypeable/TTypeable.hs

and search for ORELSE (near the end of the file). See
        http://okmij.org/ftp/Haskell/typeEQ.html#TTypeable
for background.

From chneukirchen at gmail.com  Mon Nov 23 12:56:58 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Mon, 23 Nov 2015 13:56:58 +0100
Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-11-25 @ 19:30
Message-ID: <87wpt8g9gl.fsf@gmail.com>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Wednesday, November 25 at Cafe Puck at 19h30. For details see here:

http://chneukirchen.github.io/haskell-munich.de/dates.html

If you plan to join, please add yourself to this dudle so we can
reserve enough seats!  It is OK to add yourself to the dudle
anonymously or pseudonymously.

https://dudle.inf.tu-dresden.de/haskell-munich-nov-2015/

Everybody is welcome!

cu,
-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

From heraldhoi at gmail.com  Mon Nov 23 15:17:22 2015
From: heraldhoi at gmail.com (Geraldus)
Date: Mon, 23 Nov 2015 15:17:22 +0000
Subject: [Haskell-cafe] darcs 2.10.2 release
In-Reply-To: <CADw8UJq92Tg4vgn8CcajvVqOu2UBnkkh20TVi0jKJri__73Zpw@mail.gmail.com>
References: <CADw8UJprRJBe6h+RG2yLMyOpA_FHU8wFWoQYFZegSq6CJWL=uQ@mail.gmail.com>
 <op.x7ug7ztxpz0j5l@alquantor>
 <CADw8UJq92Tg4vgn8CcajvVqOu2UBnkkh20TVi0jKJri__73Zpw@mail.gmail.com>
Message-ID: <CAB2YT55MPx=+BboE5z=4vSawj3cvek-=XW8mzZV+RfJj4TgqqA@mail.gmail.com>

I was not able to build darcs with stack because it failed to find a proper
build plan.

??, 10 ????. 2015 ?. ? 3:41, Guillaume Hoffmann <guillaumh at gmail.com>:

> Thanks Henk-Jan!
>
> My setup is very linux-and-cabal centric so help like this is very
> welcome. I also had feedback about how to provide build instructions
> with stack.
>
> Guillaume
>
> 2015-11-09 14:51 GMT-03:00 Henk-Jan van Tuyl <hjgtuyl at chello.nl>:
> > On Mon, 09 Nov 2015 15:17:44 +0100, Guillaume Hoffmann <
> guillaumh at gmail.com>
> > wrote:
> >
> >> The darcs team is pleased to announce the release of darcs 2.10.2 !
> >>
> >> # Downloading #
> >>
> >> The easiest way to install darcs 2.10.2 from source is by first
> >> installing the Haskell Platform (http://www.haskell.org/platform). If
> >> you have installed the Haskell Platform or cabal-install, you can
> >> install this release by doing:
> >>
> >> $ cabal update
> >> $ cabal install darcs-2.10.2
> >
> >
> > Windows users must use
> >   cabal install darcs-2.10.2 -f-curl
> >
> > Regards,
> > Henk-Jan van Tuyl
> >
> >
> > --
> > Folding at home
> > What if you could share your unused computer power to help find a cure?
> In
> > just 5 minutes you can join the world's biggest networked computer and
> get
> > us closer sooner. Watch the video.
> > http://folding.stanford.edu/
> >
> >
> > http://Van.Tuyl.eu/
> > http://members.chello.nl/hjgtuyl/tourdemonad.html
> > Haskell programming
> > --
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/726a9916/attachment.html>

From awick at galois.com  Mon Nov 23 20:03:26 2015
From: awick at galois.com (Adam Wick)
Date: Mon, 23 Nov 2015 20:03:26 +0000
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
In-Reply-To: <CAM_nd56Sz5LB4puXZVjJYTWMfSDZ4Y8oem503eJ=M4dq96L_+g@mail.gmail.com>
References: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
 <CAM_nd56Sz5LB4puXZVjJYTWMfSDZ4Y8oem503eJ=M4dq96L_+g@mail.gmail.com>
Message-ID: <CAN3T=gV2w6QZ_G1U-6+2Y+KbeBaiR-9Ta24b25VVKOC8z-Rnrg@mail.gmail.com>

The path I've been using is basically using the tor spec and implement it.
I'll also say that, for C, Tor is pretty clear, so the source can be used
to clarify the docs.

Other things that might be useful for warm-up purposes:

(1) Right now the test executable is pretty just a hard-coded 'wget' that
runs through Tor. If we could expand it to be an analogue of the
traditional Tor binary, that'd be cool. It'd mean figuring out how to pull
in the existing options via command line arguments and/or config files, and
then extending haskell-tor to allow some of the same flags normal-tor has.

(2) Running hpc over the source code while running the test suite, and then
finding tests to run on the uncovered bits would be great. Theoretically
the library is well set up for building up fake, internal test networks and
then running higher-level tests, too. This needs to be done.

(3) There's some stuff in the Tor spec about reporting bandwidth usage when
publishing node descriptions. I think you could just add a wrapper around
the network stack argument and come up with something pretty clean,
awesome, and simple, but again ... needs to be thought out and done.

(4) Flow control! I put a little bit of flow control stuff in, but I
suspect it might be wrong. But at least you'd have some existing stuff to
start from.

Those seem like the easiest four to jump on, if you don't want to start
adding core features as your first step. :) And certainly the first two are
going to be priorities for me, as soon as I fix a couple early issues
people have submitted and get a chance to put more time into it.


- Adam

On Thu, Nov 19, 2015 at 10:58 AM Curtis Gagliardi <
gagliardi.curtis at gmail.com> wrote:

> Very excited about this.  I want to contribute but am new to tor
> (internals at least, been runing a relay for a long time).   Do any of
> those strike you as lower hanging fruit than the others that might be a
> good place to start?  Do you have any recommended resources or is the path
> pretty much read the tor spec and implement it?
>
> On Wed, Nov 18, 2015 at 5:22 PM, Adam Wick <awick at galois.com> wrote:
>
>> Howdy -
>>
>> Galois is pleased to announce an initial release of haskell-tor.
>> Haskell-tor is intended to be a full-featured, drop-in implementation of
>> the Tor onion routing protocol. This release provides full support for
>> resolving names and building connections via anonymized channels, as well
>> as (less tested) support for running relay and exit nodes.
>>
>> There are still many tasks left to do, however, if you're interested in
>> learning about and working on a Tor implementation, including support for
>> hidden services, proper flow control, directory support, etc. So if you're
>> interested, jump in! We welcome your patches.
>>
>> You can find haskell-tor on:
>>
>> GitHub: https://github.com/GaloisInc/haskell-tor
>> Hackage: https://hackage.haskell.org/package/haskell-tor
>>
>> Haskell-tor is HaLVM-ready.
>>
>>
>> - Adam
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/35adedb0/attachment.html>

From iavor.diatchki at gmail.com  Mon Nov 23 23:10:33 2015
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 23 Nov 2015 15:10:33 -0800
Subject: [Haskell-cafe] Type-level lazy bool operations
In-Reply-To: <20151123123307.GA2557@Magus.sf-private>
References: <20151123123307.GA2557@Magus.sf-private>
Message-ID: <CAGK9nurKtmJ8QoVAgOdsH5USg1ccp9vsLqES5H3BUdh32SkQ2Q@mail.gmail.com>

Hello,

Isn't the issue a bit more complex?  The way I see it, the difference
between the type level and the value level is that at the type level we
want to do reasoning rather than just evaluation.  Reasoning may require
evaluating parts of a type that would not be evaluated if we were to do
just ordinary "forward" evaluation.  Consider, for example, the constraint:

(IfThenElse a Int b ~ Char)

It make perfect sense to simplify this to (a ~ False, b ~ Char), however to
do so we need to evaluate the `then` part so that we can see that it leads
to a contradiction.

-Iavor




On Mon, Nov 23, 2015 at 4:33 AM, Oleg <oleg at okmij.org> wrote:

>
> Dmitry Olshansky wrote:
> > There are some type-level boolean operation (If, &&, ||, Not) in
> > Data.Type.Bool.  Are they lazy enough?
> >
> > I faced with problem and it seems that the reason is non-lazy "If".
> > I.e. both (on-True and on-False) types are trying to be calculated.
> > Does it work in this way really? Could it be changed?
>
> Just a remark: if (type-level) computations are pure, then whether
> they are done lazily or in any other way should not matter. The
> evaluation strategy invariance is the main characteristic, if not the
> definition, of purity.
>
> Type-level computations are not pure however: they may have an effect
> of divergence, or generating a type-error. Thus we really need a
> type-level If, which evaluates only one of the two conditional
> branches but never both. It can be easily implemented using the
> standard approach of delaying evaluation with a thunk. Please see
>
>         http://okmij.org/ftp/Haskell/TTypeable/TTypeable.hs
>
> and search for ORELSE (near the end of the file). See
>         http://okmij.org/ftp/Haskell/typeEQ.html#TTypeable
> for background.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151123/633862ed/attachment.html>

From simons at cryp.to  Tue Nov 24 09:01:07 2015
From: simons at cryp.to (Peter Simons)
Date: Tue, 24 Nov 2015 10:01:07 +0100
Subject: [Haskell-cafe] ANN: haskell-tor 0.1
References: <CAN3T=gVdHKB81tjsVZtkN7MhDqy6Yn16xVF8JwAK-T9E--CSCw@mail.gmail.com>
Message-ID: <871tbfg4a4.fsf@write-only.here.com>

Hi Adam,

 > GitHub: https://github.com/GaloisInc/haskell-tor
 > Hackage: https://hackage.haskell.org/package/haskell-tor

do you respond to issues posted on Github?

As far as I can tell, haskell-tor does not compile, because the release
tarball is missing the module Tor.Flags. This seems easy enough to fix,
but I didn't get any response to my report at:

  https://github.com/GaloisInc/haskell-tor/issues/4

Best regards,
Peter


From arnaudpourseb at gmail.com  Tue Nov 24 17:51:43 2015
From: arnaudpourseb at gmail.com (Sebastian)
Date: Tue, 24 Nov 2015 12:51:43 -0500
Subject: [Haskell-cafe] [ANN] Linode package
Message-ID: <CAD27H6+Z7+MRF6rrFQ=VnJa6huOpceU_dM+foLycKoDzPoTXxg@mail.gmail.com>

Hello everybody,

I'm happy to announce the initial release of the Linode package. It
contains bindings to the Linode API and a few user friendly routines to
setup and destroy VPS instances.

The next major release will cover private IPs and load balancing.

Hackage: http://hackage.haskell.org/package/linode
Github: https://github.com/Helkafen/haskell-linode

A working example is provided in the docs. It creates one linode instance
and performs a dummy install:
https://hackage.haskell.org/package/linode-0.1.0.4/docs/Network-Linode.html

Use cases include:
- Running some daily batch, with one or several instances
- Dynamically adding some resources to a long running process
- Anything you would normally do with a VPS

Ideas, contributions and feedback are welcome!

--
Sebastian de Bellefon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151124/5b341c35/attachment.html>

From jykang22 at gmail.com  Tue Nov 24 18:20:03 2015
From: jykang22 at gmail.com (Jeon-Young Kang)
Date: Tue, 24 Nov 2015 13:20:03 -0500
Subject: [Haskell-cafe] Comparison between fields of each record
Message-ID: <CALWtiK_Gtsw2j9_EtcvGAHssinpf5rhm=YYr0T2_QJzJ0gzWnQ@mail.gmail.com>

Dear All.

I'd like to compare fields of each record.

here is my record.

data Person = Person {name:: String, age:: Int } deriving(Show)
data Relations = Friend | Older | Younger

class Comparison a where
    compare:: a -> a -> Relations

instance Comparison Person where
    compare Person a b Person a b
         | b1 == b2 = Friend
         | b1 > b2 = Older
         | b1 < b2 = Younger

How can I fit it?

Sincerely,


Jeon-Young Kang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151124/cd23cd3c/attachment.html>

From fa-ml at ariis.it  Tue Nov 24 19:01:08 2015
From: fa-ml at ariis.it (Francesco Ariis)
Date: Tue, 24 Nov 2015 20:01:08 +0100
Subject: [Haskell-cafe] Comparison between fields of each record
In-Reply-To: <CALWtiK_Gtsw2j9_EtcvGAHssinpf5rhm=YYr0T2_QJzJ0gzWnQ@mail.gmail.com>
References: <CALWtiK_Gtsw2j9_EtcvGAHssinpf5rhm=YYr0T2_QJzJ0gzWnQ@mail.gmail.com>
Message-ID: <20151124190108.GA4519@casa.casa>

On Tue, Nov 24, 2015 at 01:20:03PM -0500, Jeon-Young Kang wrote:
> Dear All.
> 
> I'd like to compare fields of each record.
> 
> here is my record.
> 
> data Person = Person {name:: String, age:: Int } deriving(Show)
> data Relations = Friend | Older | Younger
> 
> class Comparison a where
>     compare:: a -> a -> Relations
> 
> instance Comparison Person where
>     compare Person a b Person a b
>          | b1 == b2 = Friend
>          | b1 > b2 = Older
>          | b1 < b2 = Younger
> 
> How can I fit it?
> 
> Sincerely,
> 
> 
> Jeon-Young Kang

Hello Jeon-Young, I attach a version that compiles. Keep in mind that

    compare (Person x y) (Person q w) -- this is legal

    compare Person x y Person q w -- "space" takes precedence over everything,
                                  -- so this function has 6 arguments
                                  -- instead of the expected 2!


?> Main.compare (Person "cdsac" 1) (Person "cdscasd" 20)
Younger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.hs
Type: text/x-haskell
Size: 343 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151124/05b234a7/attachment.hs>

From jykang22 at gmail.com  Tue Nov 24 19:14:01 2015
From: jykang22 at gmail.com (Jeon-Young Kang)
Date: Tue, 24 Nov 2015 14:14:01 -0500
Subject: [Haskell-cafe] Comparison between fields of each record
In-Reply-To: <20151124190108.GA4519@casa.casa>
References: <CALWtiK_Gtsw2j9_EtcvGAHssinpf5rhm=YYr0T2_QJzJ0gzWnQ@mail.gmail.com>
 <20151124190108.GA4519@casa.casa>
Message-ID: <CALWtiK-Z3hwn=abCEUc7yZ+RN5JLxcfxZNwHrDFMQM366m5fnw@mail.gmail.com>

Thank you so much :)

On Tue, Nov 24, 2015 at 2:01 PM, Francesco Ariis <fa-ml at ariis.it> wrote:

> On Tue, Nov 24, 2015 at 01:20:03PM -0500, Jeon-Young Kang wrote:
> > Dear All.
> >
> > I'd like to compare fields of each record.
> >
> > here is my record.
> >
> > data Person = Person {name:: String, age:: Int } deriving(Show)
> > data Relations = Friend | Older | Younger
> >
> > class Comparison a where
> >     compare:: a -> a -> Relations
> >
> > instance Comparison Person where
> >     compare Person a b Person a b
> >          | b1 == b2 = Friend
> >          | b1 > b2 = Older
> >          | b1 < b2 = Younger
> >
> > How can I fit it?
> >
> > Sincerely,
> >
> >
> > Jeon-Young Kang
>
> Hello Jeon-Young, I attach a version that compiles. Keep in mind that
>
>     compare (Person x y) (Person q w) -- this is legal
>
>     compare Person x y Person q w -- "space" takes precedence over
> everything,
>                                   -- so this function has 6 arguments
>                                   -- instead of the expected 2!
>
>
> ?> Main.compare (Person "cdsac" 1) (Person "cdscasd" 20)
> Younger
>



-- 
Department of Geography
State University of New York at Buffalo

jykang22 at gmail.com

Jeon-Young Kang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151124/014f44cc/attachment.html>

From capn.freako at gmail.com  Wed Nov 25 14:12:57 2015
From: capn.freako at gmail.com (David Banas)
Date: Wed, 25 Nov 2015 06:12:57 -0800
Subject: [Haskell-cafe] Run time module definition file location information?
Message-ID: <B644BDB9-B0B6-476F-93E6-F81EA5DEF993@gmail.com>

Hi all,

How can I get a running Haskell program to tell me where it?s looking, in order to satisfy ?import ?? statements?

Thanks,
-db


From kane at kane.cx  Wed Nov 25 15:42:53 2015
From: kane at kane.cx (David Kraeutmann)
Date: Wed, 25 Nov 2015 16:42:53 +0100
Subject: [Haskell-cafe] Run time module definition file location
	information?
In-Reply-To: <B644BDB9-B0B6-476F-93E6-F81EA5DEF993@gmail.com>
References: <B644BDB9-B0B6-476F-93E6-F81EA5DEF993@gmail.com>
Message-ID: <CAJ8B99yKursaSECrHceE-p0eEE1Z_O2MA9S_EwXSXn8u3HceYw@mail.gmail.com>

Imports are resolved at compile time and linked statically into the
executable unless you tell GHC to use dynamic linking. In that case, `ldd`
will tell you the files it's linked against. In any case, that information
is unavailable at runtime.

Note that generally static linking is preferred over dynamic linking.
On Nov 25, 2015 3:12 PM, "David Banas" <capn.freako at gmail.com> wrote:

> Hi all,
>
> How can I get a running Haskell program to tell me where it?s looking, in
> order to satisfy ?import ?? statements?
>
> Thanks,
> -db
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151125/d1edce9f/attachment.html>

From silvio.frischi at gmail.com  Wed Nov 25 15:51:35 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Wed, 25 Nov 2015 16:51:35 +0100
Subject: [Haskell-cafe] Run time module definition file location
 information?
In-Reply-To: <B644BDB9-B0B6-476F-93E6-F81EA5DEF993@gmail.com>
References: <B644BDB9-B0B6-476F-93E6-F81EA5DEF993@gmail.com>
Message-ID: <5655D907.5030409@gmail.com>

> How can I get a running Haskell program to tell me where it?s looking, in order to satisfy ?import ?? statements?

Short answer: You can't.

Long answer:
Everything is imported at compile time. GHC for instance usually links
all imports statically. I.e. no files will be opened for the import
statements. The only dynamically linked libraries are libc, posix, ...


Maybe if you clarify what you want to do, I can be more helpful.

Cheers

Silvio

From simon at joyful.com  Wed Nov 25 17:44:59 2015
From: simon at joyful.com (Simon Michael)
Date: Wed, 25 Nov 2015 09:44:59 -0800
Subject: [Haskell-cafe] [ANN] Linode package
In-Reply-To: <CAD27H6+Z7+MRF6rrFQ=VnJa6huOpceU_dM+foLycKoDzPoTXxg@mail.gmail.com>
References: <CAD27H6+Z7+MRF6rrFQ=VnJa6huOpceU_dM+foLycKoDzPoTXxg@mail.gmail.com>
Message-ID: <n34s2r$722$1@ger.gmane.org>

Nice! thank you.


From silvio.frischi at gmail.com  Wed Nov 25 19:00:32 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Wed, 25 Nov 2015 20:00:32 +0100
Subject: [Haskell-cafe] Info about List with terminal element
Message-ID: <56560550.1030905@gmail.com>

Hello,

I'm interested in learning more about a list-like structure with a
terminal element. I.e.

data List t e = Cons e (List t e) | Null t

or maybe

data List t e = Cons e (List t e) | Null | Terminal t


An practical application could be lazy reading from a file
readFile :: String -> List Error String

Obviously there is a Functor instance. There is even a Monad instance.
However, it is not defined as obviously because it's not clear what the
terminal element should be. There is a straight forward fold like structure.

My questions are.

Are there more interesting generalizations of List?
What rules do they follow?
How should the Monad work? Why?

I know this is related to the whole Iteratee discussion (I'm not
completely familiar with it).

Cheers

Silvio

From silvio.frischi at gmail.com  Wed Nov 25 19:04:30 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Wed, 25 Nov 2015 20:04:30 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56560550.1030905@gmail.com>
References: <56560550.1030905@gmail.com>
Message-ID: <5656063E.5090108@gmail.com>

> readFile :: String -> List Error String

should have been

readFile :: String -> IO (List Error String)

From kane at kane.cx  Wed Nov 25 19:38:11 2015
From: kane at kane.cx (David Kraeutmann)
Date: Wed, 25 Nov 2015 20:38:11 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <5656063E.5090108@gmail.com>
References: <56560550.1030905@gmail.com> <5656063E.5090108@gmail.com>
Message-ID: <56560E23.5010801@kane.cx>

I'm not quite sure I understand the purpose of this structure. As far as I can tell, it's isomorphic to list (even under laziness) with some minor differences in performance characteristics (determining whether a cons cell is terminal requires evaluating the subsequent list to WHNF, whereas in your structure it follows from the constructor. But I think that's just a minor performance detail).

On 11/25/2015 8:04 PM, Silvio Frischknecht wrote:
> > readFile :: String -> List Error String
>
> should have been
>
> readFile :: String -> IO (List Error String)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4291 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151125/82990adf/attachment.bin>

From silvio.frischi at gmail.com  Wed Nov 25 20:47:15 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Wed, 25 Nov 2015 21:47:15 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56560E23.5010801@kane.cx>
References: <56560550.1030905@gmail.com> <5656063E.5090108@gmail.com>
 <56560E23.5010801@kane.cx>
Message-ID: <56561E53.9090002@gmail.com>



On 25.11.2015 20:38, David Kraeutmann wrote:
> I'm not quite sure I understand the purpose of this structure. As far
> as I can tell, it's isomorphic to list (even under laziness) with
> some minor differences in performance characteristics (determining
> whether a cons cell is terminal requires evaluating the subsequent
> list to WHNF, whereas in your structure it follows from the
> constructor. But I think that's just a minor performance detail).

I think you misunderstand the structure. It is just a list that has an
element of a type t at the end. It might not terminate.

data List t e = Cons e (List t e) | Null | Terminal t
data List t e = Cons e (List t e) | Null t

are somewhat similar to

([e],Maybe t)
([e],t)

respectively.

but it is guaranteed that all cons of [e] are evaluated before t can be
touched.

Silvio

From kane at kane.cx  Wed Nov 25 21:16:19 2015
From: kane at kane.cx (David Kraeutmann)
Date: Wed, 25 Nov 2015 22:16:19 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56561E53.9090002@gmail.com>
References: <56560550.1030905@gmail.com> <5656063E.5090108@gmail.com>
 <56560E23.5010801@kane.cx> <56561E53.9090002@gmail.com>
Message-ID: <CAJ8B99yovd3F+JXoqfaqVmRfj9KOWA6qNewkmejzCXhZNqaRKA@mail.gmail.com>

Oh, sorry. Yes, I missed the t. Thanks for clearing it up.

On Wed, Nov 25, 2015 at 9:47 PM, Silvio Frischknecht
<silvio.frischi at gmail.com> wrote:
>
>
> On 25.11.2015 20:38, David Kraeutmann wrote:
>> I'm not quite sure I understand the purpose of this structure. As far
>> as I can tell, it's isomorphic to list (even under laziness) with
>> some minor differences in performance characteristics (determining
>> whether a cons cell is terminal requires evaluating the subsequent
>> list to WHNF, whereas in your structure it follows from the
>> constructor. But I think that's just a minor performance detail).
>
> I think you misunderstand the structure. It is just a list that has an
> element of a type t at the end. It might not terminate.
>
> data List t e = Cons e (List t e) | Null | Terminal t
> data List t e = Cons e (List t e) | Null t
>
> are somewhat similar to
>
> ([e],Maybe t)
> ([e],t)
>
> respectively.
>
> but it is guaranteed that all cons of [e] are evaluated before t can be
> touched.
>
> Silvio
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Nov 25 21:23:29 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 25 Nov 2015 21:23:29 +0000
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56560550.1030905@gmail.com>
References: <56560550.1030905@gmail.com>
Message-ID: <20151125212329.GE27237@weber>

On Wed, Nov 25, 2015 at 08:00:32PM +0100, Silvio Frischknecht wrote:
> I'm interested in learning more about a list-like structure with a
> terminal element. I.e.
> 
> data List t e = Cons e (List t e) | Null t

I think this is isomorphic to

    Producer e Identity r

    https://hackage.haskell.org/package/pipes-4.1.7/docs/Pipes.html#g:2

Tom

From ok at cs.otago.ac.nz  Thu Nov 26 05:19:58 2015
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Thu, 26 Nov 2015 18:19:58 +1300
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56560550.1030905@gmail.com>
References: <56560550.1030905@gmail.com>
Message-ID: <175BC3AE-7E74-4BBE-A71F-76AF2FE5A6C3@cs.otago.ac.nz>


On 26/11/2015, at 8:00 am, Silvio Frischknecht <silvio.frischi at gmail.com> wrote:
> I'm interested in learning more about a list-like structure with a
> terminal element. I.e.
> 
> data List t e = Cons e (List t e) | Null t
> 
> or maybe
> 
> data List t e = Cons e (List t e) | Null | Terminal t

> Are there more interesting generalizations of List?

There are unrolled lists.
http://www.cs.otago.ac.nz/staffpriv/ok/Ursl.hs
is "Unrolled Strict Lists", something I wrote many years
ago when learning Haskell.

There's a data structure that makes reverse and append
unit time.

Okasaki's "Functional Data Structures" book has some
interesting variations.

        "An Applicative Random-Access Stack"
        Eugene W. Myers
        TR 83-9, Dept of CS, University of Arizona.

gives a data structure with O(1) empty, push, pop, top,
and length, and O(lg(length)) indexing.



From gershomb at gmail.com  Thu Nov 26 05:47:08 2015
From: gershomb at gmail.com (Gershom B)
Date: Thu, 26 Nov 2015 00:47:08 -0500
Subject: [Haskell-cafe] regex-posix broken on 64 bit windows.
Message-ID: <etPan.56569d19.3293334d.10a@mbp.local>

Here?s a ticket reporting the issue:

https://github.com/haskell/haskell-platform/issues/144

The ticket is on the platform site, but it doesn?t really belong there. On the other hand, there?s no tracker for regex-posix anywhere else.

This problem has probably existed for a _long_ time, and I guess has to do with 64-bit incompatibilities in the cbits shipped with the package.

I?ve cc?d Chris?Kuklewicz as he is author and maintainer. But I know that he has taken a step back from these packages some time ago.

Generally, I would be happy to consider them stable-ish and let the community just migrate away from them or not as open source typically evolves. But regex-posix is pretty widely used still and is in the platform, so I think it is unfortunate that it is broken in this way.

It would be great if some interested volunteer were to step up and fix this issue and maybe even offer to take over maintainership (to which I?m sure Chris would have no objection?).

(Relatedly, it would be good to have a future discussion on which regex library, if any, is suitable for inclusion in the platform. At this point my inclination would be regex-tdfa-text, although my sense is nearly all the libs are relatively unmaintained at this point?)

?Gershom

From oleg at okmij.org  Thu Nov 26 09:18:40 2015
From: oleg at okmij.org (Oleg)
Date: Thu, 26 Nov 2015 18:18:40 +0900
Subject: [Haskell-cafe] Type-level lazy bool operations
In-Reply-To: <CAGK9nurKtmJ8QoVAgOdsH5USg1ccp9vsLqES5H3BUdh32SkQ2Q@mail.gmail.com>
Message-ID: <20151126091840.GA1722@Magus.rd.isc.tohoku.ac.jp>


> Isn't the issue a bit more complex?  The way I see it, the difference
> between the type level and the value level is that at the type level we
> want to do reasoning rather than just evaluation.

That is an excellent point! I wish the design of Haskell type-level
features has kept that in mind. For example, given the closed type
families

        type family F1 a where
           F1 Int = True
           F1 a   = False


        type family F2 a where
           F2 Int = Char
           F2 a   = Bool

wouldn't it be nice if (F1 a ~ True) were to simplify to (a ~ Int)?
Then the following term t1 would not have been ambiguous

        data Proxy (a::Bool) = Proxy

        foo :: Proxy (F1 a) -> a -> String
        foo = undefined

        t1 = foo (Proxy :: Proxy True) 1


And wouldn't it be nice if
(F1 a ~ False, F2 a ~ b) were to simplify to (b ~ Bool)?

Alas, such considerations were explicitly out of scope when type
families, open or closed, were designed. We wouldn't have had to wait
so long for injective type families; with the proper design, the need
for such feature would've been obvious from the beginning.


From plredmond at gmail.com  Thu Nov 26 09:10:31 2015
From: plredmond at gmail.com (Patrick Redmond)
Date: Thu, 26 Nov 2015 01:10:31 -0800
Subject: [Haskell-cafe] make a server & connect to it - strange behavior
Message-ID: <CAHUea4F64yuNzNqwBGD_EnPf12yf2FMMxLoYKqf2AmqHP_ON6Q@mail.gmail.com>

Hi Haskell Cafe,

When I start a web server (http-server:Network.HTTP.Server.serverWith) on a
separate thread (async:Control.Concurrent.Async.withAsync) and then try to
retrieve a response from the server (HTTP:Network.Browser.*) on a threaded
runtime, I see either

   - connection refusals or
   - deadlock.

Before I sink time into reading the source of the packages in question,
does anybody see what's wrong with the code below?

Increasing the timeout to wait for the server to initialize doesn't solve
the problem. Using a bound thread doesn't solve the problem. I'm compiling
with options "-threaded -rtsopts -with-rtsopts=-N".

Thank you for taking a look.
--Patrick

This test project is on github.
<https://github.com/plredmond/http-server-test-hs/blob/master/src/Lib.hs>

module Lib
    ( someFunc
    ) where

import Control.Monad.IO.Class (liftIO)
import qualified Control.Concurrent as Concurrent
import qualified Control.Concurrent.Async as Async
import qualified Control.Exception as Exception
import qualified Data.Maybe as Maybe
import qualified Network.Browser as Browser
import qualified Network.HTTP as HTTP
import qualified Network.HTTP.Server as Server
import qualified Network.HTTP.Server.Logger as ServerL
import qualified Network.HTTP.Server.Response as ServerR
import qualified Network.URI as URI

someFunc :: IO (Either Exception.SomeException (URI.URI, HTTP.Response
String))
someFunc = do
    Async.withAsync (Server.serverWith config handler) $ \_ -> do
        Concurrent.threadDelay . round $ 2e6
        Exception.try . Browser.browse . Browser.request .
Browser.defaultGETRequest $ uri
    where
        uri = Maybe.fromJust . URI.parseURI $ "http://localhost:8080/"
        config = Server.Config ServerL.stdLogger "localhost" 8080
        handler _ url req = return (ServerR.respond ServerR.OK ::
Server.Response String)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151126/c0550308/attachment.html>

From dct25-561bs at mythic-beasts.com  Thu Nov 26 14:48:55 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Thu, 26 Nov 2015 14:48:55 +0000
Subject: [Haskell-cafe] Could not deduce Monad m => MonadReader r (ReaderT r
	m) ??
Message-ID: <CAErCyQ8ps0SV5A8N6iH0CXY9K=L5Os8f4GSC7+J_1vK7fO+waw@mail.gmail.com>

Porting some code from GHC 7.8.4 to GHC 7.10.2 and have encountered this
rather odd failure:

    Could not deduce (MonadReader
                        (PqColumn m -> m B.ByteString)
                        (ReaderT (PqColumn m -> m B.ByteString) m))
      arising from a use of ?ask?
    from the context (Monad m)
      bound by the type signature for
                 readFieldByteString :: Monad m =>
                                        PqColumn m -> RowReader m
B.ByteString
      at src/EventStore/LibPq.hs:164:24-72
    In a stmt of a 'do' block: readField <- ask
    In the expression:
      do { readField <- ask;
           lift $ readField col }
    In an equation for ?readFieldByteString?:
        readFieldByteString col
          = do { readField <- ask;
                 lift $ readField col }

I wondered if it was because the environment type (PqColumn m -> m
B.ByteString) itself was an instance of MonadReader and the typechecker was
getting confused, so I put the environment in a newtype and it was indeed
happy.

Unfortunately I can't share enough of this code to get the problematic
fragment to compile, and my initial attempts at a small reproduction have
been unsuccessful. It's something like the following, but this compiles
just fine.

    class MyClass m where
      type MyType m
      defaultValue :: m (MyType m)

    l :: Monad m => MyType m -> ReaderT (MyType m -> m Int) m Int
    l n = do
      f <- ask
      lift $ f n

Before I put more effort into reproducing this, does anyone recognise this
failure or know what might be going on here?

Cheers,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151126/782b470b/attachment.html>

From silvio.frischi at gmail.com  Thu Nov 26 15:47:51 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Thu, 26 Nov 2015 16:47:51 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <20151125212329.GE27237@weber>
References: <56560550.1030905@gmail.com> <20151125212329.GE27237@weber>
Message-ID: <565729A7.1050707@gmail.com>



>> data List t e = Cons e (List t e) | Null t
> 
> I think this is isomorphic to
> 
>     Producer e Identity r

Interesting. It does appear to be very similar.

Except that the Monad/Functor variable is 'r' not 'e'

Silvio

From diaz.carrete at gmail.com  Thu Nov 26 20:35:54 2015
From: diaz.carrete at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz?=)
Date: Thu, 26 Nov 2015 12:35:54 -0800 (PST)
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <56560550.1030905@gmail.com>
References: <56560550.1030905@gmail.com>
Message-ID: <26e12188-37a3-4428-8a6b-23c77994de2a@googlegroups.com>

The type

Cofree (Either t) e


is isomorphic to a non-empty version of 

List t e 


On Wednesday, November 25, 2015 at 8:00:40 PM UTC+1, Silvio Frischknecht 
wrote:
>
> Hello, 
>
> I'm interested in learning more about a list-like structure with a 
> terminal element. I.e. 
>
> data List t e = Cons e (List t e) | Null t 
>
> or maybe 
>
> data List t e = Cons e (List t e) | Null | Terminal t 
>
>
> An practical application could be lazy reading from a file 
> readFile :: String -> List Error String 
>
> Obviously there is a Functor instance. There is even a Monad instance. 
> However, it is not defined as obviously because it's not clear what the 
> terminal element should be. There is a straight forward fold like 
> structure. 
>
> My questions are. 
>
> Are there more interesting generalizations of List? 
> What rules do they follow? 
> How should the Monad work? Why? 
>
> I know this is related to the whole Iteratee discussion (I'm not 
> completely familiar with it). 
>
> Cheers 
>
> Silvio 
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151126/98a1cda5/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Nov 26 21:27:30 2015
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 26 Nov 2015 21:27:30 +0000
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <565729A7.1050707@gmail.com>
References: <56560550.1030905@gmail.com> <20151125212329.GE27237@weber>
 <565729A7.1050707@gmail.com>
Message-ID: <20151126212730.GO27237@weber>

On Thu, Nov 26, 2015 at 04:47:51PM +0100, Silvio Frischknecht wrote:
> >> data List t e = Cons e (List t e) | Null t
> > 
> > I think this is isomorphic to
> > 
> >     Producer e Identity r
> 
> Interesting. It does appear to be very similar.
> 
> Except that the Monad/Functor variable is 'r' not 'e'

Yes, I should have said isomorphic to 

    Producer e Identity t

The type parameters get arranged differently, so they will interact in
different ways with the standard typeclasses, but morally I think they are
the same.

Tom

From silvio.frischi at gmail.com  Thu Nov 26 23:01:31 2015
From: silvio.frischi at gmail.com (Silvio Frischknecht)
Date: Fri, 27 Nov 2015 00:01:31 +0100
Subject: [Haskell-cafe] Info about List with terminal element
In-Reply-To: <26e12188-37a3-4428-8a6b-23c77994de2a@googlegroups.com>
References: <56560550.1030905@gmail.com>
 <26e12188-37a3-4428-8a6b-23c77994de2a@googlegroups.com>
Message-ID: <56578F4B.6000702@gmail.com>



On 26.11.2015 21:35, Daniel D?az wrote:
> The type
> 
>     Cofree (Either t) e
> 
> 
> is isomorphic to a non-empty version of 
> 
>     List t e

Thanks. This is exactly the kind of thing I was looking for.

From romain.gehrig at gmail.com  Sat Nov 28 02:04:37 2015
From: romain.gehrig at gmail.com (Romain Gehrig)
Date: Sat, 28 Nov 2015 03:04:37 +0100
Subject: [Haskell-cafe] Why was this function that fast ?
Message-ID: <CADgYZhNP7QFMoTHEsQ0XaqjVk0g_F56Z6wynaP8CduxZqAnnYA@mail.gmail.com>

Hi,

I implemented a function to count how many steps it takes for a number to
be reduced to 1 using the Collatz Conjecture (also known as the 3n + 1
problem) and I was very surprised to see it working instantaneously for
integers as big as 10^100000.

The said function:

collatzSteps :: Integer -> Integer
collatzSteps n = steps 1 n
    where steps acc 1 = acc
          steps acc n' | even n' = steps (acc+1) (n' `div` 2)
          steps acc n'           = steps (acc+1) (n' * 3 + 1)


You can try in GHCi (apparently with an upper limit of 10^199669):

GHCi> collatzSteps 10^199668
[big num...]
GHCi> length $ show $ collatzSteps 10^199668
168740
GHCi> collatzSteps 10^199669 -- Oops
[1]    36128 bus error  ghci


Notice the number 168740: it is the number of *digits* for the number of
steps. It implies that the `acc` is ~= *10^168740* when the function ends.
Without optimisation at some point, it would mean there were as much
(acc+1) calls ! My understanding completely stops there; I can't comprehend
why a function that shouldn't return anything even long after the end of
the universe just finished before my eyes.

Can someone shed some light on how this peculiar function was optimised by
GHC?

Many thanks,
(still dazed) Romain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151128/6b97f101/attachment.html>

From holmgren at mit.edu  Sat Nov 28 02:21:35 2015
From: holmgren at mit.edu (Justin Holmgren)
Date: Fri, 27 Nov 2015 21:21:35 -0500
Subject: [Haskell-cafe] Why was this function that fast ?
In-Reply-To: <CADgYZhNP7QFMoTHEsQ0XaqjVk0g_F56Z6wynaP8CduxZqAnnYA@mail.gmail.com>
References: <CADgYZhNP7QFMoTHEsQ0XaqjVk0g_F56Z6wynaP8CduxZqAnnYA@mail.gmail.com>
Message-ID: <CAOSNmoY9QYDVckR7pvUvM8eSdbmdGJWEPxsHxK862BAH_vJn9A@mail.gmail.com>

Function application has higher precedence than exponentiation

On Fri, Nov 27, 2015 at 9:04 PM, Romain Gehrig <romain.gehrig at gmail.com>
wrote:

> Hi,
>
> I implemented a function to count how many steps it takes for a number to
> be reduced to 1 using the Collatz Conjecture (also known as the 3n + 1
> problem) and I was very surprised to see it working instantaneously for
> integers as big as 10^100000.
>
> The said function:
>
> collatzSteps :: Integer -> Integer
> collatzSteps n = steps 1 n
>     where steps acc 1 = acc
>           steps acc n' | even n' = steps (acc+1) (n' `div` 2)
>           steps acc n'           = steps (acc+1) (n' * 3 + 1)
>
>
> You can try in GHCi (apparently with an upper limit of 10^199669):
>
> GHCi> collatzSteps 10^199668
> [big num...]
> GHCi> length $ show $ collatzSteps 10^199668
> 168740
> GHCi> collatzSteps 10^199669 -- Oops
> [1]    36128 bus error  ghci
>
>
> Notice the number 168740: it is the number of *digits* for the number of
> steps. It implies that the `acc` is ~= *10^168740* when the function
> ends. Without optimisation at some point, it would mean there were as much
> (acc+1) calls ! My understanding completely stops there; I can't comprehend
> why a function that shouldn't return anything even long after the end of
> the universe just finished before my eyes.
>
> Can someone shed some light on how this peculiar function was optimised by
> GHC?
>
> Many thanks,
> (still dazed) Romain
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151127/128ce469/attachment.html>

From jeffbrown.the at gmail.com  Sat Nov 28 05:03:13 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Fri, 27 Nov 2015 21:03:13 -0800
Subject: [Haskell-cafe] How to create a Wiki account?
Message-ID: <CAEc4Ma0NFZc6X=OyV2Veryy5acf0HGdeZuu5VF7pb333rGowkw@mail.gmail.com>

This [1] is as close as I can seem to get. I noticed [2] had obsolete
information; it says Either is not by default a Monad.

[1] https://wiki.haskell.org/HaskellWiki:New_accounts
[2] https://wiki.haskell.org/Failure

-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151127/7d00c982/attachment.html>

From fvillanustre at gmail.com  Sat Nov 28 13:20:58 2015
From: fvillanustre at gmail.com (Flavio Villanustre)
Date: Sat, 28 Nov 2015 08:20:58 -0500
Subject: [Haskell-cafe] How to create a Wiki account?
In-Reply-To: <CAEc4Ma0NFZc6X=OyV2Veryy5acf0HGdeZuu5VF7pb333rGowkw@mail.gmail.com>
References: <CAEc4Ma0NFZc6X=OyV2Veryy5acf0HGdeZuu5VF7pb333rGowkw@mail.gmail.com>
Message-ID: <CAEUQ4QEYgabk-5eBnrz8UNr7DJt2MkK=mvJpUug5r7o0HucUbA@mail.gmail.com>

Jeffrey, I can help you with the wiki account. What account name would you
like?

Best,

Flavio
On Nov 28, 2015 12:03 AM, "Jeffrey Brown" <jeffbrown.the at gmail.com> wrote:

> This [1] is as close as I can seem to get. I noticed [2] had obsolete
> information; it says Either is not by default a Monad.
>
> [1] https://wiki.haskell.org/HaskellWiki:New_accounts
> [2] https://wiki.haskell.org/Failure
>
> --
> Jeffrey Benjamin Brown
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151128/73829576/attachment.html>

From ratzes at gmail.com  Sat Nov 28 16:17:15 2015
From: ratzes at gmail.com (ratzes at gmail.com)
Date: Sat, 28 Nov 2015 11:17:15 -0500
Subject: [Haskell-cafe] Why was this function that fast ?
In-Reply-To: <CAOSNmoY9QYDVckR7pvUvM8eSdbmdGJWEPxsHxK862BAH_vJn9A@mail.gmail.com>
References: <CADgYZhNP7QFMoTHEsQ0XaqjVk0g_F56Z6wynaP8CduxZqAnnYA@mail.gmail.com>
 <CAOSNmoY9QYDVckR7pvUvM8eSdbmdGJWEPxsHxK862BAH_vJn9A@mail.gmail.com>
Message-ID: <2E54B232-3A3A-4A3B-84E1-2EED4DE858FA@gmail.com>

Wow, nice catch!

> On Nov 27, 2015, at 9:21 PM, Justin Holmgren <holmgren at mit.edu> wrote:
> 
> Function application has higher precedence than exponentiation
> 
>> On Fri, Nov 27, 2015 at 9:04 PM, Romain Gehrig <romain.gehrig at gmail.com> wrote:
>> Hi,
>> 
>> I implemented a function to count how many steps it takes for a number to be reduced to 1 using the Collatz Conjecture (also known as the 3n + 1 problem) and I was very surprised to see it working instantaneously for integers as big as 10^100000.
>> 
>> The said function:
>> collatzSteps :: Integer -> Integer
>> collatzSteps n = steps 1 n
>>     where steps acc 1 = acc
>>           steps acc n' | even n' = steps (acc+1) (n' `div` 2)
>>           steps acc n'           = steps (acc+1) (n' * 3 + 1)
>> 
>> You can try in GHCi (apparently with an upper limit of 10^199669):
>> GHCi> collatzSteps 10^199668
>> [big num...]
>> GHCi> length $ show $ collatzSteps 10^199668
>> 168740 
>> GHCi> collatzSteps 10^199669 -- Oops
>> [1]    36128 bus error  ghci
>> 
>> Notice the number 168740: it is the number of digits for the number of steps. It implies that the `acc` is ~= 10^168740 when the function ends. Without optimisation at some point, it would mean there were as much (acc+1) calls ! My understanding completely stops there; I can't comprehend why a function that shouldn't return anything even long after the end of the universe just finished before my eyes.
>> 
>> Can someone shed some light on how this peculiar function was optimised by GHC?
>> 
>> Many thanks,
>> (still dazed) Romain
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151128/75a82e42/attachment.html>

From hjgtuyl at chello.nl  Sun Nov 29 10:36:51 2015
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Sun, 29 Nov 2015 11:36:51 +0100
Subject: [Haskell-cafe] How to create a Wiki account?
In-Reply-To: <CAEc4Ma0NFZc6X=OyV2Veryy5acf0HGdeZuu5VF7pb333rGowkw@mail.gmail.com>
References: <CAEc4Ma0NFZc6X=OyV2Veryy5acf0HGdeZuu5VF7pb333rGowkw@mail.gmail.com>
Message-ID: <op.x8uyfuu5pz0j5l@alquantor>

On Sat, 28 Nov 2015 06:03:13 +0100, Jeffrey Brown  
<jeffbrown.the at gmail.com> wrote:

> [...] I noticed [2] had obsolete
> information; it says Either is not by default a Monad.
>
> [...]
> [2] https://wiki.haskell.org/Failure

You are right, it was changed since this page was written; you are welcome  
to update the page.

Regards,
Henk-Jan van Tuyl


-- 
Folding at home
What if you could share your unused computer power to help find a cure? In  
just 5 minutes you can join the world's biggest networked computer and get  
us closer sooner. Watch the video.
http://folding.stanford.edu/


http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

From p.giarrusso at gmail.com  Sun Nov 29 11:54:28 2015
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Sun, 29 Nov 2015 03:54:28 -0800 (PST)
Subject: [Haskell-cafe] Compatibility etiquette for apps,
	with cabal sandboxes and `stack`
Message-ID: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>

Hi all,

IIUC, people used to spend nontrivial effort making their Haskell tools 
work across a range of dependencies, and be careful about dropping support 
for older ones. 

Do cabal sandboxes or Stack reduce that need, at least for applications?* 
Or conversely, how bad is it to restrict support to users having them? I 
guess I am asking about common policies, but this probably depends on 
adoption of those tools.

As in:

a) without sandboxes or Stack, packages need to build with whatever 
environment is there.
b) with either of sandboxes or Stack, you can just specify the environment 
and get it. With Stack, you can even specify whichever (supported) GHC you 
want, without impacting the environment.

Concretely, Control.Monad.Trans.Error is deprecated in 
transformers-0.4.3.0, but the replacement Control.Monad.Trans.Except does 
not exist in transformers-0.3.x, thus in the one-but-last Haskell Platform 
(2014.2.0.0). Hence, fixing the deprecation would make this application 
hard to install** for some users, including past me (around two months 
ago).*** Would you apply such a patch? Would you keep it out? Or would you 
even use CPP (something I'd really like to avoid)?

Cheers,
Paolo

* I take for granted libraries are a different matter ? composing libraries 
means intersecting their supported versions.
** I'll omit detailing "hard to install", because that's a matter of 
opinion; I considered `constraint: transformers installed` necessary in my 
cabal config (https://www.vex.net/~trebla/haskell/cabal-cabal.xhtml), and 
I've read that's becoming the default in the HP, so I think users are 
entitled to this opinion.
*** This particular app has a tiny userbase, so my question is a curiosity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/21bebdcb/attachment.html>

From omari at smileystation.com  Sun Nov 29 12:30:09 2015
From: omari at smileystation.com (Omari Norman)
Date: Sun, 29 Nov 2015 07:30:09 -0500
Subject: [Haskell-cafe] Fwd:  Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
Message-ID: <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>

On Sun, Nov 29, 2015 at 6:54 AM, Paolo Giarrusso <p.giarrusso at gmail.com>
wrote:

> Hi all,
>
> IIUC, people used to spend nontrivial effort making their Haskell tools
> work across a range of dependencies, and be careful about dropping support
> for older ones.
>

Given the tools we had, this was not easy.  I was never aware of any tool
that substantially helped with making sure that a package remained
compatible with the range of packages that was theoretically allowed by the
package's .cabal file.


> Do cabal sandboxes or Stack reduce that need, at least for applications?*
> Or conversely, how bad is it to restrict support to users having them? I
> guess I am asking about common policies, but this probably depends on
> adoption of those tools.
>
>
IMO there is really no one right answer to this question.  It depends on
how nice you are, or whether someone is paying you.  Obviously if someone
is paying you, do as she says or do what she needs.  If no one is paying
you, then how nice do you want to be by expending the work?  Honestly I'm
not very nice.  I keep stuff working in the current Stackage Nightly but
that's it.  Maintaining compatibility with huge dependency matrices is just
an enormous amount of work.  In my view, someone installing an application
can just use stack and Stackage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/dc3eb1ba/attachment.html>

From michael at orlitzky.com  Sun Nov 29 15:40:42 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Sun, 29 Nov 2015 10:40:42 -0500
Subject: [Haskell-cafe] Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
Message-ID: <565B1C7A.4080208@orlitzky.com>

On 11/29/2015 06:54 AM, Paolo Giarrusso wrote:
> Hi all,
> 
> IIUC, people used to spend nontrivial effort making their Haskell tools
> work across a range of dependencies, and be careful about dropping
> support for older ones. 
> 
> Do cabal sandboxes or Stack reduce that need, at least for
> applications?* Or conversely, how bad is it to restrict support to users
> having them? I guess I am asking about common policies, but this
> probably depends on adoption of those tools.
> 

If your application can't be installed through a package manager, a lot
of end users and every system administrator are going to pretend it
doesn't exist. Using stack/sandboxes hides the fact that the ecosystem
is broken from the developer, but it cannot be hidden from the end user.
Please make sure any such breakage is not your fault =)


From p.giarrusso at gmail.com  Sun Nov 29 16:37:11 2015
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Sun, 29 Nov 2015 08:37:11 -0800 (PST)
Subject: [Haskell-cafe] Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAKA2JgL2_Ah5nNJFdgUCqxTR=9KCcXmhNMdsE9y_eYjD9fmv2A@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAKA2JgL2_Ah5nNJFdgUCqxTR=9KCcXmhNMdsE9y_eYjD9fmv2A@mail.gmail.com>
Message-ID: <0b2d9d9b-bd48-42b8-84f7-0dc5fd51a2d8@googlegroups.com>

On Sunday, November 29, 2015 at 1:23:58 PM UTC+1, Michael Snoyman wrote:
>
> For your particular example, you can use the transformers-compat package.
>

Thanks, that's useful!

But to answer your general question: for applications, I strongly advocate 
> supporting just a single set of package version combos for dependencies. 
> Stack does do this by default, but cabal freeze files can get you most of 
> the way there too (barring some corner cases with different OSes and 
> OS-specific packages).
>
> I'm sure others will disagree with this recommendation, but I see no 
> reason to absorb a large amount of compatibility work just so that two 
> installations of the same application may end up behaving differently at 
> runtime because of differences in the behavior of a dependency.
>
 
Personally, I switched all the way to stack. I added mention of cabal 
sandboxes to address anybody who didn't switch yet or who prefers to stick 
to cabal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/4d387a41/attachment.html>

From simons at cryp.to  Sun Nov 29 16:37:15 2015
From: simons at cryp.to (Peter Simons)
Date: Sun, 29 Nov 2015 17:37:15 +0100
Subject: [Haskell-cafe] Fwd:  Compatibility etiquette for apps,
	with cabal sandboxes and `stack`
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
Message-ID: <871tb8dao4.fsf@write-only.cryp.to>

Omari Norman writes:

 > Someone installing an application can just use stack and Stackage.

I wonder how many people would be using XMonad, git-annex, etc. if this
view were common place among application developers.

I'm pretty sure that a large part of the user base of these tools has no
clue "stack" exists, even, and the only reason why they can install
these programs is because their distributions package manager allows
then to do so without exposing them to any Haskell-specific build tools.

Best regards,
Peter


From p.giarrusso at gmail.com  Sun Nov 29 16:51:34 2015
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Sun, 29 Nov 2015 08:51:34 -0800 (PST)
Subject: [Haskell-cafe] Fwd:  Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <871tb8dao4.fsf@write-only.cryp.to>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
Message-ID: <88801bd7-4c74-43be-930c-8f48d7cde1bd@googlegroups.com>

On Sunday, November 29, 2015 at 5:37:35 PM UTC+1, Peter Simons wrote:
>
> Omari Norman writes: 
>
>  > Someone installing an application can just use stack and Stackage. 
>
> I wonder how many people would be using XMonad, git-annex, etc. if this 
> view were common place among application developers. 
>
> I'm pretty sure that a large part of the user base of these tools has no 
> clue "stack" exists, even, and the only reason why they can install 
> these programs is because their distributions package manager allows 
> then to do so without exposing them to any Haskell-specific build tools. 
>

I guess you're thinking of different markets: "uses git-annex" is indeed 
(probably) orthogonal even to "knows there's a programming language called 
Haskell" (I might be exaggerating); I agree there distributing via Hackage 
is not a good option.

But developers of, say, `hlint` have (I guess arguably) another target 
audience ? Haskell developers; my question was about this audience, and 
Omari Norman's answer makes sense there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/4c50a758/attachment.html>

From diaz.carrete at gmail.com  Sun Nov 29 17:00:09 2015
From: diaz.carrete at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz?=)
Date: Sun, 29 Nov 2015 09:00:09 -0800 (PST)
Subject: [Haskell-cafe] Semi-closed handles and I/O errors: misleading
	documentation?
Message-ID: <0b7dbf06-9885-40e2-a0cb-818e8c4b9167@googlegroups.com>

In the documentation for System.IO 
<http://hackage.haskell.org/package/base-4.8.1.0/docs/System-IO.html>, we 
find the following assertion:

Any I/O errors encountered while a handle is semi-closed are simply 
discarded.


also this other one:

Encoding and decoding errors are always detected and reported, except 
during lazy I/O (hGetContents, getContents, and readFile), where a decoding 
error merely results in termination of the character stream, as with other 
I/O errors.


Is this really correct, though? This SO question 
<http://stackoverflow.com/questions/16257037/detecting-i-o-exceptions-in-a-lazy-string-from-hgetcontents> 
says that exceptions found during lazy I/O are thrown from pure code, and a small 
experiment <http://stackoverflow.com/a/33985047/1364288> seems to confirm 
it. I personally prefer that behaviour, by the way. 

Perhaps the documentation should be updated?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/17d26529/attachment.html>

From simons at cryp.to  Sun Nov 29 17:25:17 2015
From: simons at cryp.to (Peter Simons)
Date: Sun, 29 Nov 2015 18:25:17 +0100
Subject: [Haskell-cafe] Compatibility etiquette for apps,
	with cabal sandboxes and `stack`
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <88801bd7-4c74-43be-930c-8f48d7cde1bd@googlegroups.com>
Message-ID: <87lh9gbtvm.fsf_-_@write-only.cryp.to>

Hi Paolo,

 > But developers of, say, `hlint` have (I guess arguably) another
 > target audience ? Haskell developers; my question was about this
 > audience, and Omari Norman's answer makes sense there.

personally, I never install anything with stack or cabal-install,
regardless of whether it's a tool intended for Haskell developers or
not. Stack and cabal-install are great tools to use during code
development, but neither of them has the capabilities I want from a
package manager.

Just my 2 cents,
Peter


From omari at smileystation.com  Sun Nov 29 18:37:29 2015
From: omari at smileystation.com (Omari Norman)
Date: Sun, 29 Nov 2015 13:37:29 -0500
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <871tb8dao4.fsf@write-only.cryp.to>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
Message-ID: <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>

On Sun, Nov 29, 2015 at 11:37 AM, Peter Simons <simons at cryp.to> wrote:

> Omari Norman writes:
>
>  > Someone installing an application can just use stack and Stackage.
>
> I wonder how many people would be using XMonad, git-annex, etc. if this
> view were common place among application developers.
>

Maybe zero.  If an application developer cares about popularity, he should
consider these things.  Not all application developers care how many users
they have.

I'm pretty sure that a large part of the user base of these tools has no
> clue "stack" exists, even, and the only reason why they can install
> these programs is because their distributions package manager allows
> then to do so without exposing them to any Haskell-specific build tools.
>

Distribution packagers are savvy enough to use stack.  Furthermore,
distributions do not install using cabal or from Hackage.  Therefore, by
your reasoning just as many people would be using XMonad, git-annex, etc.
because the distribution packager would get the package, make the necessary
alterations, and upload the distribution-specific package to the repository.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/ca3abf70/attachment.html>

From michael at orlitzky.com  Sun Nov 29 19:12:11 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Sun, 29 Nov 2015 14:12:11 -0500
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
Message-ID: <565B4E0B.5090703@orlitzky.com>

On 11/29/2015 01:37 PM, Omari Norman wrote:
> 
> Distribution packagers are savvy enough to use stack.

Ignoring the question of *how* that might work, most distributions
forbid bundled dependencies because it creates a maintenance nightmare
and fills our users' machines with untraceable security vulnerabilities.
Literally no one does this, so I'm not sure what you're claiming here.


> Furthermore, distributions do not install using cabal or from Hackage.

They do install from Hackage, just not using cabal-install.


> Therefore, by your reasoning just as many people would be using
> XMonad, git-annex, etc. because the distribution packager would get
> the package, make the necessary alterations, and upload the
> distribution-specific package to the repository.

When using a real package manager, every package's dependencies must be
satisfied simultaneously. Using stack isolates the developer from
dependency conflicts with other packages during development, but when a
user goes to install it, he doesn't have that luxury.

If the developers of xmonad and git-annex both use stack/sandboxes, then
it's possible that one of them will introduce a dependency that
conflicts with the other, and neither developer will notice it thanks to
the sandboxes. But if a user tries to install both at the same time, he
can't, because (for example) xmonad wants foo-1.0 and git-annex wants
foo-2.0.

As a volunteer packager, I'm not going to fix that for you, I'm just
going to work on something else whose upstream isn't a pain in the ass.



From omari at smileystation.com  Sun Nov 29 19:39:42 2015
From: omari at smileystation.com (Omari Norman)
Date: Sun, 29 Nov 2015 14:39:42 -0500
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565B4E0B.5090703@orlitzky.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
Message-ID: <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>

On Sun, Nov 29, 2015 at 2:12 PM, Michael Orlitzky <michael at orlitzky.com>
wrote:



> > Furthermore, distributions do not install using cabal or from Hackage.
>
> They do install from Hackage, just not using cabal-install.


So there's a distribution out there where end users pull source from
Hackage, pull source for every dependency, and then build it all with GHC?
If they're not doing what distributors like Debian does--building
binaries--then what's the point of distributing at all?

When using a real package manager, every package's dependencies must be
> satisfied simultaneously.


True, but ouch, ultimately this is one factor that pushed me out of desktop
Linux altogether.  It's too hard to get packages for things I want to use,
and then I'm fending for myself by building things.  Centrally-planned
packaging does not scale.


> Using stack isolates the developer from
> dependency conflicts with other packages during development, but when a
> user goes to install it, he doesn't have that luxury.
>

He does if he uses stack.  Grab a stack binary.  It even installs GHC for
the user.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/ac45f1ff/attachment.html>

From imantc at gmail.com  Sun Nov 29 19:52:18 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 29 Nov 2015 20:52:18 +0100
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
Message-ID: <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>

Just thought of something that might help to deal with dependency nuisance:

What if the top package (in namespace)  contained major version?

E.g. Cabal_1_22

below packages might use minor versions - basically, whenever api changes,
change the version part of the affected package.

Here by package I mean part of the namespace.

This way, different versions could coexist quite painlessly..

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/74816335/attachment.html>

From svenpanne at gmail.com  Sun Nov 29 20:13:22 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 29 Nov 2015 21:13:22 +0100
Subject: [Haskell-cafe] Fwd:  Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
Message-ID: <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>

[... and now to the whole list, I hate gmail's defaults... :-]

---------- Forwarded message ----------
From: Sven Panne <svenpanne at gmail.com>
Date: 2015-11-29 21:12 GMT+01:00
Subject: Re: [Haskell-cafe] Fwd: Compatibility etiquette for apps, with
cabal sandboxes and `stack`
To: Imants Cekusins <imantc at gmail.com>


2015-11-29 20:52 GMT+01:00 Imants Cekusins <imantc at gmail.com>:

> [...] What if the top package (in namespace)  contained major version?
>
> E.g. Cabal_1_22
>
> below packages might use minor versions - basically, whenever api changes,
> change the version part of the affected package. [...]
>
As a developer, what should I import if my program/library works with e.g.
the version range [1.20 .. 1.23]? It definitely can't be

   import Cabal_1_23.Foo.Bar

because if it later still works with e.g. 1.24, I would have to rename all
my imports. And always using the lower bound is probably too restrictive,
unless I'm mistaken... In general I think it's a bad idea to spread build
dependencies all over the code.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/3b963d80/attachment.html>

From imantc at gmail.com  Sun Nov 29 20:23:48 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 29 Nov 2015 21:23:48 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
Message-ID: <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>

> As a developer, what should I import if my program/library works with e.g. the version range [1.20 .. 1.23]?

maybe change only that part of the namespace where api changed?

also, why not publish less frequently? I mean, nothing stops anyone
from making frequent changes to  a library, but why not limit number
of versions released to public?

From svenpanne at gmail.com  Sun Nov 29 20:36:14 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 29 Nov 2015 21:36:14 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
 <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
Message-ID: <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>

2015-11-29 21:23 GMT+01:00 Imants Cekusins <imantc at gmail.com>:

> > As a developer, what should I import if my program/library works with
> e.g. the version range [1.20 .. 1.23]?
>
> maybe change only that part of the namespace where api changed?
>

In the exporting library? In the importing library?

also, why not publish less frequently? I mean, nothing stops anyone
> from making frequent changes to  a library, but why not limit number
> of versions released to public?
>

Could you explain this in more detail, please? I don't seem to understand
what you're proposing... :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/4a0be76b/attachment.html>

From michael at orlitzky.com  Sun Nov 29 20:46:42 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Sun, 29 Nov 2015 15:46:42 -0500
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
Message-ID: <565B6432.3020907@orlitzky.com>

On 11/29/2015 02:39 PM, Omari Norman wrote:
> 
> So there's a distribution out there where end users pull source from
> Hackage, pull source for every dependency, and then build it all with
> GHC?  If they're not doing what distributors like Debian does--building
> binaries--then what's the point of distributing at all?

Sure, all of the source-based distributions use the upstream tarball and
compile it. The point of creating a "package" is so that you can have a
real package manager manage your dependencies. Since most of the
dependency info is contained in the cabal file, the packages are usually
trivial. Gentoo, Nix, and FreeBSD all have tools that will convert a
hackage package into a distribution package automatically.


>     When using a real package manager, every package's dependencies must be
>     satisfied simultaneously.
> 
> 
> True, but ouch, ultimately this is one factor that pushed me out of
> desktop Linux altogether.  It's too hard to get packages for things I
> want to use, and then I'm fending for myself by building things. 
> Centrally-planned packaging does not scale.

Given that almost all Linux systems in existence uses centrally-planned
packaging, I don't believe that last claim. How many programs can you
realistically keep installed and up-to-date with stack? Ten, twenty
maybe -- if this is a serious hobby for you. One or two hundred if it's
your full-time job?

A typical Linux system will have hundreds of packages, and a system
administrator will need to manage tens or hundreds of those systems.
It's just not possible to do with something like stack -- you need one
package manager that does everything.

I'm not saying you need to rely on e.g. Debian upstream to create
packages for you (I certainly don't), but you do need to have "system"
packages for everything installed. This actually isn't very hard with
those automated tools I mentioned earlier.


>     Using stack isolates the developer from
>     dependency conflicts with other packages during development, but when a
>     user goes to install it, he doesn't have that luxury.
> 
> 
> He does if he uses stack.  Grab a stack binary.  It even installs GHC
> for the user.

If the user is highly technical and he wants to make stack
administration his weekend activity. Otherwise, this isn't feasible for
more than one or two packages.

You can easily convince yourself of this: set up ten virtual machines,
and install 20 packages using stack on each of them. Now keep them
up-to-date for a year. If you're very good at bookkeeping and time
management, it might even be possible. But it's not going to be a fun
year. And 200 packages is barely enough to boot a single web server.


From imantc at gmail.com  Sun Nov 29 21:03:14 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 29 Nov 2015 22:03:14 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
 <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
 <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>
Message-ID: <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>

> In the exporting library? In the importing library?

Well, in both places. Basically, similar part of namespace guarantees that
api is the same below.

If api (or code) changed, then it will lead to  a different result.

As consumer of a library, you'd refer to exactly the version you used while
developing. This exact same version would be pulled in alongside other
versions of the same library, used in other parts of a large app.

It may lead to code duplication and larger binaries however it would
essentially give you a sandbox with very little effort.

>> also, why not publish less frequently?

> Could you explain this in more detail, please? I don't seem to understand
what you're proposing... :-/

Well, let's say I am working on a library. Tempting as it is to release the
first draft, I'd first use this fresh library in a few places, catch some
bugs, fix them, and then release.

Because this takes time, this library would see very few releases per year.

It would be less likely to cause multiple  version conflict.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/ed9e5edb/attachment.html>

From imantc at gmail.com  Sun Nov 29 21:15:38 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Sun, 29 Nov 2015 22:15:38 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
 <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
 <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>
 <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>
Message-ID: <CAP1qinaOhxpSZVPGJ2qk_XqSr1vhLrS5=D5KxCyTccUqtY_Szg@mail.gmail.com>

Here is an allegory:

There is Toyota 1985 and Toyota 2010.

Although they both are Toyotas, they may be very different cars.

ads show cars by brand, model and year, because brand alone is rarely
enough.

So why not spell this out in code? Why dump this task on tools which can
not really tell what importing code actually requires?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/dfce1c03/attachment.html>

From jo at durchholz.org  Sun Nov 29 21:19:47 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Sun, 29 Nov 2015 22:19:47 +0100
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565B6432.3020907@orlitzky.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <565B6432.3020907@orlitzky.com>
Message-ID: <565B6BF3.7040605@durchholz.org>

Am 29.11.2015 um 21:46 schrieb Michael Orlitzky:
> On 11/29/2015 02:39 PM, Omari Norman wrote:
>>
>> So there's a distribution out there where end users pull source from
>> Hackage, pull source for every dependency, and then build it all with
>> GHC?  If they're not doing what distributors like Debian does--building
>> binaries--then what's the point of distributing at all?
>
> Sure, all of the source-based distributions use the upstream tarball and
> compile it. The point of creating a "package" is so that you can have a
> real package manager manage your dependencies. Since most of the
> dependency info is contained in the cabal file, the packages are usually
> trivial. Gentoo, Nix, and FreeBSD all have tools that will convert a
> hackage package into a distribution package automatically.
>
>
>>      When using a real package manager, every package's dependencies must be
>>      satisfied simultaneously.
>>
>>
>> True, but ouch, ultimately this is one factor that pushed me out of
>> desktop Linux altogether.  It's too hard to get packages for things I
>> want to use, and then I'm fending for myself by building things.
>> Centrally-planned packaging does not scale.
>
> Given that almost all Linux systems in existence uses centrally-planned
> packaging, I don't believe that last claim.

What does not scale is having to beg, bribe, or strong-arm upstreams 
into using a consistent set of library versions. You'll run into 
situation where application A wants libraries X.5 and Y.6, and 
application B wants X.6 and Y.4, and at that point, you'll have to make 
a hard decision between A and B.

One way out is to make it so that multiple versions of the same library 
can be installed at the same time. C-based packages do this routinely by 
installing not libX and libY, but by installing libX-5, libX-6, libY.4, 
and libY.6. This still requires a mechanism to automatically select the 
right packaged lib, so the Haskell runtime will have to be told which 
libraries at what versions to combine with a given application. This 
could be totally easy or a huge PITA, I don't know enough about Haskell 
(I just happen to have a lot of administration experience with Linux).

Another way out is to statically link each application, and avoid 
library packages entirely. It's viable only because we have 
multi-terabyte harddisks and multi-gigabyte RAM these days, and probably 
not what everybody wants to do.

One thing that does not work at all in my experience is situations where 
you have a software ecosystem that's orthogonal to the OS. Typical 
package managers offer no way of having a local install, so my Eclipse 
installation typically consists of a download somewhere into my home 
directory, and plugins installed into that. Python is similar - I almost 
never install a Python application directly, I download it, use a 
virtualenv (Python's sandboxing method), and let it pull in and set up 
any dependencies it wants or needs.
These local installs are all wheel reinventions, it would be better if 
apt, yum, rpm etc. supported local installs (in the form of "please 
install this into THAT directory inside my home dir, thank you very 
much"), and kept these installs separate. You can do stuff like that, 
but it requires expert knowledge so it's not an option for application 
installs.

 > How many programs can you
> realistically keep installed and up-to-date with stack? Ten, twenty
> maybe -- if this is a serious hobby for you. One or two hundred if it's
> your full-time job?
>
> A typical Linux system will have hundreds of packages, and a system
> administrator will need to manage tens or hundreds of those systems.
> It's just not possible to do with something like stack -- you need one
> package manager that does everything.

True for operating systems. Or anything else that needs to "just work" 
without bothering about specific versions.
Not so true for those individual applications. Of these, you often need 
a specific version, and since nothing in the OS depends on them, it's 
okay to have these installed independently of the package manager (but 
these applications can have such complicated dependency setups that 
they'll need their own package managers - Eclipse and Python come with 
such things for exactly that reason).

Regards,
Jo

From p.giarrusso at gmail.com  Sun Nov 29 23:11:06 2015
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Mon, 30 Nov 2015 00:11:06 +0100
Subject: [Haskell-cafe] Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565B6432.3020907@orlitzky.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <565B6432.3020907@orlitzky.com>
Message-ID: <CAAcnjCSaoNgROLevLp5Uf6oOnNPU8+Z1-a5wscYDf0ee9tzXcg@mail.gmail.com>

On 29 November 2015 at 21:46, Michael Orlitzky <michael at orlitzky.com> wrote:
> On 11/29/2015 02:39 PM, Omari Norman wrote:
>>
>> So there's a distribution out there where end users pull source from
>> Hackage, pull source for every dependency, and then build it all with
>> GHC?  If they're not doing what distributors like Debian does--building
>> binaries--then what's the point of distributing at all?

> Gentoo, Nix, and FreeBSD all have tools that will convert a
> hackage package into a distribution package automatically.

> I'm not saying you need to rely on e.g. Debian upstream to create
> packages for you (I certainly don't), but you do need to have "system"
> packages for everything installed. This actually isn't very hard with
> those automated tools I mentioned earlier.

OK, that might be a (somewhat) reasonable alternative to using
`cabal-install` or `stack` as a package manager ?  for users of those
distros only. I know the mantra `cabal` is not a package manager, and
that usually read as "`cabal` doesn't want to support its users'
needs".
I'm on OS X + Homebrew though.

Also, as long as you just want to upgrade, a working `cabal upgrade`
would be enough (and maybe within reach after the upcoming cabal
changes); `stack upgrade-all` could also do the job. Bigger problems
are removing packages and intermediate build products.

-- 
Paolo G. Giarrusso - Ph.D. Student, T?bingen University
http://ps.informatik.uni-tuebingen.de/team/giarrusso/

From p.giarrusso at gmail.com  Sun Nov 29 23:11:58 2015
From: p.giarrusso at gmail.com (Paolo Giarrusso)
Date: Mon, 30 Nov 2015 00:11:58 +0100
Subject: [Haskell-cafe] Fwd:  Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
Message-ID: <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>

On 29 November 2015 at 20:12, Michael Orlitzky <michael at orlitzky.com> wrote:
> On 11/29/2015 01:37 PM, Omari Norman wrote:
>>
>> Distribution packagers are savvy enough to use stack.
>
> Ignoring the question of *how* that might work, most distributions
> forbid bundled dependencies because it creates a maintenance nightmare
> and fills our users' machines with untraceable security vulnerabilities.

But doesn't Haskell do static linking (usually) and cross-module
inlining? Or are you fine with static linking as long as it's somehow
tracked by the package manager, so that upgrading some-vuln-lib from
1.0 to 1.1 forces upgrading all client programs (looks quite doable at
least with Debian packages)?

--
Paolo G. Giarrusso - Ph.D. Student, T?bingen University
http://ps.informatik.uni-tuebingen.de/team/giarrusso/

-- 
Paolo G. Giarrusso - Ph.D. Student, T?bingen University
http://ps.informatik.uni-tuebingen.de/team/giarrusso/

From michael at orlitzky.com  Sun Nov 29 23:24:52 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Sun, 29 Nov 2015 18:24:52 -0500
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
 <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>
Message-ID: <565B8944.2020303@orlitzky.com>

On 11/29/2015 06:11 PM, Paolo Giarrusso wrote:
> On 29 November 2015 at 20:12, Michael Orlitzky <michael at orlitzky.com> wrote:
>> On 11/29/2015 01:37 PM, Omari Norman wrote:
>>>
>>> Distribution packagers are savvy enough to use stack.
>>
>> Ignoring the question of *how* that might work, most distributions
>> forbid bundled dependencies because it creates a maintenance nightmare
>> and fills our users' machines with untraceable security vulnerabilities.
> 
> But doesn't Haskell do static linking (usually) and cross-module
> inlining? Or are you fine with static linking as long as it's somehow
> tracked by the package manager, so that upgrading some-vuln-lib from
> 1.0 to 1.1 forces upgrading all client programs (looks quite doable at
> least with Debian packages)?
> 

GHC does dynamic linking now, but I'm OK with static linking as long as
it's tracked. The end result is the same as if you had dynamic linking,
only with a lot more wasted space and rebuilds/reinstalls.


From roconnor at theorem.ca  Mon Nov 30 04:23:11 2015
From: roconnor at theorem.ca (roconnor at theorem.ca)
Date: Sun, 29 Nov 2015 20:23:11 -0800 (PST)
Subject: [Haskell-cafe] A new case for the pointed functor class
Message-ID: <alpine.LRH.2.11.1511292014190.5788@turing.theorem.ca>

>From <http://r6research.livejournal.com/28338.html>:


There has been some debate for some time as to whether there should be a 
superclass for Applicative with just the pure function should exist:

-- Natural law:
-- fmap f . pure = pure . f
class Functor f => Pointed f where
   pure :: a -> f a

The charge laid against this class is that there are no laws for this 
single function beyond the single law that is naturally implied. Compare 
this to a more reasonable class

-- Natural laws:
-- distRight . right . fmap f = fmap (right f) . distRight
-- distRight . left f = fmap (left f) . distRight
--
-- Other laws:
-- 1. either absurd (fmap Right) = distRight :: Either Void (f a) -> f (Either Void a)
-- 2. fmap assocL . distRight . right distRight . assocR = distRight :: Either (Either a b) (f c) -> f (Either (Either a b) c)
--  where
--   assocL :: Either a (Either b c) -> Either (Either a b) c
--   assocL (Left a) = Left (Left a)
--   assocL (Right (Left a)) = Left (Right a)
--   assocL (Right (Right a)) = Right a
--   assocR :: Either (Either a b) c -> Either a (Either b c)
--   assocR (Left (Left a)) = Left a
--   assocR (Left (Right a)) = Right (Left a)
--   assocR (Right a) = Right (Right a)
class Functor f => StrongSum f where
   distRight :: Either a (f b) -> f (Either a b)

   distLeft :: Either (f a) b -> f (Either a b)
   distLeft = fmap switch . distRight . switch
    where
     switch :: Either a b -> Either b a
     switch = Right ||| Left

StrongSum is a honest class with two additional real laws in addition to 
its natural laws. No one would object to creating and using such a class.

What if I told you that Pointed and StrongSum are in fact the same class?

class Functor f => Pointed f where
   pure :: a -> f a
   pure = fmap (id ||| absurd) . distRight . Left

   distRight : Either a (f b) -> f (Either a b)
   distRight = either (fmap Left . pure) (fmap Right)

Theorem 1. If we define pure, then the distRight automatically satisfies 
the 2 required laws.

Proof. Law 1:

either absurd (fmap Right)
= { extensionality of absurd }
either (fmap Left . pure) (fmap Right)
= { definition in terms of pure }
distRight :: Either Void (f a) -> f (Either Void a)

Law 2: fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR
  = either (fmap Left . pure) (fmap Right)

case 1: Right x

fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Right x
=
fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Right x)
=
fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Right x))
=
fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Right x)
=
fmap assocL $ fmap Right (fmap Right x)
=
fmap (assocL . Right . Right) x
=
fmap Right x
=
either (fmap Left . pure) (fmap Right) $ Right x

case 2: Left (Right x)

fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Right x)
=
fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Right (Left x)
=
fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (either (fmap Left . pure) (fmap Right) (Left x))
=
fmap assocL . either (fmap Left . pure) (fmap Right) $ Right (fmap Left (pure x))
=
fmap assocL $ fmap Right (fmap Left (pure x))
=
fmap (assocL . Right . Left) (pure x)
=
fmap (Left . Right) (pure x)
=
fmap Left . fmap Right . pure $ x
=
fmap Left . pure . Right $ x
=
fmap Left . pure $ Right x
=
either (fmap Left . pure) (fmap Right) $ Left (Right x)

case 3: Left (Left x)

fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) . assocR $ Left (Left x)
=
fmap assocL . either (fmap Left . pure) (fmap Right) . right (either (fmap Left . pure) (fmap Right)) $ Left x
=
fmap assocL . either (fmap Left . pure) (fmap Right) $ Left x
=
fmap assocL . fmap Left . pure $ x
=
fmap (assocL . Left) . pure $ x
=
fmap (Left . Left) . pure $ x
=
fmap Left . fmap Left . pure $ x
=
fmap Left . pure . Left $ x
=
fmap Left . pure $ Left x
=
either (fmap Left . pure) (fmap Right) $ Left (Left x)

Theorem 2. If we define pure, then
pure = fmap (id ||| absurd) . distRight . Left where distRight = either (fmap Left . pure) (fmap Right)

Proof.

fmap (id ||| absurd) . distRight . Left
=
fmap (id ||| absurd) . either (fmap Left . pure) (fmap Right) . Left
=
fmap (id ||| absurd) . fmap Left . pure
=
fmap ((id ||| absurd) . Left) . pure
=
fmap id . pure
=
pure

Theorem 3. If we define distRight such that distRight satisfies its two 
laws then distRight = either (fmap Left . pure) (fmap Right) where pure = 
fmap (id ||| absurd) . distRight . Left.

Proof. either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right)
  = distRight

case 1: Left x

either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Left x
=
fmap Left . fmap (id ||| absurd) . distRight $ Left x
=
fmap (Left . (id ||| absurd)) $ distRight (Left x)
=
fmap (Left ||| (Left . absurd)) $ distRight (Left x)
=
fmap (Left ||| absurd) $ distRight (Left x)
= { extensionality of absurd }
fmap (Left ||| Right) $ distRight (Left x)
=
fmap id $ distRight (Left x)
=
distRight (Left x)

case 2: Right x

either (fmap Left . fmap (id ||| absurd) . distRight . Left) (fmap Right) $ Right x
=
fmap Right x
=
fmap (left absurd . Right) x
=
fmap (left absurd) $ fmap Right x
=
fmap (left absurd) . either absurd (fmap Right) $ Right x
= { Law 1 for distRight }
fmap (left absurd) . distRight $ Right x
= { Natural law for distRight }
distRight . left absurd $ Right x
=
distRight $ Right x

Interestingly we only ever used the first law for distRight. By composing 
these proofs together we should be able to show that the second law for 
distRight holds whenever the first law does.

In conclusion we have seen that the StrongSum class and the Pointed class 
are equivalent classes. The pure function contains the heart of what a law 
abiding distRight function is, such that whenever we have a law abiding 
distRight function it can be written in terms of pure and every instance 
of pure yields a law abiding distRight function. Given that I think people 
would welcome a StrongSum class, it only makes sense to equally welcome 
the Pointed class.

-- 
Russell O'Connor                                      <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

From svenpanne at gmail.com  Mon Nov 30 07:20:30 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Mon, 30 Nov 2015 08:20:30 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
 <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
 <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>
 <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>
Message-ID: <CANBN=msS6bcic24m3p2j1mgCZerH3OZHRWcYJOSQLbhOUy6BhA@mail.gmail.com>

2015-11-29 22:03 GMT+01:00 Imants Cekusins <imantc at gmail.com>:

> > In the exporting library? In the importing library?
>
> Well, in both places. Basically, similar part of namespace guarantees that
> api is the same below.
>
To make this work on the exporting side, the namespace hierarchy would need
to be structured according to API versions. This would mean constant
reshuffling of modules in the hierarchy every time you make an API change.
Furthermore, speaking from a more aesthetical point of view, names in the
hierarchy should have some sensible semantic meaning and should not be
littered with more or less random name suffixes.

> [...] This exact same version would be pulled in alongside other versions
> of the same library, used in other parts of a large app.
>
This won't work when e.g.the libraries have a C part (unless you convince
all people out there to use some kind consistent hierarchical naming scheme
for C, too).


> It may lead to code duplication and larger binaries however it would
> essentially give you a sandbox with very little effort.
>
Personally, I don't consider littering my code with version numbers as
"little effort". Stuff like this should be specified outside of the source
code IMHO.

> Well, let's say I am working on a library. Tempting as it is to release
> the first draft, I'd first use this fresh library in a few places, catch
> some bugs, fix them, and then release.
>
> Because this takes time, this library would see very few releases per year.
>
> It would be less likely to cause multiple  version conflict.
>
This contradicts the common "release early, release often" scheme of doing
things, which has *many* advantages. And the number of releases is not
relevant in itself, it's how often you change the API, which is a totally
different matter. The longer you wait with releases, the higher the chance
is that the next release has an incompatible API change, and your users
won't get bug fixes without that API change, which won't make them
especially happy.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151130/3bd528a2/attachment.html>

From plredmond at gmail.com  Mon Nov 30 07:45:18 2015
From: plredmond at gmail.com (Patrick Redmond)
Date: Sun, 29 Nov 2015 23:45:18 -0800
Subject: [Haskell-cafe] make a server & connect to it - strange behavior
In-Reply-To: <CAHUea4F64yuNzNqwBGD_EnPf12yf2FMMxLoYKqf2AmqHP_ON6Q@mail.gmail.com>
References: <CAHUea4F64yuNzNqwBGD_EnPf12yf2FMMxLoYKqf2AmqHP_ON6Q@mail.gmail.com>
Message-ID: <CAHUea4Eu78MZiWmYywjPix87dF5WwrU-b2MqwRAUrpOE3S=rLQ@mail.gmail.com>

For any curious, I found a smaller example of the root cause and sorted it
out. The previously linked-to repo is no longer up.

https://github.com/GaloisInc/http-server/issues/8#

The http-server library requires that the provided handler function appends
a "Connection: close" to the response, or it leaves the connection open.

On Thu, Nov 26, 2015 at 1:10 AM, Patrick Redmond <plredmond at gmail.com>
wrote:

> Hi Haskell Cafe,
>
> When I start a web server (http-server:Network.HTTP.Server.serverWith) on
> a separate thread (async:Control.Concurrent.Async.withAsync) and then try
> to retrieve a response from the server (HTTP:Network.Browser.*) on a
> threaded runtime, I see either
>
>    - connection refusals or
>    - deadlock.
>
> Before I sink time into reading the source of the packages in question,
> does anybody see what's wrong with the code below?
>
> Increasing the timeout to wait for the server to initialize doesn't solve
> the problem. Using a bound thread doesn't solve the problem. I'm compiling
> with options "-threaded -rtsopts -with-rtsopts=-N".
>
> Thank you for taking a look.
> --Patrick
>
> This test project is on github.
> <https://github.com/plredmond/http-server-test-hs/blob/master/src/Lib.hs>
>
> module Lib
>     ( someFunc
>     ) where
>
> import Control.Monad.IO.Class (liftIO)
> import qualified Control.Concurrent as Concurrent
> import qualified Control.Concurrent.Async as Async
> import qualified Control.Exception as Exception
> import qualified Data.Maybe as Maybe
> import qualified Network.Browser as Browser
> import qualified Network.HTTP as HTTP
> import qualified Network.HTTP.Server as Server
> import qualified Network.HTTP.Server.Logger as ServerL
> import qualified Network.HTTP.Server.Response as ServerR
> import qualified Network.URI as URI
>
> someFunc :: IO (Either Exception.SomeException (URI.URI, HTTP.Response
> String))
> someFunc = do
>     Async.withAsync (Server.serverWith config handler) $ \_ -> do
>         Concurrent.threadDelay . round $ 2e6
>         Exception.try . Browser.browse . Browser.request .
> Browser.defaultGETRequest $ uri
>     where
>         uri = Maybe.fromJust . URI.parseURI $ "http://localhost:8080/"
>         config = Server.Config ServerL.stdLogger "localhost" 8080
>         handler _ url req = return (ServerR.respond ServerR.OK ::
> Server.Response String)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151129/4ca32ae0/attachment.html>

From jo at durchholz.org  Mon Nov 30 08:54:13 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 30 Nov 2015 09:54:13 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <CANBN=msS6bcic24m3p2j1mgCZerH3OZHRWcYJOSQLbhOUy6BhA@mail.gmail.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAL2jp54-bAmxDv_2AhLJXJufDTuNe8AYkfzY7AbEuw2nQbLNrA@mail.gmail.com>
 <CAP1qinas9qnSLiTieOFfpcxsfWsPAxd0W6SeRj2GRka=KFkcvA@mail.gmail.com>
 <CANBN=mtcONJ7ASZE-bJ_KveYs7Tagg3K=WhNjGiUe1-V9-TyPA@mail.gmail.com>
 <CANBN=mtTQu2g6s-jAqfVApcVCfa8HDvSAtTNGs6PamxK-fGAuQ@mail.gmail.com>
 <CAP1qinaUOkCyo0vpW5VeLt2mEeXC6JJVDg+C+JZr1=WD_JeiPg@mail.gmail.com>
 <CANBN=muv0Q05P0_u3yYDoV66BfC_ERfhrjQ_F_7GVCbPL1uuDg@mail.gmail.com>
 <CAP1qinausjSVitz+uBhV_d89NG2h9=_kzsMLzoi9Vx0iODUdxg@mail.gmail.com>
 <CANBN=msS6bcic24m3p2j1mgCZerH3OZHRWcYJOSQLbhOUy6BhA@mail.gmail.com>
Message-ID: <565C0EB5.4060208@durchholz.org>

Am 30.11.2015 um 08:20 schrieb Sven Panne:
> Personally, I don't consider littering my code with version numbers as
> "little effort".

Indeed it isn't.
The effort could be reduced with proper tool or language support.

 > Stuff like this should be specified outside of the source
> code IMHO.

Well, sort-of.
Let's assume semantic versioning: major version number changes for 
incompatible API changes, minor for downwards-compatible API changes, 
and tertiary ("milli") version number changes for API-unaffecting changes.

So if your code calls into foo-3.4.1, you shouldn't have to worry 
whether it is actually being used with foo-3.4.2, or foo-3.5.0.
However, you need to say foo-3 somewhere, inside your sources, because 
your code may break with foo-4.x.x.

One issue I'm having with semantic versioning is that 
supposed-to-be-compatible library updates tend to be actually 
incompatible, often in subtle ways, so the library is released with a 
millversion change but that's a mistake (and lieing towards the 
application that's assuming an unchanged API).
It's a big issue with imperative languages, where implementation details 
can leak via state. In Haskell, I suspect that (non-)termination 
behaviour is a similar potential implementation leak, though there's 
less opportunity for that to actually happen since the library would 
need to have lots of complicated, potentially infinite data structures 
hidden below opaque types.

Regards,
Jo

From jo at durchholz.org  Mon Nov 30 08:59:16 2015
From: jo at durchholz.org (Joachim Durchholz)
Date: Mon, 30 Nov 2015 09:59:16 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565B8944.2020303@orlitzky.com>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
 <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>
 <565B8944.2020303@orlitzky.com>
Message-ID: <565C0FE4.9090100@durchholz.org>

Am 30.11.2015 um 00:24 schrieb Michael Orlitzky:
> GHC does dynamic linking now, but I'm OK with static linking as long as
> it's tracked. The end result is the same as if you had dynamic linking,
> only with a lot more wasted space and rebuilds/reinstalls.

Well, the idea was to use static linking to keep the libraries 
themselves outside the view of the package manager. I.e. the libraries 
aren't tracked inside the package manager, they become part of your 
upstream.

If you insist on tracking the libs inside the package manager, then you 
retain all the disadvantages of dynamic linking (inability to work with 
mutually incompatible library version requirements) and static linking 
(bigger space requirements).

I do wonder about the "a lot more wasted space" bit.
How much space are we really talking about?

Regards,
Jo

From imantc at gmail.com  Mon Nov 30 15:41:34 2015
From: imantc at gmail.com (Imants Cekusins)
Date: Mon, 30 Nov 2015 16:41:34 +0100
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565C0FE4.9090100@durchholz.org>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
 <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>
 <565B8944.2020303@orlitzky.com> <565C0FE4.9090100@durchholz.org>
Message-ID: <CAP1qinYaZxqKcVeam38+RBUgc+8EDhG2TK9j1Nr_OYZnnJBiRg@mail.gmail.com>

Well let's think of books vs tweets.

Books:
take longer to write
are written to last for at least a couple years
are expected to be read by a number of readers, over time
are planned
are structured / organized
cover a few topics in depth
are reviewed
are proof read
some books become out of date
may contain errata

There are different editions. There is usually time span between them.
Sometimes authors change title between editions.

There are different books about similar topics.

Tweets are in several ways just the opposite of books.

I like to think of software libraries as books. Good libraries are like
hardcover editions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151130/ad2991da/attachment.html>

From michael at orlitzky.com  Mon Nov 30 15:47:16 2015
From: michael at orlitzky.com (Michael Orlitzky)
Date: Mon, 30 Nov 2015 10:47:16 -0500
Subject: [Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps,
 with cabal sandboxes and `stack`
In-Reply-To: <565C0FE4.9090100@durchholz.org>
References: <b67c448f-eb1e-44d0-9e6f-546231aa81f7@googlegroups.com>
 <CAL2jp57-Z0q3xxaWtZg7ndMWMN0yaThJ2bg__Qik4Mdrx6581g@mail.gmail.com>
 <CAL2jp56FuV=6TremQAgLfg=r1Ld0PcTB_VrXUYhHXB+YGEp=5g@mail.gmail.com>
 <871tb8dao4.fsf@write-only.cryp.to>
 <CAL2jp569LZi7hJW_Uxu45_Zco48Ya73ZtzHse2p9H=FawzmTyw@mail.gmail.com>
 <565B4E0B.5090703@orlitzky.com>
 <CAAcnjCRQBw2zMq1=X4pD1mYe5_B5LnntaRcm13xjPMNq41MmQQ@mail.gmail.com>
 <CAAcnjCSSULEQVo9-KebWOrQ-RO2P190j=hDE2-nm_x2U-U74JQ@mail.gmail.com>
 <565B8944.2020303@orlitzky.com> <565C0FE4.9090100@durchholz.org>
Message-ID: <565C6F84.9020507@orlitzky.com>

On 11/30/2015 03:59 AM, Joachim Durchholz wrote:
> Am 30.11.2015 um 00:24 schrieb Michael Orlitzky:
>> GHC does dynamic linking now, but I'm OK with static linking as long as
>> it's tracked. The end result is the same as if you had dynamic linking,
>> only with a lot more wasted space and rebuilds/reinstalls.
> 
> Well, the idea was to use static linking to keep the libraries 
> themselves outside the view of the package manager. I.e. the libraries 
> aren't tracked inside the package manager, they become part of your 
> upstream.
> 

I get the idea, but it doesn't work in general. To use a cheesy example,
what if OpenSSL was statically linked into everything when heartbleed
was announced? If the static linking goes untracked, how do you fix it?
You need to rebuild everything that was linked against OpenSSL, but how
do you find those packages and rebuild them? Can you explain your answer
to a typical "Windows Update" user?

Less-serious vulnerabilities pop up every day and require the same
attention, so whatever solution you come up with needs to be fast and
automated.


> I do wonder about the "a lot more wasted space" bit.
> How much space are we really talking about?

Compiled programs aren't too bad. If you pull in a ton of libraries, you
might get 50MB overhead for a huge program. But if you go full retard
like NodeJS and bundle recursively, you can find yourself pulling in
500MB of dependencies for helloworld.js.

That's not anyone's main objection though. If we could fix dependencies
by wasting disk space everyone would be on board.


From jeffbrown.the at gmail.com  Mon Nov 30 22:25:49 2015
From: jeffbrown.the at gmail.com (Jeffrey Brown)
Date: Mon, 30 Nov 2015 14:25:49 -0800
Subject: [Haskell-cafe] Monadic function fails as Nothing in Maybe context
 but as Exception in Either context.
Message-ID: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>

I've written a monadic function which in a Maybe context produces a Nothing
when it fails (as intended), but in an Either context produces an Exception
rather than a Left.

Here's a tiny demonstration. "tinyGraph" below has one Node, 0, with the
label "dog". If I try to change the label at Node 0 to "cat", it works. If
I try to change the label at Node 1 to "cat", it fails, because Node 1 is
not in the graph.

    type MyGraph = Gr String String

    tinyGraph = mkGraph [(0, "dog")] [] :: MyGraph

    maybeSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Maybe MyGraph
      -- == Just (mkGraph [(0,"cat")] [])
    maybeFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Maybe MyGraph
      -- == Nothing

    eitherSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Either String
MyGraph
      -- ==  Right (mkGraph [(0,"cat")] [])
    eitherFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Either String
MyGraph
      -- *** Exception: Node not in Graph

Here's the code:

    import Data.Graph.Inductive -- FGL, the Functional Graph Library

    gelemM :: (Monad m) => MyGraph -> Node -> m ()
    gelemM g n = if gelem n g       -- FGL's gelem function returns
      then return ()                  -- True if the node is in the graph
      else fail "Node not in Graph"   -- False otherwise

    replaceStringAtNode :: MyGraph -> Node -> String -> MyGraph
    replaceStringAtNode g n e = let (Just (a,b,c,d),g') = match n g
      in (a,b,e,d) & g'

    replaceStringAtNodeM :: (Monad m) => MyGraph -> Node -> String -> m
MyGraph
    replaceStringAtNodeM g n s = do
      gelemM g n
      return $ replaceStringAtNode g n s
        -- if evaluated, the pattern match in replaceStringAtNode must
succeed,
        -- because gelemM catches the case where n is not in the graph

[1]
https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test/monad_fail_problems.hs


-- 
Jeffrey Benjamin Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151130/7049e0f4/attachment.html>

From oleg.grenrus at iki.fi  Mon Nov 30 22:34:40 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 1 Dec 2015 00:34:40 +0200
Subject: [Haskell-cafe] Monadic function fails as Nothing in Maybe
	context but as Exception in Either context.
In-Reply-To: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
References: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
Message-ID: <39EA7BFC-BD56-482F-8747-380B0C0BD9AC@iki.fi>

Hi, Jeffrey

in short: `fail` of `Either e` throws an exception (i.e. is not overriden, default implementation is `fail s = error s`) [1, 2]

For `Maybe`, fail is defined as `fail _ = Nothing`; which is good default. [3]

You probably want to use for example `throwError from `mtl` package [4]:

    gelemM :: (Monad m) => MyGraph -> Node -> m ()
    gelemM g n = if gelem n g       -- FGL's gelem function returns
      then return ()                        -- True if the node is in the graph
      else throwError "Node not in Graph"   -- False otherwise

[1] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-137 <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-137>
[2] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#Monad <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#Monad>
[3] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-642 <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-642>
[4] http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html#v:throwError <http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html#v:throwError>

- Oleg

> On 01 Dec 2015, at 00:25, Jeffrey Brown <jeffbrown.the at gmail.com> wrote:
> 
> I've written a monadic function which in a Maybe context produces a Nothing when it fails (as intended), but in an Either context produces an Exception rather than a Left.
> 
> Here's a tiny demonstration. "tinyGraph" below has one Node, 0, with the label "dog". If I try to change the label at Node 0 to "cat", it works. If I try to change the label at Node 1 to "cat", it fails, because Node 1 is not in the graph.
> 
>     type MyGraph = Gr String String
> 
>     tinyGraph = mkGraph [(0, "dog")] [] :: MyGraph
> 
>     maybeSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Maybe MyGraph
>       -- == Just (mkGraph [(0,"cat")] [])
>     maybeFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Maybe MyGraph
>       -- == Nothing
> 
>     eitherSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Either String MyGraph
>       -- ==  Right (mkGraph [(0,"cat")] [])
>     eitherFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Either String MyGraph
>       -- *** Exception: Node not in Graph
> 
> Here's the code:
> 
>     import Data.Graph.Inductive -- FGL, the Functional Graph Library
> 
>     gelemM :: (Monad m) => MyGraph -> Node -> m ()
>     gelemM g n = if gelem n g       -- FGL's gelem function returns
>       then return ()                  -- True if the node is in the graph
>       else fail "Node not in Graph"   -- False otherwise
> 
>     replaceStringAtNode :: MyGraph -> Node -> String -> MyGraph
>     replaceStringAtNode g n e = let (Just (a,b,c,d),g') = match n g
>       in (a,b,e,d) & g'
> 
>     replaceStringAtNodeM :: (Monad m) => MyGraph -> Node -> String -> m MyGraph
>     replaceStringAtNodeM g n s = do
>       gelemM g n
>       return $ replaceStringAtNode g n s
>         -- if evaluated, the pattern match in replaceStringAtNode must succeed,
>         -- because gelemM catches the case where n is not in the graph
> 
> [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test/monad_fail_problems.hs <https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test/monad_fail_problems.hs>
> 
> 
> --
> Jeffrey Benjamin Brown
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151201/bcb914cd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151201/bcb914cd/attachment.sig>

From mike at barrucadu.co.uk  Mon Nov 30 22:36:22 2015
From: mike at barrucadu.co.uk (Michael Walker)
Date: Mon, 30 Nov 2015 22:36:22 +0000
Subject: [Haskell-cafe] Monadic function fails as Nothing in Maybe
 context but as Exception in Either context.
In-Reply-To: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
References: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
Message-ID: <20151130223622.736f587f@barrucadu.co.uk>

On Mon, 30 Nov 2015 14:25:49 -0800
Jeffrey Brown <jeffbrown.the at gmail.com> wrote:

> I've written a monadic function which in a Maybe context produces a
> Nothing when it fails (as intended), but in an Either context
> produces an Exception rather than a Left.

The Monad instance for (Either e) uses the default definition of 'fail',
which is to throw an exception:

instance Monad (Either e) where
    return = Right
    Left  l >>= _ = Left l
    Right r >>= k = k r

In general, 'Left' can't be used because that would only type check
for (Either String), but the Monad instance is more general than that.

-- 
Michael Walker (http://www.barrucadu.co.uk)

From oleg.grenrus at iki.fi  Mon Nov 30 22:38:29 2015
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 1 Dec 2015 00:38:29 +0200
Subject: [Haskell-cafe] Monadic function fails as Nothing in Maybe
	context but as Exception in Either context.
In-Reply-To: <39EA7BFC-BD56-482F-8747-380B0C0BD9AC@iki.fi>
References: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
 <39EA7BFC-BD56-482F-8747-380B0C0BD9AC@iki.fi>
Message-ID: <E58CC1D2-9F1B-4E77-926F-6C2161D81357@iki.fi>


> On 01 Dec 2015, at 00:34, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
> 
> Hi, Jeffrey
> 
> in short: `fail` of `Either e` throws an exception (i.e. is not overriden, default implementation is `fail s = error s`) [1, 2]
> 
> For `Maybe`, fail is defined as `fail _ = Nothing`; which is good default. [3]
> 
> You probably want to use for example `throwError from `mtl` package [4]:
> 

I haven?t still tested it, but less wrong context is `MonadError String m`:

    gelemM :: (MonadError String m) => MyGraph -> Node -> m ()
    gelemM g n = if gelem n g       -- FGL's gelem function returns
      then return ()                        -- True if the node is in the graph
      else throwError "Node not in Graph"   -- False otherwise
> 
> [1] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-137 <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/Data.Either.html#line-137>
> [2] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#Monad <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#Monad>
> [3] https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-642 <https://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#line-642>
> [4] http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html#v:throwError <http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html#v:throwError>
> 
> - Oleg
> 
>> On 01 Dec 2015, at 00:25, Jeffrey Brown <jeffbrown.the at gmail.com <mailto:jeffbrown.the at gmail.com>> wrote:
>> 
>> I've written a monadic function which in a Maybe context produces a Nothing when it fails (as intended), but in an Either context produces an Exception rather than a Left.
>> 
>> Here's a tiny demonstration. "tinyGraph" below has one Node, 0, with the label "dog". If I try to change the label at Node 0 to "cat", it works. If I try to change the label at Node 1 to "cat", it fails, because Node 1 is not in the graph.
>> 
>>     type MyGraph = Gr String String
>> 
>>     tinyGraph = mkGraph [(0, "dog")] [] :: MyGraph
>> 
>>     maybeSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Maybe MyGraph
>>       -- == Just (mkGraph [(0,"cat")] [])
>>     maybeFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Maybe MyGraph
>>       -- == Nothing
>> 
>>     eitherSucceed = replaceStringAtNodeM tinyGraph 0 "cat" :: Either String MyGraph
>>       -- ==  Right (mkGraph [(0,"cat")] [])
>>     eitherFail = replaceStringAtNodeM tinyGraph 1 "cat" :: Either String MyGraph
>>       -- *** Exception: Node not in Graph
>> 
>> Here's the code:
>> 
>>     import Data.Graph.Inductive -- FGL, the Functional Graph Library
>> 
>>     gelemM :: (Monad m) => MyGraph -> Node -> m ()
>>     gelemM g n = if gelem n g       -- FGL's gelem function returns
>>       then return ()                  -- True if the node is in the graph
>>       else fail "Node not in Graph"   -- False otherwise
>> 
>>     replaceStringAtNode :: MyGraph -> Node -> String -> MyGraph
>>     replaceStringAtNode g n e = let (Just (a,b,c,d),g') = match n g
>>       in (a,b,e,d) & g'
>> 
>>     replaceStringAtNodeM :: (Monad m) => MyGraph -> Node -> String -> m MyGraph
>>     replaceStringAtNodeM g n s = do
>>       gelemM g n
>>       return $ replaceStringAtNode g n s
>>         -- if evaluated, the pattern match in replaceStringAtNode must succeed,
>>         -- because gelemM catches the case where n is not in the graph
>> 
>> [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test/monad_fail_problems.hs <https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/test/monad_fail_problems.hs>
>> 
>> 
>> --
>> Jeffrey Benjamin Brown
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151201/cf3cf228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151201/cf3cf228/attachment.sig>

From b at chreekat.net  Mon Nov 30 22:40:51 2015
From: b at chreekat.net (Bryan Richter)
Date: Mon, 30 Nov 2015 14:40:51 -0800
Subject: [Haskell-cafe] Monadic function fails as Nothing in Maybe
 context but as Exception in Either context.
In-Reply-To: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
References: <CAEc4Ma3-Do+tr+LEXv0mmBT=52dgWOxjRFNjVoyjP69Gdy5y7A@mail.gmail.com>
Message-ID: <20151130224051.GC25530@fuzzbomb>

On Mon, Nov 30, 2015 at 02:25:49PM -0800, Jeffrey Brown wrote:
> I've written a monadic function which in a Maybe context produces a Nothing
> when it fails (as intended), but in an Either context produces an Exception
> rather than a Left.

The Maybe instance for Monad overrides fail to be Nothing, but Either
instance does not. The default definition for fail is error.

The Except type has the behavior you are looking for, I believe ? but
you may be better off avoiding the use of fail to begin with. :)

Except/ExceptT:
http://haddock.stackage.org/lts-3.16/transformers-0.4.2.0/Control-Monad-Trans-Except.html

Also recommended for all your error-ful needs:
http://haddock.stackage.org/lts-3.16/errors-2.0.1/Control-Error.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151130/865a0d3f/attachment.sig>