From berdario at gmail.com  Fri Aug  1 00:05:26 2014
From: berdario at gmail.com (Dario Bertini)
Date: Thu, 31 Jul 2014 17:05:26 -0700
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DAB0E9.70207@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
Message-ID: <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>

On Thu, Jul 31, 2014 at 2:11 PM, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
> But, AFAIK, the (necessary and sufficient) protection against timing attacks
> is the addition of randomized waits. In the protocol layer, not in pure
> encryption/decryption/hashing routines.

I agree that we don't have a lot of evidence for/against timing
attacks in functional languages (that I know of).

But adding a randomized delay never seemed the correct solution to me
(granted, I had the luck to never had to write code sensitive to such
issues, and I never wrote a timing attack exploit either), I don't
think that doing it in the protocol layer makes it neither necessary
nor sufficient.

http://rdist.root.org/2010/01/07/timing-independent-array-comparison/

This explains the pitfalls in some possible timing attack misconceptions

-- 
xmpp: berdario at gmail.com
bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
for signing commits)

From michael at snoyman.com  Fri Aug  1 05:00:33 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 1 Aug 2014 08:00:33 +0300
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
Message-ID: <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>

tl;dr: Thanks to Felipe's comments, I think I've found the issue, which is
in the primitive package, together with a possible GHC bug. Following is my
blow-by-blow walk through on this issue.

OK, a little more information, and a simpler repro. This is reproducible
entirely with the primitive package:

    import Control.Monad.Primitive
    import Data.Primitive.Array

    main :: IO ()
    main = do
        arr <- newArray 1 'A'
        let unit = unsafeInlineIO $ writeArray arr 0 'B'
        readArray arr 0 >>= print
        return $! unit
        readArray arr 0 >>= print

However, it's not reproducible with the underlying primops:

    {-# LANGUAGE MagicHash, UnboxedTuples #-}
    import GHC.IO (IO (..))
    import GHC.Prim

    writeB :: MutableArray# RealWorld Char -> ()
    writeB arr# =
        case writeArray# arr# 0# 'B' realWorld# of
            _ -> ()

    read0 :: MutableArray# RealWorld Char -> IO Char
    read0 arr# = IO $ \s0# -> readArray# arr# 0# s0#

    test :: IO ((), IO Char)
    test = IO $ \s0# ->
      case newArray# 1# 'A' s0# of
        (# s1#, arr# #) ->
            (# s1#, (writeB arr#, read0 arr#) #)

    main :: IO ()
    main = do
        (unit, getter) <- test
        getter >>= print
        return $! unit
        getter >>= print

This behavior only occurs with optimizations turned on (unsurprising, given
Felipe's find about the simplifier pass). Now, if I define a new operation:

    unsafeWriteArray :: MutableArray RealWorld a -> Int -> a -> ()
    unsafeWriteArray (MutableArray arr#) (I# i#) x =
        case writeArray# arr# i# x realWorld# of
            _ -> ()

and then replace my unit above with:

    let unit = unsafeWriteArray arr 0 'B'

it works as expected. Similarly, the following tweak fixes the example as
well:

    arr@(MutableArray arr#) <- newArray 1 'A'
    let unit =
            case writeArray# arr# 0# 'B' realWorld# of
                _ -> ()

So it appears the bug is in writeArray, or more likely in primitive_. Sure
enough, setting NOINLINE on primitive_ *does* resolve the issue. And
looking at the definition of primitive_:

    primitive_ f = primitive (\s# -> (# f s#, () #))

this is starting to make sense. unsafeInlineIO is completely ignoring the
resulting state value, as can be seen by its implementation:

    unsafeInlineIO m = case internal m realWorld# of (# _, r #) -> r

Therefore `f s#` is never getting evaluated. However, if we force
evaluation by switching to:

    primitive_ f = primitive (\s# ->
        case f s# of
            s'# -> (# s'#, () #))

seems to solve the problem. I think this is the right approach for now, and
I've sent a pull request to primitive with this tweak[1].

One last question on the GHC front, however. It *does* seem like there's
still a bug in GHC here, since presumably case-ing on an unboxed tuple
should force evaluation of both of its values. Indeed, after going through
the above debugging, I can reproduce the issue using just primops:

    {-# LANGUAGE MagicHash, UnboxedTuples #-}
    import GHC.IO (IO (..))
    import GHC.Prim

    writeB :: MutableArray# RealWorld Char -> IO ()
    writeB arr# =
        IO $ \s0# ->
            (# writeArray# arr# 0# 'B' s0#, () #)

    inlineWriteB :: MutableArray# RealWorld Char -> ()
    inlineWriteB arr# =
        case f realWorld# of
            (# _, x #) -> x
      where
        IO f = writeB arr#

    test :: IO Char
    test = IO $ \s0# ->
      case newArray# 1# 'A' s0# of
        (# s1#, arr# #) ->
          case seq# (inlineWriteB arr#) s1# of
            (# s2#, () #) ->
              readArray# arr# 0# s2#

    main :: IO ()
    main = test >>= print

I've filed this as a bug with GHC[2].

Michael

[1] https://github.com/haskell/primitive/pull/11
[2] https://ghc.haskell.org/trac/ghc/ticket/9390
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/35879460/attachment.html>

From carter.schonwald at gmail.com  Fri Aug  1 05:51:26 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 1 Aug 2014 01:51:26 -0400
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
Message-ID: <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>

a) are you certain you're using inlinePerformIO correctly?
it was recently renamed to accursedUnutterablePerformIO
for good reason!
https://github.com/haskell/bytestring/blob/2530b1c28f15d0f320a84701bf507d5650de6098/Data/ByteString/Internal.hs#L624-L634
links to a few choice tickets from attempts to use it
https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7

https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da

https://ghc.haskell.org/trac/ghc/ticket/3486

https://ghc.haskell.org/trac/ghc/ticket/3487

https://ghc.haskell.org/trac/ghc/ticket/7270


I tried compiling your original codes with normal unsafePerformIO on ghc
7.8.3, and I get the "B" result at -O0 and the "A" result at O1 and O2

{-# LANGUAGE BangPatterns,  UnboxedTuples,MagicHash #-}

import Data.ByteString.Internal (inlinePerformIO)
import qualified Data.Vector as V
import qualified Data.Vector.Mutable as VM

import System.IO.Unsafe

main :: IO ()
main = do
    vm <- VM.new 1
    VM.write vm 0 'A'
    !b<- return $! 'B'
    let !x = unsafePerformIO $! VM.write vm 0 b
    x `seq` (V.freeze vm >>= print)

i don't think the issue has to do with inlinePerformIO (though it doesn't
help matters), because changing the optimization level impacts normal
unsafePerformIO too!


On Fri, Aug 1, 2014 at 1:00 AM, Michael Snoyman <michael at snoyman.com> wrote:

> tl;dr: Thanks to Felipe's comments, I think I've found the issue, which is
> in the primitive package, together with a possible GHC bug. Following is my
> blow-by-blow walk through on this issue.
>
> OK, a little more information, and a simpler repro. This is reproducible
> entirely with the primitive package:
>
>     import Control.Monad.Primitive
>     import Data.Primitive.Array
>
>
>     main :: IO ()
>     main = do
>         arr <- newArray 1 'A'
>         let unit = unsafeInlineIO $ writeArray arr 0 'B'
>         readArray arr 0 >>= print
>         return $! unit
>         readArray arr 0 >>= print
>
> However, it's not reproducible with the underlying primops:
>
>     {-# LANGUAGE MagicHash, UnboxedTuples #-}
>     import GHC.IO (IO (..))
>     import GHC.Prim
>
>     writeB :: MutableArray# RealWorld Char -> ()
>     writeB arr# =
>         case writeArray# arr# 0# 'B' realWorld# of
>             _ -> ()
>
>     read0 :: MutableArray# RealWorld Char -> IO Char
>     read0 arr# = IO $ \s0# -> readArray# arr# 0# s0#
>
>     test :: IO ((), IO Char)
>     test = IO $ \s0# ->
>       case newArray# 1# 'A' s0# of
>         (# s1#, arr# #) ->
>             (# s1#, (writeB arr#, read0 arr#) #)
>
>
>     main :: IO ()
>     main = do
>         (unit, getter) <- test
>         getter >>= print
>         return $! unit
>         getter >>= print
>
> This behavior only occurs with optimizations turned on (unsurprising,
> given Felipe's find about the simplifier pass). Now, if I define a new
> operation:
>
>     unsafeWriteArray :: MutableArray RealWorld a -> Int -> a -> ()
>     unsafeWriteArray (MutableArray arr#) (I# i#) x =
>         case writeArray# arr# i# x realWorld# of
>             _ -> ()
>
> and then replace my unit above with:
>
>     let unit = unsafeWriteArray arr 0 'B'
>
> it works as expected. Similarly, the following tweak fixes the example as
> well:
>
>     arr@(MutableArray arr#) <- newArray 1 'A'
>     let unit =
>             case writeArray# arr# 0# 'B' realWorld# of
>                 _ -> ()
>
> So it appears the bug is in writeArray, or more likely in primitive_. Sure
> enough, setting NOINLINE on primitive_ *does* resolve the issue. And
> looking at the definition of primitive_:
>
>     primitive_ f = primitive (\s# -> (# f s#, () #))
>
> this is starting to make sense. unsafeInlineIO is completely ignoring the
> resulting state value, as can be seen by its implementation:
>
>     unsafeInlineIO m = case internal m realWorld# of (# _, r #) -> r
>
> Therefore `f s#` is never getting evaluated. However, if we force
> evaluation by switching to:
>
>     primitive_ f = primitive (\s# ->
>         case f s# of
>             s'# -> (# s'#, () #))
>
> seems to solve the problem. I think this is the right approach for now,
> and I've sent a pull request to primitive with this tweak[1].
>
> One last question on the GHC front, however. It *does* seem like there's
> still a bug in GHC here, since presumably case-ing on an unboxed tuple
> should force evaluation of both of its values. Indeed, after going through
> the above debugging, I can reproduce the issue using just primops:
>
>     {-# LANGUAGE MagicHash, UnboxedTuples #-}
>     import GHC.IO (IO (..))
>     import GHC.Prim
>
>     writeB :: MutableArray# RealWorld Char -> IO ()
>     writeB arr# =
>         IO $ \s0# ->
>             (# writeArray# arr# 0# 'B' s0#, () #)
>
>     inlineWriteB :: MutableArray# RealWorld Char -> ()
>     inlineWriteB arr# =
>         case f realWorld# of
>             (# _, x #) -> x
>       where
>         IO f = writeB arr#
>
>     test :: IO Char
>     test = IO $ \s0# ->
>       case newArray# 1# 'A' s0# of
>         (# s1#, arr# #) ->
>           case seq# (inlineWriteB arr#) s1# of
>             (# s2#, () #) ->
>               readArray# arr# 0# s2#
>
>     main :: IO ()
>     main = test >>= print
>
> I've filed this as a bug with GHC[2].
>
> Michael
>
> [1] https://github.com/haskell/primitive/pull/11
> [2] https://ghc.haskell.org/trac/ghc/ticket/9390
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/d6a64a0e/attachment.html>

From michael at snoyman.com  Fri Aug  1 05:58:15 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Fri, 1 Aug 2014 08:58:15 +0300
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
 <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
Message-ID: <CAKA2JgJKybXzFAd5NoEoVKxRnPp_gTwoL24VoUxhQuJhYSDCbw@mail.gmail.com>

On Fri, Aug 1, 2014 at 8:51 AM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

>
> a) are you certain you're using inlinePerformIO correctly?
> it was recently renamed to accursedUnutterablePerformIO
> for good reason!
>

No, I'm not certain yet, my next task was to look into this further and be
certain that what I was doing was actually safe. I took this detour first,
and was planning on following up on the safety (or lack thereof) of
the-function-which-shall-not-be-named. The links you've provided will
certainly be very helpful, thank you.


>
> https://github.com/haskell/bytestring/blob/2530b1c28f15d0f320a84701bf507d5650de6098/Data/ByteString/Internal.hs#L624-L634
> links to a few choice tickets from attempts to use it
>
> https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7
>
>
> https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da
>
> https://ghc.haskell.org/trac/ghc/ticket/3486
>
> https://ghc.haskell.org/trac/ghc/ticket/3487
>
> https://ghc.haskell.org/trac/ghc/ticket/7270
>
>
> I tried compiling your original codes with normal unsafePerformIO on ghc
> 7.8.3, and I get the "B" result at -O0 and the "A" result at O1 and O2
>
> {-# LANGUAGE BangPatterns,  UnboxedTuples,MagicHash #-}
>
> import Data.ByteString.Internal (inlinePerformIO)
> import qualified Data.Vector as V
> import qualified Data.Vector.Mutable as VM
>
> import System.IO.Unsafe
>
> main :: IO ()
> main = do
>     vm <- VM.new 1
>     VM.write vm 0 'A'
>     !b<- return $! 'B'
>     let !x = unsafePerformIO $! VM.write vm 0 b
>     x `seq` (V.freeze vm >>= print)
>
> i don't think the issue has to do with inlinePerformIO (though it doesn't
> help matters), because changing the optimization level impacts normal
> unsafePerformIO too!
>
>
Thank you for pointing out that the problem exists even with the "benign"
unsafePerformIO. I'm not sure if that makes me relieved or more worried.

Michael


>
> On Fri, Aug 1, 2014 at 1:00 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
>
>> tl;dr: Thanks to Felipe's comments, I think I've found the issue, which
>> is in the primitive package, together with a possible GHC bug. Following is
>> my blow-by-blow walk through on this issue.
>>
>> OK, a little more information, and a simpler repro. This is reproducible
>> entirely with the primitive package:
>>
>>     import Control.Monad.Primitive
>>     import Data.Primitive.Array
>>
>>
>>     main :: IO ()
>>     main = do
>>         arr <- newArray 1 'A'
>>         let unit = unsafeInlineIO $ writeArray arr 0 'B'
>>         readArray arr 0 >>= print
>>         return $! unit
>>         readArray arr 0 >>= print
>>
>> However, it's not reproducible with the underlying primops:
>>
>>     {-# LANGUAGE MagicHash, UnboxedTuples #-}
>>     import GHC.IO (IO (..))
>>     import GHC.Prim
>>
>>     writeB :: MutableArray# RealWorld Char -> ()
>>     writeB arr# =
>>         case writeArray# arr# 0# 'B' realWorld# of
>>             _ -> ()
>>
>>     read0 :: MutableArray# RealWorld Char -> IO Char
>>     read0 arr# = IO $ \s0# -> readArray# arr# 0# s0#
>>
>>     test :: IO ((), IO Char)
>>     test = IO $ \s0# ->
>>       case newArray# 1# 'A' s0# of
>>         (# s1#, arr# #) ->
>>             (# s1#, (writeB arr#, read0 arr#) #)
>>
>>
>>     main :: IO ()
>>     main = do
>>         (unit, getter) <- test
>>         getter >>= print
>>         return $! unit
>>         getter >>= print
>>
>> This behavior only occurs with optimizations turned on (unsurprising,
>> given Felipe's find about the simplifier pass). Now, if I define a new
>> operation:
>>
>>     unsafeWriteArray :: MutableArray RealWorld a -> Int -> a -> ()
>>     unsafeWriteArray (MutableArray arr#) (I# i#) x =
>>         case writeArray# arr# i# x realWorld# of
>>             _ -> ()
>>
>> and then replace my unit above with:
>>
>>     let unit = unsafeWriteArray arr 0 'B'
>>
>> it works as expected. Similarly, the following tweak fixes the example as
>> well:
>>
>>     arr@(MutableArray arr#) <- newArray 1 'A'
>>     let unit =
>>             case writeArray# arr# 0# 'B' realWorld# of
>>                 _ -> ()
>>
>> So it appears the bug is in writeArray, or more likely in primitive_.
>> Sure enough, setting NOINLINE on primitive_ *does* resolve the issue. And
>> looking at the definition of primitive_:
>>
>>     primitive_ f = primitive (\s# -> (# f s#, () #))
>>
>> this is starting to make sense. unsafeInlineIO is completely ignoring the
>> resulting state value, as can be seen by its implementation:
>>
>>     unsafeInlineIO m = case internal m realWorld# of (# _, r #) -> r
>>
>> Therefore `f s#` is never getting evaluated. However, if we force
>> evaluation by switching to:
>>
>>     primitive_ f = primitive (\s# ->
>>         case f s# of
>>             s'# -> (# s'#, () #))
>>
>> seems to solve the problem. I think this is the right approach for now,
>> and I've sent a pull request to primitive with this tweak[1].
>>
>> One last question on the GHC front, however. It *does* seem like there's
>> still a bug in GHC here, since presumably case-ing on an unboxed tuple
>> should force evaluation of both of its values. Indeed, after going through
>> the above debugging, I can reproduce the issue using just primops:
>>
>>     {-# LANGUAGE MagicHash, UnboxedTuples #-}
>>     import GHC.IO (IO (..))
>>     import GHC.Prim
>>
>>     writeB :: MutableArray# RealWorld Char -> IO ()
>>     writeB arr# =
>>         IO $ \s0# ->
>>             (# writeArray# arr# 0# 'B' s0#, () #)
>>
>>     inlineWriteB :: MutableArray# RealWorld Char -> ()
>>     inlineWriteB arr# =
>>         case f realWorld# of
>>             (# _, x #) -> x
>>       where
>>         IO f = writeB arr#
>>
>>     test :: IO Char
>>     test = IO $ \s0# ->
>>       case newArray# 1# 'A' s0# of
>>         (# s1#, arr# #) ->
>>           case seq# (inlineWriteB arr#) s1# of
>>             (# s2#, () #) ->
>>               readArray# arr# 0# s2#
>>
>>     main :: IO ()
>>     main = test >>= print
>>
>> I've filed this as a bug with GHC[2].
>>
>> Michael
>>
>> [1] https://github.com/haskell/primitive/pull/11
>> [2] https://ghc.haskell.org/trac/ghc/ticket/9390
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/b7cb0ab1/attachment-0001.html>

From vigalchin at gmail.com  Fri Aug  1 06:58:55 2014
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Fri, 1 Aug 2014 01:58:55 -0500
Subject: [Haskell-cafe] Tor project and Haskell (FPL) ,..
Message-ID: <CA+0XtC-PBiHqXms09JgSEL1rSjWKh7QjFKhswmBpBoX2WEx-MA@mail.gmail.com>

I wasn't trying to offend anybody .... Only trying to provoke a lively
discussion in order lift all boats.  Sometimes one sentence IHMO provokes
thought. In any case I appreciate all responders :-) Kind thanks friends.

Vasya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/35600b63/attachment.html>

From friedrichwiemer at gmail.com  Fri Aug  1 06:59:20 2014
From: friedrichwiemer at gmail.com (Friedrich Wiemer)
Date: Fri, 01 Aug 2014 08:59:20 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
Message-ID: <53DB3AC8.5010500@gmail.com>

A comparision would be interesting though. I'm aware of constant time
implementations of cryptographic functions to reduce timing issues, but
these are often coded in C or ASM - I have no clue if this would be
possible in a functional language, as the compiler has to know not to
optimize for short cuts or anything in the code?

On 08/01/2014 02:05 AM, Dario Bertini wrote:
> On Thu, Jul 31, 2014 at 2:11 PM, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
>> But, AFAIK, the (necessary and sufficient) protection against timing attacks
>> is the addition of randomized waits. In the protocol layer, not in pure
>> encryption/decryption/hashing routines.
> 
> I agree that we don't have a lot of evidence for/against timing
> attacks in functional languages (that I know of).
> 
> But adding a randomized delay never seemed the correct solution to me
> (granted, I had the luck to never had to write code sensitive to such
> issues, and I never wrote a timing attack exploit either), I don't
> think that doing it in the protocol layer makes it neither necessary
> nor sufficient.
> 
> http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
> 
> This explains the pitfalls in some possible timing attack misconceptions
> 

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

From tdammers at gmail.com  Fri Aug  1 07:10:32 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 09:10:32 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
Message-ID: <20140801071031.GA23813@yemaya>

Timing attacks generally work such that the attacker samples a large
number of runs and maps their execution times; "humps" in the graph show
different code paths being taken.

Because they're statistical attacks, adding uniform noise (random
delays) does not work - it's uniform noise after all, you'll just raise
the floor, but the humps will still be there; the random delays will
just average out. Ten million times (10 + rand()) is still going to be
smaller than ten million times (1000 + rand()).

Instead, a way I've seen recommended is run the entire input through a
cryptographic hash function, and derive a delay from that, in a range
that dwarfs the actual timing difference. This way, things will still
average out, but the averaging will not compensate for the delay we
added, because that delay is always the same for a given input.

Of course designing functions to minimize execution time differences is
still a good idea; it's just not very reliable on its own, and for many
real-world cases, it's not even practical (or outright impossible) -
even if your code doesn't branch based on whether a username was found
in the database or not, your database does.

On Thu, Jul 31, 2014 at 05:05:26PM -0700, Dario Bertini wrote:
> On Thu, Jul 31, 2014 at 2:11 PM, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
> > But, AFAIK, the (necessary and sufficient) protection against timing attacks
> > is the addition of randomized waits. In the protocol layer, not in pure
> > encryption/decryption/hashing routines.
> 
> I agree that we don't have a lot of evidence for/against timing
> attacks in functional languages (that I know of).
> 
> But adding a randomized delay never seemed the correct solution to me
> (granted, I had the luck to never had to write code sensitive to such
> issues, and I never wrote a timing attack exploit either), I don't
> think that doing it in the protocol layer makes it neither necessary
> nor sufficient.
> 
> http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
> 
> This explains the pitfalls in some possible timing attack misconceptions
> 
> -- 
> xmpp: berdario at gmail.com
> bitmessage: BM-2cTYXfGiSTsnx3righ6aHcJSWe4MV17jDP
> gpg fingerprint: 3F8D53518012716C4EEF7DF67B498306B3BF75A0 (used just
> for signing commits)
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From wojtek at power.com.pl  Fri Aug  1 07:20:11 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 09:20:11 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB3AC8.5010500@gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
Message-ID: <53DB3FAB.50802@power.com.pl>

On 01.08.2014 08:59, Friedrich Wiemer wrote:
> A comparision would be interesting though. I'm aware of constant time
> implementations of cryptographic functions to reduce timing issues, but
> these are often coded in C or ASM - I have no clue if this would be
> possible in a functional language, as the compiler has to know not to
> optimize for short cuts or anything in the code?
>
>

Well, how about something like

inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult) -> 
IO (Maybe CryptoResult)



From ltclifton at gmail.com  Fri Aug  1 07:27:11 2014
From: ltclifton at gmail.com (Luke Clifton)
Date: Fri, 1 Aug 2014 15:27:11 +0800
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB3FAB.50802@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com> <53DB3FAB.50802@power.com.pl>
Message-ID: <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>

> Well, how about something like
>
> inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult) -> IO
> (Maybe CryptoResult)


I'm no expert, but aren't timing attacks also possible with something like
that. If your `functionToPerform' touches the cache in funny ways, the
program after resuming from the timeout might have different timings as
there could be cache misses in one scenario, but not the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/e8559871/attachment.html>

From wojtek at power.com.pl  Fri Aug  1 07:35:37 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 09:35:37 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <20140801071031.GA23813@yemaya>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya>
Message-ID: <53DB4349.6060908@power.com.pl>


On 01.08.2014 09:10, Tobias Dammers wrote:
> Timing attacks generally work such that the attacker samples a large
> number of runs and maps their execution times; "humps" in the graph show
> different code paths being taken.
>
> Because they're statistical attacks, adding uniform noise (random
> delays) does not work - it's uniform noise after all, you'll just raise
> the floor, but the humps will still be there; the random delays will
> just average out. Ten million times (10 + rand()) is still going to be
> smaller than ten million times (1000 + rand()).
Okay, so basically we'd would have to add dependent random noise. For 
example send out a Normal distribution. Or a smiley (Beta, Weibull).
> Instead, a way I've seen recommended is run the entire input through a
> cryptographic hash function, and derive a delay from that, in a range
> that dwarfs the actual timing difference. This way, things will still
> average out, but the averaging will not compensate for the delay we
> added, because that delay is always the same for a given input.
>
> Of course designing functions to minimize execution time differences is
> still a good idea; it's just not very reliable on its own, and for many
> real-world cases, it's not even practical (or outright impossible) -
> even if your code doesn't branch based on whether a username was found
> in the database or not, your database does.
>
Why the gimmick, for each and every piece of crypto code? Why not just 
use the clock for timing? The crypto lib would probably have to tune 
itself on startup.

-- 
Wojtek N.

From wojtek at power.com.pl  Fri Aug  1 07:38:26 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 09:38:26 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>	<lrci4n$ito$1@ger.gmane.org>	<0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>	<CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>	<BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>	<53DAB0E9.70207@power.com.pl>	<CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>	<53DB3AC8.5010500@gmail.com>	<53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
Message-ID: <53DB43F2.2010603@power.com.pl>


On 01.08.2014 09:27, Luke Clifton wrote:
>
>     Well, how about something like
>
>     inConstantTime :: timeBudget -> (functionToPerform ::
>     CryptoResult) -> IO (Maybe CryptoResult) 
>
>
> I'm no expert, but aren't timing attacks also possible with something 
> like that. If your `functionToPerform' touches the cache in funny 
> ways, the program after resuming from the timeout might have different 
> timings as there could be cache misses in one scenario, but not the 
> other.
Oh come on, there is still a number of slow buffers in between: kernel, 
network cards, switches, routers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/3726d5e5/attachment.html>

From ltclifton at gmail.com  Fri Aug  1 07:49:21 2014
From: ltclifton at gmail.com (Luke Clifton)
Date: Fri, 1 Aug 2014 15:49:21 +0800
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB43F2.2010603@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com> <53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
 <53DB43F2.2010603@power.com.pl>
Message-ID: <CAEvi2wEES1wD-CgMmoVBXAD7Hn_+=SnUOtTQ6hxCmakQC0-bJg@mail.gmail.com>

But the delay caused by those buffers does not depend on the internal
workings of your crypto algorithm.

The delay caused by potential cache misses could very well leak
information. If your algorithm terminates early on a string comparison, and
therefore doesn't end up evicting more pages out of the cache performing
whatever operations would have come after had the strings matched, there
could be real world measurable differences, even if you waited for the
clock to hit some threshold before continuing on with execution.

Regardless of how much delay there is in other sources, if it is not
directly correlated, it can be averaged out.


On Fri, Aug 1, 2014 at 3:38 PM, Wojtek Narczy?ski <wojtek at power.com.pl>
wrote:

>
> On 01.08.2014 09:27, Luke Clifton wrote:
>
>
>
>>   Well, how about something like
>>
>> inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult) -> IO
>> (Maybe CryptoResult)
>
>
>  I'm no expert, but aren't timing attacks also possible with something
> like that. If your `functionToPerform' touches the cache in funny ways, the
> program after resuming from the timeout might have different timings as
> there could be cache misses in one scenario, but not the other.
>
> Oh come on, there is still a number of slow buffers in between: kernel,
> network cards, switches, routers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/d1edeb6c/attachment.html>

From karel.gardas at centrum.cz  Fri Aug  1 07:49:41 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Fri, 01 Aug 2014 09:49:41 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB43F2.2010603@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>	<lrci4n$ito$1@ger.gmane.org>	<0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>	<CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>	<BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>	<53DAB0E9.70207@power.com.pl>	<CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>	<53DB3AC8.5010500@gmail.com>	<53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
 <53DB43F2.2010603@power.com.pl>
Message-ID: <53DB4695.50206@centrum.cz>

On 08/ 1/14 09:38 AM, Wojtek Narczy?ski wrote:
>
> On 01.08.2014 09:27, Luke Clifton wrote:
>>
>>     Well, how about something like
>>
>>     inConstantTime :: timeBudget -> (functionToPerform ::
>>     CryptoResult) -> IO (Maybe CryptoResult)
>>
>>
>> I'm no expert, but aren't timing attacks also possible with something
>> like that. If your `functionToPerform' touches the cache in funny
>> ways, the program after resuming from the timeout might have different
>> timings as there could be cache misses in one scenario, but not the
>> other.
> Oh come on, there is still a number of slow buffers in between: kernel,
> network cards, switches, routers.

I think original poster has been talking about something like that:

https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
https://eprint.iacr.org/2014/248.pdf

not funny reading indeed. So yes, I would also like to see paper about 
attacks above being done against purely functional TLS implementation. 
Results may be interesting, especially when we consider functional 
programming to provide more secure code by default (in comparison with C)...

Karel

From friedrichwiemer at gmail.com  Fri Aug  1 08:02:23 2014
From: friedrichwiemer at gmail.com (Friedrich Wiemer)
Date: Fri, 01 Aug 2014 10:02:23 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com> <53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
Message-ID: <53DB498F.3060207@gmail.com>

>     Well, how about something like
> 
>     inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult)
>     -> IO (Maybe CryptoResult) 
> 
> 
> I'm no expert, but aren't timing attacks also possible with something
> like that. If your `functionToPerform' touches the cache in funny ways,
> the program after resuming from the timeout might have different timings
> as there could be cache misses in one scenario, but not the other.

One would need to add countermeasures for this sidechannel, too, I guess.

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

From auke at tulcod.com  Fri Aug  1 08:03:01 2014
From: auke at tulcod.com (Auke Booij)
Date: Fri, 1 Aug 2014 10:03:01 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB3AC8.5010500@gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
Message-ID: <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>

On 1 August 2014 08:59, Friedrich Wiemer <friedrichwiemer at gmail.com> wrote:
> A comparision would be interesting though. I'm aware of constant time
> implementations of cryptographic functions to reduce timing issues, but
> these are often coded in C or ASM - I have no clue if this would be
> possible in a functional language, as the compiler has to know not to
> optimize for short cuts or anything in the code?

I thought about the possibilities to make a "fixed time"
implementation of some standard functions a while ago.

What I *think* should give a solution is the following.

Why do C implementations against, say, timing attack works?

Well, a very typical scenario is password checking: you have two input
[Char]s, and need to see if they match, which you do by zipping them
and seeing if all pairs are of equal elements. Now of course, once you
found a first element which doesn't match, you /can/ stop computation
because you know the result, but you don't /want/ to, because... well,
because you don't want to expose the fact that you're done. In other
words, you want to look like you're still processing!

So instead, let's make an implementation where even if halfway through
checking equality of two passwords we discover that they're unequal,
there is still some more information we need to compute! Let's
/actually/ make it so that we still need to do more computations.

So what if we made, for every standard library haskell function,
something that somehow accumulates small bits of data that take the
full input data to process, but in the end we are not interested in?
For example, we could make an implementation of
all::(a->Bool)->[a]->Bool (with a different signature) which doesn't
just compute the output we need, but also computes a "cumulative hash
function" (for lack of better words) of all the elements.

So let us give a name to the "trash data" we attach to any "input
data", whose hash function (or whatever constant time function) gets
accumulated throughout the algorithm that processes the input....
"slack data"?

Now, exactly what slack data you attach to input data depends on the
thing that you want to be constant in: if you want your computation to
always take as long as the length of the input data, attach that much
slack data. But, for example, if passwords can be up to 128 chars
long, and you don't want to expose /any/ information about the given
password, you should attach 128 items of slack data to your input,
possibly making it larger.


Let me know if the above didn't make sense. I don't know how to
implement this, but I think it might give a way to fix *many*
side-channel leaks using functional techniques.

PS: obviously this is not how you want to be checking passwords, but
this is quite a typical side channel leak scenario.

From wojtek at power.com.pl  Fri Aug  1 08:08:08 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 10:08:08 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB498F.3060207@gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com> <53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
 <53DB498F.3060207@gmail.com>
Message-ID: <53DB4AE8.2010903@power.com.pl>

On 01.08.2014 10:02, Friedrich Wiemer wrote:
>>      Well, how about something like
>>
>>      inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult)
>>      -> IO (Maybe CryptoResult)
>>
>>
>> I'm no expert, but aren't timing attacks also possible with something
>> like that. If your `functionToPerform' touches the cache in funny ways,
>> the program after resuming from the timeout might have different timings
>> as there could be cache misses in one scenario, but not the other.
> One would need to add countermeasures for this sidechannel, too, I guess.
>
>
Countermeasures here, countermeasures there, and the best language to do 
it is C. I find it hard to believe.

From wojtek at power.com.pl  Fri Aug  1 08:11:48 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 10:11:48 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
 <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>
Message-ID: <53DB4BC4.5090701@power.com.pl>


On 01.08.2014 10:03, Auke Booij wrote:
> (...)
> Let me know if the above didn't make sense.
You asked for it. For me, doing useless computations just to make sure 
the timing is right, does not make sense. Using a clock makes sense.

From wojtek at power.com.pl  Fri Aug  1 08:16:18 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Fri, 01 Aug 2014 10:16:18 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4695.50206@centrum.cz>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>	<lrci4n$ito$1@ger.gmane.org>	<0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>	<CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>	<BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>	<53DAB0E9.70207@power.com.pl>	<CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>	<53DB3AC8.5010500@gmail.com>	<53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
 <53DB43F2.2010603@power.com.pl> <53DB4695.50206@centrum.cz>
Message-ID: <53DB4CD2.6050004@power.com.pl>

On 01.08.2014 09:49, Karel Gardas wrote:
>
> I think original poster has been talking about something like that:
>
> https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf
> https://eprint.iacr.org/2014/248.pdf
>
> not funny reading indeed. So yes, I would also like to see paper about 
> attacks above being done against purely functional TLS implementation. 
> Results may be interesting, especially when we consider functional 
> programming to provide more secure code by default (in comparison with 
> C)...
>

A scientific proof that sending your private keys to public cloud is not 
very smart. Adorable.

Now seriously, thanks for pointing out the papers.

From friedrichwiemer at gmail.com  Fri Aug  1 08:19:02 2014
From: friedrichwiemer at gmail.com (Friedrich Wiemer)
Date: Fri, 01 Aug 2014 10:19:02 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4BC4.5090701@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
 <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>
 <53DB4BC4.5090701@power.com.pl>
Message-ID: <53DB4D76.5000701@gmail.com>

I dont think this is a solution as well. You're actually trying to cheat
around compiler optimizations, don't you? What if the compiler notices
you don't need this trash data and optimizes the computation away?

On 08/01/2014 10:11 AM, Wojtek Narczy?ski wrote:
> 
> On 01.08.2014 10:03, Auke Booij wrote:
>> (...)
>> Let me know if the above didn't make sense.
> You asked for it. For me, doing useless computations just to make sure
> the timing is right, does not make sense. Using a clock makes sense.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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

From haskell at ibotty.net  Fri Aug  1 08:26:49 2014
From: haskell at ibotty.net (Tobias Florek)
Date: Fri, 01 Aug 2014 10:26:49 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DAB0E9.70207@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
Message-ID: <53DB4F49.2050207@ibotty.net>

 > [random delay for mitigating side channel attacks]

that is not enough. to mitigate _network attacks_ you need at least 
predictable random delay. i was toying around in adding that to vincent 
hanquez tls library but did not find the time to do that in the end. it 
would be great to see others do that of course :).

talk from sebastian schnitzler on 29c3:
 
http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_side_h264.html

slides:
  http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf

abstract:
  http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf


it should be stressed that delay does only help against network side 
channels. if you have an attacker on the same physical hardware, you 
will at least need branchless code. that is a very hard problem. i think 
it's pretty much impossible to solve that problem in haskell alone. 
maybe with a dsl that generates code it's possible though. cryptol looks 
interesting in that regard (whenever it gets back it code generators). 
offloading the computation to a fpga that only you have access to should 
solve cache-line side-channels.

  http://cryptol.net


regarding observable gc behavior it's interesting to see tedu's recent 
blogpost about attacking string compare in lua.

  http://www.tedunangst.com/flak/post/timing-attacks-vs-interned-strings

tob

From auke at tulcod.com  Fri Aug  1 08:28:54 2014
From: auke at tulcod.com (Auke Booij)
Date: Fri, 1 Aug 2014 10:28:54 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4BC4.5090701@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
 <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>
 <53DB4BC4.5090701@power.com.pl>
Message-ID: <CAP6YhLLAy=YAraTzKb2JtUnoFuycsgF5Kzr6cTU_iGX=nXbHwQ@mail.gmail.com>

On 1 August 2014 10:11, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
> You asked for it. For me, doing useless computations just to make sure the
> timing is right, does not make sense. Using a clock makes sense.

If you believe that is the case, how are you planning to tackle power
analysis attacks? (Note that such attacks are not just theoretical.)

Let's say you went to sit an exam, but were already given the answers
by a friend beforehand. How do you fake actually sitting the exam? You
don't set a clock: that only fixes one of the ways in which the
examiners might discover you don't need to work to do the exam.

Instead, you stare ate your paper intensely, make useless drawings on
your rough work paper, and pretend you're working hard.

If you want to look like you're processing, you better actually be processing.

C allows you compute absolutely nothing, because the compiler isn't
smart enough to see that. But Haskell's compiler is much better at
detecting if you're computing trash, so we need to be more convincing
that we're not.


You can call it a cheat around compiler optimizations, but really
that's missing the point, because Haskell doesn't even work without
those optimizations.

This is a way to process data in a configurable way.

Obviously you'll need to somehow tell the compiler that the eventual
result of all the slack data propagation should not be thrown out. But
this is nothing new: we already have the IO monad (although admittedly
its internal data gets optimized away, or so I heard; but the
important thing is that the effects stay).

From auke at tulcod.com  Fri Aug  1 08:31:23 2014
From: auke at tulcod.com (Auke Booij)
Date: Fri, 1 Aug 2014 10:31:23 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4F49.2050207@ibotty.net>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
Message-ID: <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>

On 1 August 2014 10:26, Tobias Florek <haskell at ibotty.net> wrote:
> it should be stressed that delay does only help against network side
> channels. if you have an attacker on the same physical hardware, you will at
> least need branchless code. that is a very hard problem. i think it's pretty
> much impossible to solve that problem in haskell alone. maybe with a dsl
> that generates code it's possible though. cryptol looks interesting in that
> regard (whenever it gets back it code generators). offloading the
> computation to a fpga that only you have access to should solve cache-line
> side-channels.

Just wanted to say that what I posted might give hope for such
"branchless" code (or in fact: code that may branch, but by
construction not in a detectable way).

From vigalchin at gmail.com  Fri Aug  1 08:53:04 2014
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Fri, 1 Aug 2014 03:53:04 -0500
Subject: [Haskell-cafe] www.galois.com vs Google??
In-Reply-To: <20140731102434.GD1558@yemaya>
References: <CA+0XtC-ukB8ifWejmNYY5mWPBNA3qBiFh8WVQpHVQDoZ4EF52Q@mail.gmail.com>
 <20140731102434.GD1558@yemaya>
Message-ID: <CA+0XtC_NzW-c5veXJVC5Zuvc9_HVoBvdJLXb9L9fB4AF_f6mrQ@mail.gmail.com>

Tobias,

     I pretty agree with your response. I was  trying to challenge the
entire audience to think about the issue about software
correctness(e.g. strong typefullness (and static type checking) like
Haskell, et. al. vs no type-checking/ dynamic type checking). My point
is how can we as a community respond to Google's challenge?? In my
humble opinion (IMHO) I think Google has missed the point regarding
contemporary software correctness problems  .. (and also the Tor
project . given the languages of implementation) ..

       Here is a very simple and cheesy example .. I worked at HP on a
contract .. . a predecessor   of mine used with typefullnes of C++ (I
thinking using type casting ) and did a buffer overrun of "heap"
allocated that corrupted "the heap allocator metadata" (malloc) ....
of course I used to "gdb" to do a "postmordum after the patient died"
... IHMO I would been more happier if this "overrun" had been detected
at compile-tyime .. due to static strong type checking ... :-)

      Alll grammer errors are due to my cat Buddy ...

Vasya

On Thu, Jul 31, 2014 at 5:24 AM, Tobias Dammers <tdammers at gmail.com> wrote:
> The way I read that article, those are two very different goals and
> approaches.
>
> The "Project Zero" thing seems to be about subjecting "everything" to
> thorough security checking by the best experts Google can buy, in order
> to fix as many security problems on the internet as they possibly can.
>
> The software correctness problem is somewhat related, but not entirely -
> not all security problems are software bugs, and not all software bugs
> are security problems.
>
> On a side note, I think both problems are inherently unsolvable - we can
> go a long way cleaning up the solvable problems, and building an
> infrastructure that avoids them by design, but some potential for bugs
> and flaws will always remain, at least as long as we're using reasonable
> definitions of "programming" and "software".
>
> On Wed, Jul 30, 2014 at 10:08:06PM -0500, Vasili I. Galchin wrote:
>> Hello Haskellers(and all FPL people),
>>
>>         I just ran across the following effort by Google:
>> http://blogs.techworld.com/war-on-error/2014/07/googles-project-zero-flaw-programme-do-gooding-spin-or-a-much-needed-evolution/index.htm
>>
>>          It seems to me that www.galois.com(www.janestreetcapital.com)
>> realizes that the solution to software correctness problems doesn't
>> lie with uncontrolled "mutability" ...
>>
>>         Question: does Google concur with www.galois.com or google's
>> effort just "more of the same"??
>>
>> Vasili
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

From karel.gardas at centrum.cz  Fri Aug  1 09:21:45 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Fri, 01 Aug 2014 11:21:45 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <784C06CC-006E-4BBD-B1BD-20D7D6256093@proclivis.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <784C06CC-006E-4BBD-B1BD-20D7D6256093@proclivis.com>
Message-ID: <53DB5C29.8040002@centrum.cz>


[Unrelated to original topic!]

If you're using Linux on i.MX6, then you can also use native compilation 
which is working better than cross-compilation.

If eCos does not provide proper POSIX, then you can also have a look at 
RTEMS. I attempted to port GHC to it year ago IIRC, but it would require 
some changes to cabal and libs too. But anyway this is really nice OS 
target...

Karel

On 08/ 1/14 01:42 AM, Michael Jones wrote:
> I am not an expert, but I think timing attacks try to push data though a system and look for time dependent calculations. If every packet that leaves a system has the same data size and the same encryption time, the attacker would not be able to detect any difference in time wrt difference in data. Time could also vary if you mucked with the voltage of the CPU, or if some calculation could.
>
> I would guess that if it is not possible to make all packages the same size and time, randomizing time would hide time differences. However, it may be possible to extract randomness. This is just a conjecture on my part.
>
> A work around might be to use hardware encryption. I work on an A9, and with openssl, there is the option to have hardware do the actual encryption, etc. I have not had the time to implement this, but I believe that Linux for IMX6 has support for hardware encryption. If nothing else, it is best to use the hardware for random number generation.
>
> My interested would be to run it on my Wandboard and Yocto linux. Hence my questions about cross-compilers. I am still stuck on that problem because I have not figure out how to make GHC pass architecture options to the gcc cross compiler but not to the local linux gcc. It seems some variables in the build are tied together. But eventually I?ll probably figure it out.
>
> I think the Hypervisor approach is also interesting. Just build a mini OS with TLS and Tor. That could reduce the attack surface by eliminating Linux. This would be interesting for a repeater. I was thinking doing the same onto of a smaller kernel such as eCos. I tried to get GHC running on that, but there is some missing POSIX support, so I went back to linux.
>
> Mike
>
> On Jul 31, 2014, at 3:11 PM, Wojtek Narczy?ski<wojtek at power.com.pl>  wrote:
>
>> On 31.07.2014 18:59, Adam Wick wrote:
>>> As for TLS, it is possible that timing attacks based on a functional language implementation could be more likely than those for a traditional C implementation. (...) I don?t believe the balance has been studied, but it?d be interesting.
>>>
>> I believe no evidence is available, not even anecdotal. And it would be rather expensive a subject to study.
>>
>> But, AFAIK, the (necessary and sufficient) protection against timing attacks is the addition of randomized waits. In the protocol layer, not in pure encryption/decryption/hashing routines. I strive not to use words I don't understand, but I have the M. word in mind for structuring such a computation.
>>
>> In other words, I think it is a myth.
>>
>> --
>> Kind regards,
>> Wojtek N.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From haskell at ibotty.net  Fri Aug  1 09:35:01 2014
From: haskell at ibotty.net (Tobias Florek)
Date: Fri, 01 Aug 2014 11:35:01 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
 <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
Message-ID: <53DB5F45.20104@ibotty.net>

hi,

 > Just wanted to say that what I posted might give hope for such
> "branchless" code (or in fact: code that may branch, but by
> construction not in a detectable way).

i don't have the papers handy, but on the same host you can observe 
cache line collisions. that means you cannot do something different that 
takes the same time and generates the same amount of heat. you will have 
to do _the same thing_. of course packages like vincent hanquez 
securemem provide that kind of equality checks (and other very useful 
properties). so some building blocks are there. interaction with the 
garbage collector is still something to worry about though. in some gcs 
you can observe whether a string is in use somewhere in the program or 
not. i am not intimate with ghc's gc but i don't expect that particular 
vulnerability is a problem when using securemem (or even bytestring or 
text), but there might (and i assume will) be many other opportunities 
to observe some state from outside the program.

don't let me discourage you though. every step to less side channels is 
a valuable step!

tob

From wojtek at power.com.pl  Fri Aug  1 09:43:00 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qY2llY2ggTmFyY3p5xYRza2k=?=)
Date: Fri, 01 Aug 2014 11:43:00 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <CAP6YhLLAy=YAraTzKb2JtUnoFuycsgF5Kzr6cTU_iGX=nXbHwQ@mail.gmail.com>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com>
 <CAP6YhLKK-mhe8v_7KeyeeDdCZ9_hHGaXLngEVDBwA-zLrfn-Fg@mail.gmail.com>
 <53DB4BC4.5090701@power.com.pl>
 <CAP6YhLLAy=YAraTzKb2JtUnoFuycsgF5Kzr6cTU_iGX=nXbHwQ@mail.gmail.com>
Message-ID: <53DB6124.2090908@power.com.pl>


W dniu 2014-08-01 10:28, Auke Booij pisze:
> On 1 August 2014 10:11, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
>> You asked for it. For me, doing useless computations just to make sure the
>> timing is right, does not make sense. Using a clock makes sense.
> If you believe that is the case, how are you planning to tackle power
> analysis attacks? (Note that such attacks are not just theoretical.)
>
Oh, okay, my mind is set on remote attacks. In the scenario where the 
attacker has access to the hardware under attack, doing fake 
computations most resembling normal computations is definitely better 
then clock. In general, access to the hardware raises the bar for 
security very high. In such a scenario assembly language might be the 
best choice, or at least analysis of the binary code.

From ky3 at atamo.com  Fri Aug  1 09:46:14 2014
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Fri, 1 Aug 2014 16:46:14 +0700
Subject: [Haskell-cafe] Does web-based email harm mailman lists?
Message-ID: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>

Beautiful haskell people,

Ever noticed the lacunae on some list threads?

Someone hits reply and instead of reflecting via mailman, it goes direct to
OP. OP notices absence of To:haskell-cafe and adds it back in in their
reply to the reply.

End result? The thread looks like OP having a convo with themselves. Unless
you look at the quoted parts, which you have to click to reveal in
web-based email.

The convention, say with a google-groups based mailing list, is that
conversations in mailing list are public by default. With some manual C&P,
you can email responses in private.

For cafe participants using web-based email, the situation is reversed,
through no fault of their own.

Approx 18 months ago, the haskell-beginners list suffered the same problem
[1]. After some digging, it looks like there's a configurable option to Do
The Right Thing:

http://ccit.mines.edu/Mailman-FAQ#25

I was also privately emailed that there are downsides I wasn't aware of:

Reply-To Munging Considered Harmful
http://www.unicom.com/pw/reply-to-harmful.html

Reply-To Munging Considered Useful
http://www.metasystema.org/essays/reply-to-useful.html

So what happened in the aftermath?

Not much that I can tell. Everything just purred along.

Now you might argue that haskell-cafe will just purr along grandly as well
given the status quo.

But this is a wrinkle that probably needs some awareness at least, hence
this email.

Would you like this fixed? The list owner would need to be obliged upon.

[1] http://www.haskell.org/pipermail/beginners/2013-January/011304.html

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/8783b801/attachment.html>

From wojtek at power.com.pl  Fri Aug  1 09:54:06 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qY2llY2ggTmFyY3p5xYRza2k=?=)
Date: Fri, 01 Aug 2014 11:54:06 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB5F45.20104@ibotty.net>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
 <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
 <53DB5F45.20104@ibotty.net>
Message-ID: <53DB63BE.6080405@power.com.pl>

Everybody,

thanks for an interesting discussion.

And, by the way, we're all on NSA watch list now.



From tdammers at gmail.com  Fri Aug  1 09:56:35 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 11:56:35 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4349.6060908@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
Message-ID: <20140801095634.GA1610@yemaya>

On Fri, Aug 01, 2014 at 09:35:37AM +0200, Wojtek Narczy?ski wrote:
> 
> Why the gimmick, for each and every piece of crypto code? Why not just use
> the clock for timing? The crypto lib would probably have to tune itself on
> startup.

Sorry, I didn't mean use the crypto function to cause the delay; I meant
using a cryptographic hash to determine how long the delay should be.
Once we have a number, the system clock should of course be used to
actually delay things.

The point of this is as follows.

The attacker sends a large number of messages, each one of them multiple
times, averaging execution times. The reasonable expectation is that the
average execution times will fall into distinct groups, each of them
representing one execution path. The averaging is needed because there
will be fluctuations anyway, if only because there are other things
happening on the network and on the target machine, but those noise
sources are typically all uniform or at least normal distributions, so
averaging will filter them out. The part that remains after filtering is
what interests the attacker. Then if you have sampled, say, 10,000
random usernames, and 10 of them are in one group and the other 9,990
are in the other, it's a pretty good guess to assume that those 10 are
usernames that actually exist on the target system and the others don't.

Now, if we add some random noise, we just add one more uniformly
distributed noise source to our signal, but we already have a bunch of
those, so we're not really winning anything here - the extra noise will
just get filtered out along with the rest.

However, if we add noise that depends on the input, the filtering won't
remove it, because for each given input it is constant. Instead of
removing the noise component from `code(input) + system_noise()`,
leaving `code(input)`, the attacker now deals with `code(input) +
hash(input) + system_noise()`, leaving them with `code(input) +
hash(input)`. Without cracking the hash, I don't know how you'd remove
the hash-based delay from the sample; possible mistakes would be
insufficient granularity in the hash-based delay (e.g. if the difference
between code paths is 1ms and our delay has a 100ms granularity, it's
still trivial to filter out the hash noise), insufficient range (if the
difference between code paths is 100ms and our delay is between 0 and
25ms, we still have two distinct groups), a weak hash function, and
probably a bunch more.

> 
> -- 
> Wojtek N.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From tdammers at gmail.com  Fri Aug  1 09:58:21 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 11:58:21 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB63BE.6080405@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
 <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
 <53DB5F45.20104@ibotty.net> <53DB63BE.6080405@power.com.pl>
Message-ID: <20140801095821.GB1610@yemaya>

Aren't we anyway?

On Fri, Aug 01, 2014 at 11:54:06AM +0200, Wojciech Narczy?ski wrote:
> Everybody,
> 
> thanks for an interesting discussion.
> 
> And, by the way, we're all on NSA watch list now.
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From tdammers at gmail.com  Fri Aug  1 10:02:40 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 12:02:40 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB4AE8.2010903@power.com.pl>
References: <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <53DB3AC8.5010500@gmail.com> <53DB3FAB.50802@power.com.pl>
 <CAEvi2wEZOztoOQjuz9+CQprzaEt4DtCVT86uWUAGKkDGd3XV3g@mail.gmail.com>
 <53DB498F.3060207@gmail.com> <53DB4AE8.2010903@power.com.pl>
Message-ID: <20140801100239.GD1610@yemaya>

On Fri, Aug 01, 2014 at 10:08:08AM +0200, Wojtek Narczy?ski wrote:
> Countermeasures here, countermeasures there, and the best language to do it
> is C. I find it hard to believe.

Well; it's a two-edged sword.

C is close to the metal, so you have a lot of control over timing,
memory allocations, even CPU registers; this is beneficial when dealing
with things like timing attacks, and it is a disaster when trying to
write provably correct code. I believe that having both in the same
language would be the holy grail of secure programming.

From haskell at ibotty.net  Fri Aug  1 10:04:48 2014
From: haskell at ibotty.net (Tobias Florek)
Date: Fri, 01 Aug 2014 12:04:48 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <20140801095634.GA1610@yemaya>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
 <20140801095634.GA1610@yemaya>
Message-ID: <53DB6640.4040408@ibotty.net>

hi,

> However, if we add noise that depends on the input, the filtering won't
> remove it, because for each given input it is constant. Instead of
> removing the noise component from `code(input) + system_noise()`,
> leaving `code(input)`, the attacker now deals with `code(input) +
> hash(input) + system_noise()`, leaving them with `code(input) +
> hash(input)`. Without cracking the hash, I don't know how you'd remove
> the hash-based delay from the sample; possible mistakes would be
> insufficient granularity in the hash-based delay (e.g. if the difference
> between code paths is 1ms and our delay has a 100ms granularity, it's
> still trivial to filter out the hash noise), insufficient range (if the
> difference between code paths is 100ms and our delay is between 0 and
> 25ms, we still have two distinct groups), a weak hash function, and
> probably a bunch more.

just a note, that that's what sebastian schinzel's "Deterministic and
Unpredictable delay padding" is about. see the talk (i linked to earlier):

talk from sebastian schnitzler on 29c3:

http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_side_h264.html

slides:
  http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf

abstract:
  http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf

cheers,
  tob

From tdammers at gmail.com  Fri Aug  1 10:12:31 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 12:12:31 +0200
Subject: [Haskell-cafe] www.galois.com vs Google??
In-Reply-To: <CA+0XtC_NzW-c5veXJVC5Zuvc9_HVoBvdJLXb9L9fB4AF_f6mrQ@mail.gmail.com>
References: <CA+0XtC-ukB8ifWejmNYY5mWPBNA3qBiFh8WVQpHVQDoZ4EF52Q@mail.gmail.com>
 <20140731102434.GD1558@yemaya>
 <CA+0XtC_NzW-c5veXJVC5Zuvc9_HVoBvdJLXb9L9fB4AF_f6mrQ@mail.gmail.com>
Message-ID: <20140801101230.GE1610@yemaya>

I believe that ultimately the answer lies in applying both strategies.

Provable correctness is great, and it helps keep truckloads of
headdesk-worthy oversights out the door, and a strict static type system
keeps good programmers honest - but people still make mistakes, design
oversights, or just implement the wrong thing correctly. That kind of
bug can never be caught through formal / technical means: even in the
most rigid formal type system, you can still implement things based on
wrong assumptions, and all the type system will do for you is confirm
that the code you wrote matches your wrong assumptions.

OTOH, that doesn't mean we should let go of static checks altogether -
that's as silly as saying we shouldn't wear seatbelts because they don't
save *all* lives in traffic accidents. Static checks are useful to weed
out something like 99% of the stupid mistakes people make all the time;
for the remaining 1%, we still need manual labor and scrupulous auditing
and pen-testing. The part where you check whether the real-world
assumptions that your code is based on are actually valid is something
we cannot possibly automate - we'd need a machine with full
understanding of the real world to do that.

Oh, and just to make this clear: when I say "static type checker", I am
here talking about the concept in the widest possible sense, including
unit test suites (which, if you think about it, are just another way of
implementing an ad-hoc static type system), static code analyzers,
coding style checkers, etc.

On Fri, Aug 01, 2014 at 03:53:04AM -0500, Vasili I. Galchin wrote:
> Tobias,
> 
>      I pretty agree with your response. I was  trying to challenge the
> entire audience to think about the issue about software
> correctness(e.g. strong typefullness (and static type checking) like
> Haskell, et. al. vs no type-checking/ dynamic type checking). My point
> is how can we as a community respond to Google's challenge?? In my
> humble opinion (IMHO) I think Google has missed the point regarding
> contemporary software correctness problems  .. (and also the Tor
> project . given the languages of implementation) ..
> 
>        Here is a very simple and cheesy example .. I worked at HP on a
> contract .. . a predecessor   of mine used with typefullnes of C++ (I
> thinking using type casting ) and did a buffer overrun of "heap"
> allocated that corrupted "the heap allocator metadata" (malloc) ....
> of course I used to "gdb" to do a "postmordum after the patient died"
> ... IHMO I would been more happier if this "overrun" had been detected
> at compile-tyime .. due to static strong type checking ... :-)
> 
>       Alll grammer errors are due to my cat Buddy ...
> 
> Vasya
> 
> On Thu, Jul 31, 2014 at 5:24 AM, Tobias Dammers <tdammers at gmail.com> wrote:
> > The way I read that article, those are two very different goals and
> > approaches.
> >
> > The "Project Zero" thing seems to be about subjecting "everything" to
> > thorough security checking by the best experts Google can buy, in order
> > to fix as many security problems on the internet as they possibly can.
> >
> > The software correctness problem is somewhat related, but not entirely -
> > not all security problems are software bugs, and not all software bugs
> > are security problems.
> >
> > On a side note, I think both problems are inherently unsolvable - we can
> > go a long way cleaning up the solvable problems, and building an
> > infrastructure that avoids them by design, but some potential for bugs
> > and flaws will always remain, at least as long as we're using reasonable
> > definitions of "programming" and "software".
> >
> > On Wed, Jul 30, 2014 at 10:08:06PM -0500, Vasili I. Galchin wrote:
> >> Hello Haskellers(and all FPL people),
> >>
> >>         I just ran across the following effort by Google:
> >> http://blogs.techworld.com/war-on-error/2014/07/googles-project-zero-flaw-programme-do-gooding-spin-or-a-much-needed-evolution/index.htm
> >>
> >>          It seems to me that www.galois.com(www.janestreetcapital.com)
> >> realizes that the solution to software correctness problems doesn't
> >> lie with uncontrolled "mutability" ...
> >>
> >>         Question: does Google concur with www.galois.com or google's
> >> effort just "more of the same"??
> >>
> >> Vasili
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe

From tdammers at gmail.com  Fri Aug  1 10:17:47 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 12:17:47 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB6640.4040408@ibotty.net>
References: <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
 <20140801095634.GA1610@yemaya> <53DB6640.4040408@ibotty.net>
Message-ID: <20140801101746.GF1610@yemaya>

Yeah, hadn't read your message yet.

This practice is actually pretty much common knowledge in the security
industry.

On Fri, Aug 01, 2014 at 12:04:48PM +0200, Tobias Florek wrote:
> hi,
> 
> >However, if we add noise that depends on the input, the filtering won't
> >remove it, because for each given input it is constant. Instead of
> >removing the noise component from `code(input) + system_noise()`,
> >leaving `code(input)`, the attacker now deals with `code(input) +
> >hash(input) + system_noise()`, leaving them with `code(input) +
> >hash(input)`. Without cracking the hash, I don't know how you'd remove
> >the hash-based delay from the sample; possible mistakes would be
> >insufficient granularity in the hash-based delay (e.g. if the difference
> >between code paths is 1ms and our delay has a 100ms granularity, it's
> >still trivial to filter out the hash noise), insufficient range (if the
> >difference between code paths is 100ms and our delay is between 0 and
> >25ms, we still have two distinct groups), a weak hash function, and
> >probably a bunch more.
> 
> just a note, that that's what sebastian schinzel's "Deterministic and
> Unpredictable delay padding" is about. see the talk (i linked to earlier):
> 
> talk from sebastian schnitzler on 29c3:
> 
> http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_side_h264.html
> 
> slides:
>  http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf
> 
> abstract:
>  http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf
> 
> cheers,
>  tob
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From fa-ml at ariis.it  Fri Aug  1 10:25:44 2014
From: fa-ml at ariis.it (Francesco Ariis)
Date: Fri, 1 Aug 2014 12:25:44 +0200
Subject: [Haskell-cafe] Does web-based email harm mailman lists?
In-Reply-To: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
References: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
Message-ID: <20140801102544.GA6094@x60s.casa>

On Fri, Aug 01, 2014 at 04:46:14PM +0700, Kim-Ee Yeoh wrote:
> The convention, say with a google-groups based mailing list, is that
> conversations in mailing list are public by default. With some manual C&P,
> you can email responses in private.
> 
> For cafe participants using web-based email, the situation is reversed,
> through no fault of their own.

Sorry if I am slow, but are you (in so many words), proposing Reply-To
munging?

That is indeed standard in google-groups (and I discover now, on haskell
beginners); it left me quite surprised when I first experienced it.
Mutt handles munging quite elegantly (when From and Reply-To are not the same,
it asks for confirmation), but are other clients so gracious?

Yes, I am worried about private replies broadcast to the world (and archived
on gmane, etc.). ^Reply-To Munging Considered Useful^ [1] is quite patronising
on the matter and doesn't convince me:

> This is simply not the responsibility of the administrator. People are
> responsible for their own mistakes. If someone is sending a private email
> which is derogatory, or otherwise embarrassing were it to be made public,
> they should probably be sending it directly, rather than as a reply to a
> public message. They should also pause and think about whether they should
> be sending it at all. This pause should be quite sufficient for a
> conscientious person using a reasonable mailer to catch any mistake that
> they might be about to make.

[1] https://web.archive.org/web/20110305025338/http://www.metasystema.org/essays/reply-to-useful.html

From tdammers at gmail.com  Fri Aug  1 10:26:41 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 1 Aug 2014 12:26:41 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB65F6.4070407@power.com.pl>
References: <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
 <20140801095634.GA1610@yemaya> <53DB65F6.4070407@power.com.pl>
Message-ID: <20140801102640.GG1610@yemaya>

On Fri, Aug 01, 2014 at 12:03:34PM +0200, Wojciech Narczy?ski wrote:
> 
> W dniu 2014-08-01 11:56, Tobias Dammers pisze:
> >On Fri, Aug 01, 2014 at 09:35:37AM +0200, Wojtek Narczy?ski wrote:
> >>Why the gimmick, for each and every piece of crypto code? Why not just use
> >>the clock for timing? The crypto lib would probably have to tune itself on
> >>startup.
> >Sorry, I didn't mean use the crypto function to cause the delay; I meant
> >using a cryptographic hash to determine how long the delay should be.
> >Once we have a number, the system clock should of course be used to
> >actually delay things.
> >
> >
> This is poinlessly complicated.
> 
> Just measure how much each execution takes, remove outliers, take the upper
> bound, wait appropriate amount of time on each call so that the attacker
> sees constant time for each call.
> 

I think you are underestimating the statistical aspect to this. In order
to do this in a useful way, you'd have to sample your own code on a
regular basis, for a large number of inputs, and you better get the
padding exactly right, because if it's off by a tiny amount, that tiny
amount will remain after averaging. It will basically boil down to a
sampling war between you and the attacker - if your sampling is really
good, your error may be really small, but the attacker can counter this
by sampling more. To make matters worse, you are playing this game
blindly: you don't know how much sampling is enough, or how much the
attacker can afford to sample.

I also think you are over-estimating the complexity of the crypto-hash
solution: suitable hashing functions are there for the taking (it
doesn't even have to be a time-hard function like bcrypt/scrypt/...
AFAIK, just one that's cryptographically sound), converting a hash into
a delay value is trivial, and you need to implement a delay mechanism
anyhow. The most "challenging" part, I think, is managing a secret to
seed the hash function.

From wojtek at power.com.pl  Fri Aug  1 10:53:46 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qY2llY2ggTmFyY3p5xYRza2k=?=)
Date: Fri, 01 Aug 2014 12:53:46 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <20140801102640.GG1610@yemaya>
References: <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
 <20140801095634.GA1610@yemaya> <53DB65F6.4070407@power.com.pl>
 <20140801102640.GG1610@yemaya>
Message-ID: <53DB71BA.6020609@power.com.pl>


W dniu 2014-08-01 12:26, Tobias Dammers pisze:
> On Fri, Aug 01, 2014 at 12:03:34PM +0200, Wojciech Narczy?ski wrote:
>> W dniu 2014-08-01 11:56, Tobias Dammers pisze:
>>> On Fri, Aug 01, 2014 at 09:35:37AM +0200, Wojtek Narczy?ski wrote:
>>>> Why the gimmick, for each and every piece of crypto code? Why not just use
>>>> the clock for timing? The crypto lib would probably have to tune itself on
>>>> startup.
>>> Sorry, I didn't mean use the crypto function to cause the delay; I meant
>>> using a cryptographic hash to determine how long the delay should be.
>>> Once we have a number, the system clock should of course be used to
>>> actually delay things.
>>>
>>>
>> This is poinlessly complicated.
>>
>> Just measure how much each execution takes, remove outliers, take the upper
>> bound, wait appropriate amount of time on each call so that the attacker
>> sees constant time for each call.
>>
> I think you are underestimating the statistical aspect to this. In order
> to do this in a useful way, you'd have to sample your own code on a
> regular basis, for a large number of inputs, and you better get the
> padding exactly right, because if it's off by a tiny amount, that tiny
> amount will remain after averaging. It will basically boil down to a
> sampling war between you and the attacker - if your sampling is really
> good, your error may be really small, but the attacker can counter this
> by sampling more. To make matters worse, you are playing this game
> blindly: you don't know how much sampling is enough, or how much the
> attacker can afford to sample.
I would sample a little during startup to derive a rough upper bound of 
WCET, and then sample randomly during runtime to lower the bound. The 
attacker runs would be sampled opportunistically, too. Okay, this is not 
very simple.
> I also think you are over-estimating the complexity of the crypto-hash
> solution: suitable hashing functions are there for the taking (it
> doesn't even have to be a time-hard function like bcrypt/scrypt/...
> AFAIK, just one that's cryptographically sound), converting a hash into
> a delay value is trivial, and you need to implement a delay mechanism
> anyhow. The most "challenging" part, I think, is managing a secret to
> seed the hash function.
>
Okay, this is indeed simpler. I think the hash function just has to be 
deterministic. But the downside will always be more delay then needed. 
Note that worst case execution time is a (degenerate) deterministic hash 
function.

From allbery.b at gmail.com  Fri Aug  1 13:53:55 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 1 Aug 2014 09:53:55 -0400
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB63BE.6080405@power.com.pl>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
 <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
 <53DB5F45.20104@ibotty.net> <53DB63BE.6080405@power.com.pl>
Message-ID: <CAKFCL4Uzo-aUTamZFYGoPhKs19SuMWt-LGePH3YSu8N_a+qdfA@mail.gmail.com>

On Fri, Aug 1, 2014 at 5:54 AM, Wojciech Narczy?ski <wojtek at power.com.pl>
wrote:

> And, by the way, we're all on NSA watch list now.


If you've ever given a thought to security, you were already on it. >.>

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/f15bc62c/attachment.html>

From allbery.b at gmail.com  Fri Aug  1 14:17:13 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 1 Aug 2014 10:17:13 -0400
Subject: [Haskell-cafe] Tor project and Haskell (FPL) ,..
In-Reply-To: <CA+0XtC-PBiHqXms09JgSEL1rSjWKh7QjFKhswmBpBoX2WEx-MA@mail.gmail.com>
References: <CA+0XtC-PBiHqXms09JgSEL1rSjWKh7QjFKhswmBpBoX2WEx-MA@mail.gmail.com>
Message-ID: <CAKFCL4Vj-opbv24z1di6HWyDma00O77E_maMWV+J926n5cQS4g@mail.gmail.com>

On Fri, Aug 1, 2014 at 2:58 AM, Vasili I. Galchin <vigalchin at gmail.com>
wrote:

> Sometimes one sentence IHMO provokes thought.


Only if sufficiently well-chosen; otherwise it just provokes confusion.
Perhaps leave that form of rhetoric to wordsmiths in that case.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/5fbc33f5/attachment.html>

From k.bleijenberg at lijbrandt.nl  Fri Aug  1 15:43:15 2014
From: k.bleijenberg at lijbrandt.nl (Kees Bleijenberg)
Date: Fri, 1 Aug 2014 17:43:15 +0200
Subject: [Haskell-cafe] haskell on Debian
Message-ID: <000001cfad9f$4ee130e0$eca392a0$@bleijenberg@lijbrandt.nl>

I want to reinstall Haskell on Debian (in Virtualbox on Windows).

So: apt-get remove haskell-platform

Deleted all maps with packages in it.

apt-get install haskell-platform (installing previous selected ... etc)

cabal update

All this without errors of warnings.

cabal install cabal-install

Error: /var/lib/ghc/package.conf.d: openFile: does not exist

Why this error? Setup doesn't create this directory?

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/d1b5c012/attachment.html>

From noteed at gmail.com  Fri Aug  1 17:14:15 2014
From: noteed at gmail.com (Vo Minh Thu)
Date: Fri, 1 Aug 2014 19:14:15 +0200
Subject: [Haskell-cafe] EsseOS: Haskell-based tailored services for the cloud
Message-ID: <CAOHoMskPbNJzaWd3iSbVrs929qnekYr_9ZtWJSVUDt4RAKmsKQ@mail.gmail.com>

Hi,

I came across this seemingly interesting paper:

    EsseOS: Haskell-based tailored services for the cloud
    http://dl.acm.org/citation.cfm?id=2541587

which is unfortunately behind a paywall.

I was wondering if someone knew about a freely accessible version of
that paper, or about some project page, or just heard of it.

Thank you,
Thu

From janis.voigtlaender at gmail.com  Fri Aug  1 19:53:16 2014
From: janis.voigtlaender at gmail.com (=?UTF-8?Q?Janis_Voigtl=C3=A4nder?=)
Date: Fri, 1 Aug 2014 21:53:16 +0200
Subject: [Haskell-cafe] EsseOS: Haskell-based tailored services for the
	cloud
In-Reply-To: <CAOHoMskPbNJzaWd3iSbVrs929qnekYr_9ZtWJSVUDt4RAKmsKQ@mail.gmail.com>
References: <CAOHoMskPbNJzaWd3iSbVrs929qnekYr_9ZtWJSVUDt4RAKmsKQ@mail.gmail.com>
Message-ID: <CAGkFuyB6hu8nO=iZ-tQc2cuPRiEyoXPNCt+LX0rv=_sBnGdN6w@mail.gmail.com>

You can write to the authors and ask them for an author copy (pdf). If you
can't find their email addresses, contact me off the list, and I can let
you know.

Am Freitag, 1. August 2014 schrieb Vo Minh Thu :

> Hi,
>
> I came across this seemingly interesting paper:
>
>     EsseOS: Haskell-based tailored services for the cloud
>     http://dl.acm.org/citation.cfm?id=2541587
>
> which is unfortunately behind a paywall.
>
> I was wondering if someone knew about a freely accessible version of
> that paper, or about some project page, or just heard of it.
>
> Thank you,
> Thu
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org <javascript:;>
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/09aae2e5/attachment.html>

From bertram.felgenhauer at googlemail.com  Fri Aug  1 21:30:29 2014
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Fri, 1 Aug 2014 23:30:29 +0200
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
 vectors
In-Reply-To: <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
 <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
Message-ID: <20140801213029.GA8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>

Carter Schonwald wrote:
> I tried compiling your original codes with normal unsafePerformIO on ghc
> 7.8.3, and I get the "B" result at -O0 and the "A" result at O1 and O2
> 
> {-# LANGUAGE BangPatterns,  UnboxedTuples,MagicHash #-}
> 
> import Data.ByteString.Internal (inlinePerformIO)
> import qualified Data.Vector as V
> import qualified Data.Vector.Mutable as VM
> 
> import System.IO.Unsafe
> 
> main :: IO ()
> main = do
>     vm <- VM.new 1
>     VM.write vm 0 'A'
>     !b<- return $! 'B'
>     let !x = unsafePerformIO $! VM.write vm 0 b
>     x `seq` (V.freeze vm >>= print)

Note that the compiler sees through  !b<- return $! 'B', so it does
not introduce a data dependency. Looking at the core, x is getting
evaluated (writing 'B' to the array) before the writeArray# call
resulting from VM.write vm 0 'A'.

I'm not 100% sure that the compiler is within its rights for reordering
code here; after all, writeArray# has a side effect, which will not
be performed in the hypothetical case that evaluation of x diverges.
But at least reordering effects is far less surprising than effects
disappearing completely.

[Michael Snoyman:]
> > One last question on the GHC front, however. It *does* seem like there's
> > still a bug in GHC here, since presumably case-ing on an unboxed tuple
> > should force evaluation of both of its values.

No, it should not. If it did,

  main = return undefined >> print "Foo"

would fail.

Cheers,

Bertram

From mike at proclivis.com  Fri Aug  1 21:35:39 2014
From: mike at proclivis.com (Michael Jones)
Date: Fri, 1 Aug 2014 15:35:39 -0600
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB5C29.8040002@centrum.cz>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <784C06CC-006E-4BBD-B1BD-20D7D6256093@proclivis.com>
 <53DB5C29.8040002@centrum.cz>
Message-ID: <107B6B56-162E-4CFF-93F5-DB1192C41000@proclivis.com>

Karel,

I know I can build on the target, but I am avoiding it. I am trying to keep the target simple and small. I don't even have a disk drive on the target.

Mike

> :
> 
> 
> [Unrelated to original topic!]
> 
> If you're using Linux on i.MX6, then you can also use native compilation which is working better than cross-compilation.
> 
> If eCos does not provide proper POSIX, then you can also have a look at RTEMS. I attempted to port GHC to it year ago IIRC, but it would require some changes to cabal and libs too. But anyway this is really nice OS target...
> 
> Karel
> 
>> On 08/ 1/14 01:42 AM, Michael Jones wrote:
>> I am not an expert, but I think timing attacks try to push data though a system and look for time dependent calculations. If every packet that leaves a system has the same data size and the same encryption time, the attacker would not be able to detect any difference in time wrt difference in data. Time could also vary if you mucked with the voltage of the CPU, or if some calculation could.
>> 
>> I would guess that if it is not possible to make all packages the same size and time, randomizing time would hide time differences. However, it may be possible to extract randomness. This is just a conjecture on my part.
>> 
>> A work around might be to use hardware encryption. I work on an A9, and with openssl, there is the option to have hardware do the actual encryption, etc. I have not had the time to implement this, but I believe that Linux for IMX6 has support for hardware encryption. If nothing else, it is best to use the hardware for random number generation.
>> 
>> My interested would be to run it on my Wandboard and Yocto linux. Hence my questions about cross-compilers. I am still stuck on that problem because I have not figure out how to make GHC pass architecture options to the gcc cross compiler but not to the local linux gcc. It seems some variables in the build are tied together. But eventually I?ll probably figure it out.
>> 
>> I think the Hypervisor approach is also interesting. Just build a mini OS with TLS and Tor. That could reduce the attack surface by eliminating Linux. This would be interesting for a repeater. I was thinking doing the same onto of a smaller kernel such as eCos. I tried to get GHC running on that, but there is some missing POSIX support, so I went back to linux.
>> 
>> Mike
>> 
>>> On Jul 31, 2014, at 3:11 PM, Wojtek Narczy?ski<wojtek at power.com.pl>  wrote:
>>> 
>>>> On 31.07.2014 18:59, Adam Wick wrote:
>>>> As for TLS, it is possible that timing attacks based on a functional language implementation could be more likely than those for a traditional C implementation. (...) I don?t believe the balance has been studied, but it?d be interesting.
>>> I believe no evidence is available, not even anecdotal. And it would be rather expensive a subject to study.
>>> 
>>> But, AFAIK, the (necessary and sufficient) protection against timing attacks is the addition of randomized waits. In the protocol layer, not in pure encryption/decryption/hashing routines. I strive not to use words I don't understand, but I have the M. word in mind for structuring such a computation.
>>> 
>>> In other words, I think it is a myth.
>>> 
>>> --
>>> Kind regards,
>>> Wojtek N.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 


From icfp.publicity at googlemail.com  Fri Aug  1 21:51:04 2014
From: icfp.publicity at googlemail.com (David Van Horn)
Date: Fri, 1 Aug 2014 17:51:04 -0400
Subject: [Haskell-cafe] ICFP 2014 Final Call for Participation
Message-ID: <CAAmpXii5SLdY=yAnTkKBj_e6X2+DWqZfo6ncE0oPpXrB_QWQ0Q@mail.gmail.com>

[ Early registration ends 3 Aug; Invited speakers and conference
  program have been announced. ]

=====================================================================

Final Call for Participation

ICFP 2014
19th ACM SIGPLAN International Conference on Functional Programming
and affiliated events

August 31 - September 6, 2014
Gothenburg, Swedenhttp://icfpconference.org/icfp2014/

=====================================================================

ICFP provides a forum for researchers and developers to hear
about the latest work on the design, implementations, principles, and
uses of functional programming. The conference covers the entire
spectrum of work, from practice to theory, including its peripheries.

A full week dedicated to functional programming:
1 conference, 1 symposium, 10 workshops, tutorials,
programming contest results, student research competition

 * Program:
   http://icfpconference.org/icfp2014/program.html

 * Accepted Papers:
   http://icfpconference.org/icfp2014/accepted.html

 * Local arrangements (including travel and accommodation):
   http://icfpconference.org/icfp2014/local.html

 * Registration is available via:
   https://regmaster4.com/2014conf/ICFP14/register.php
   Early registration is due 3 August, 2014.

 * Programming contest, 25-28 July, 2014:
   http://icfpcontest.org/

 * Follow @icfp_conference on twitter for the latest news:
   http://twitter.com/#!/icfp_conference

Keynote speakers:

 * Kathleen Fisher (Tufts University):
     Using Formal Methods to Enable More Secure Vehicles:
     DARPA's HACMS Program

 * Robert Bruce Findler (Northwestern University):
     Behavioral Software Contracts

 * Stephanie Weirich (University of Pennsylvania):
     Depending on Types

There are several events affiliated with ICFP:

  Sunday, August 31
    ACM SIGPLAN Workshop on Generic Programming
    ACM SIGPLAN Workshop on Higher-order Programming with Effects

  Monday, September 1 ? Wednesday, September 3
    ICFP

  Thursday, September 4
    ACM SIGPLAN Commercial Users of Functional Programming: Day 1,
    Tutorials
    ACM SIGPLAN Haskell Symposium: Day 1
    ACM SIGPLAN Workshop on Functional High-Performance Computing
    ACM SIGPLAN ML Family Workshop

  Friday, September 5
    ACM SIGPLAN Commercial Users of Functional Programming: Day 2,
    Tutorials
    ACM SIGPLAN Haskell Symposium: Day 2
    ACM SIGPLAN OCaml Workshop
    ACM SIGPLAN Erlang Workshop

  Saturday, September 6
    ACM SIGPLAN Commercial Users of Functional Programming: Day 3,
    Talks
    ACM SIGPLAN Haskell Implementors Workshop
    ACM SIGPLAN Workshop on Functional Art, Music, Modeling and Design

Conference Organizers

  General Chair:
    Johan Jeuring, Utrecht University
  Program Chair:
    Manuel Chakravarty, University of New South Wales
  Local Arrangements Chair:
    Bj?rn von Sydow, Chalmers University
  Industrial Relations Chair:
    Anil Madhavapeddy, University of Cambridge
  Workshop Co-Chairs:
    Tom Schrijvers, Ghent University
    Sam Tobin-Hochstadt, Indiana University
  Programming Contest Co-Chairs:
    Duncan Coutts, Well Typed LLP
    Nicolas Wu, University of Oxford
  Student Research Competition Chair:
    Meng Wang, Chalmers University
  Publicity Chair:
    David Van Horn, University of Maryland
  Video Chair:
    Iavor Diatchki, Galois
    Malcolm Wallace, Standard Chartered Bank

Industrial partners:

  Platinum partners
    Jane Street Capital
  Gold partners
    Google
    Microsoft Research
    Mozilla
    Oracle Labs
    Standard Chartered Bank
  Silver partners
    Bloomberg
    Credit Suisse
    CyberPoint
    Erlang Solutions
    Facebook
    Galois
    Klarna
    Lexifi
    Twitter
  Bronze partners
    Alephcloud
    IntelliFactory
    Opera Software
    QuviQ
    Systeor Vest AS

=====================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/94dc0679/attachment.html>

From noteed at gmail.com  Fri Aug  1 22:20:38 2014
From: noteed at gmail.com (Vo Minh Thu)
Date: Sat, 2 Aug 2014 00:20:38 +0200
Subject: [Haskell-cafe] EsseOS: Haskell-based tailored services for the
	cloud
In-Reply-To: <CAGkFuyB6hu8nO=iZ-tQc2cuPRiEyoXPNCt+LX0rv=_sBnGdN6w@mail.gmail.com>
References: <CAOHoMskPbNJzaWd3iSbVrs929qnekYr_9ZtWJSVUDt4RAKmsKQ@mail.gmail.com>
 <CAGkFuyB6hu8nO=iZ-tQc2cuPRiEyoXPNCt+LX0rv=_sBnGdN6w@mail.gmail.com>
Message-ID: <CAOHoMs=j6hkAQkqubbEVhETeLAM1nQobJRxwOVgd1q6ff=o1Sw@mail.gmail.com>

I emailed the authors and someone sent me a copy off list.

Thanks,
Thu
Le 1 ao?t 2014 21:53, "Janis Voigtl?nder" <janis.voigtlaender at gmail.com> a
?crit :

> You can write to the authors and ask them for an author copy (pdf). If you
> can't find their email addresses, contact me off the list, and I can let
> you know.
>
> Am Freitag, 1. August 2014 schrieb Vo Minh Thu :
>
>> Hi,
>>
>> I came across this seemingly interesting paper:
>>
>>     EsseOS: Haskell-based tailored services for the cloud
>>     http://dl.acm.org/citation.cfm?id=2541587
>>
>> which is unfortunately behind a paywall.
>>
>> I was wondering if someone knew about a freely accessible version of
>> that paper, or about some project page, or just heard of it.
>>
>> Thank you,
>> Thu
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/abd1cd76/attachment.html>

From wojtek at power.com.pl  Fri Aug  1 23:30:23 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Sat, 02 Aug 2014 01:30:23 +0200
Subject: [Haskell-cafe] Tor project
In-Reply-To: <53DB6640.4040408@ibotty.net>
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl>
 <CAFdyfB2_bcuLeE3EkidDkdRzYMr=Xfw_fBsLFgS1ygwQpM3a=g@mail.gmail.com>
 <20140801071031.GA23813@yemaya> <53DB4349.6060908@power.com.pl>
 <20140801095634.GA1610@yemaya> <53DB6640.4040408@ibotty.net>
Message-ID: <53DC230F.60701@power.com.pl>

On 01.08.2014 12:04, Tobias Florek wrote:
>
> just a note, that that's what sebastian schinzel's "Deterministic and
> Unpredictable delay padding" is about. see the talk (i linked to 
> earlier):
>
> talk from sebastian schnitzler on 29c3:
>
> http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_side_h264.html 
>
>
> slides:
>  http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf
>
> abstract:
>  http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf
>
I just realized that the unifying framework for countermeasures of any 
resource based attacks (time, electricity, heat, radiation) is MaxEnt. 
Constant time is trivially MaxEnt. If you can't do constant time, go for 
uniform distribution over a number of predefined times. If you can't do 
that, from the space of possible distributions, choose the one with 
maximum entropy. So much for the theory.

E.T. Jaynes would be delighted to see his work appear in yet another 
context.

-- 
Wojtek

From a at lelf.me  Sat Aug  2 01:10:22 2014
From: a at lelf.me (Antonio Nikishaev)
Date: Sat, 02 Aug 2014 05:10:22 +0400
Subject: [Haskell-cafe] Tor project
References: <CA+0XtC_ZMqEGzfQEVoJeQDknAzWhvKREqidgxJZF26A-29JRUw@mail.gmail.com>
 <lrci4n$ito$1@ger.gmane.org>
 <0A84F9F7-1349-489E-8B36-717FC0226D9F@proclivis.com>
 <CAOk36JgTezuRvRgypijPDMOTiB0ZSqvmTjOMojHt99dCtsgE=g@mail.gmail.com>
 <BE276BE3-CF40-4529-B994-06E8BB948416@galois.com>
 <53DAB0E9.70207@power.com.pl> <53DB4F49.2050207@ibotty.net>
 <CAP6YhL+2WbC2j7KbmdkR9RpjGjO5q+5749NaBX6qG+BaeZ-cfg@mail.gmail.com>
 <53DB5F45.20104@ibotty.net>
Message-ID: <m2vbqb1ytd.fsf@lelf.me>

Tobias Florek <haskell at ibotty.net> writes:

> hi,
>
>> Just wanted to say that what I posted might give hope for such
>> "branchless" code (or in fact: code that may branch, but by
>> construction not in a detectable way).
>
> i don't have the papers handy, but on the same host you can observe
> cache line collisions. that means you cannot do something different
> that takes the same time and generates the same amount of heat. you
> will have to do _the same thing_.

For example Flush+Reload attack, https://eprint.iacr.org/2013/448.pdf.
Or branch prediction attacks (see refs in the paper above).
Absolutely beautiful stuff.

> of course packages like vincent hanquez securemem provide that kind of
> equality checks (and other very useful properties). so some building
> blocks are there. interaction with the garbage collector is still
> something to worry about though. in some gcs you can observe whether a
> string is in use somewhere in the program or not. i am not intimate
> with ghc's gc but i don't expect that particular vulnerability is a
> problem when using securemem (or even bytestring or text), but there
> might (and i assume will) be many other opportunities to observe some
> state from outside the program.
>
> don't let me discourage you though. every step to less side channels
> is a valuable step!
>
> tob

-- 
lelf


From cmyzie28 at gmail.com  Sat Aug  2 03:07:25 2014
From: cmyzie28 at gmail.com (Chris Myzie)
Date: Fri, 1 Aug 2014 20:07:25 -0700 (PDT)
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process of
	createProcess
In-Reply-To: <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
References: <3a8ab3dd-6ae0-4132-90d7-c7af97d3fc87@googlegroups.com>
 <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
Message-ID: <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>

I'm reposting this message because I think it only went to the google group 
and not the official haskell-cafe list:

On Friday, August 1, 2014 10:06:32 AM UTC-4, Chris Myzie wrote:
>
> As a workaround, I am able to trick the child haskell process into 
> thinking it's running in an interactive terminal by wrapping it with 
> /usr/bin/script:
>
> createProcess (proc "/usr/bin/script" ["-qc","./A","/dev/null"]) { std_out 
> = CreatePipe }
>
> I still think haskell is using screwy defaults for stdout buffering..
>
> On Thursday, July 31, 2014 3:24:47 PM UTC-4, Chris Myzie wrote:
>>
>> Hello,
>>
>> I'm trying to write a wrapper process that will be able to read any child 
>> process' stdout.  The problem I'm running into is that unless I force the 
>> child's stdout to LineBuffering, it defaults to BlockBuffering.  Is 
>> BlockBuffering really the default in this case?  I don't want to have to 
>> modify all of the child processes that I want to use with this wrapper.
>>
>> Below is a simple test case.  A.hs is the child process, and B.hs is the 
>> wrapper.  If I run B.hs, I will get no output unless I uncomment the line 
>> in A.hs.
>>
>> Thanks,
>> Chris
>>
>>
>> ------------------------------ A.hs ---------------------------
>> import Control.Concurrent
>> import System.IO
>>
>> main :: IO ()
>> main = do
>>   -- hSetBuffering stdout LineBuffering
>>   putStrLn "test" >> threadDelay 1000000 >> main 
>>
>>
>> ------------------------------ B.hs ---------------------------
>> import Control.Monad
>> import System.IO
>> import System.Process
>>
>> main :: IO ()
>> main = do
>>   (_,Just h,_,_) <- createProcess (proc "./A" []) { std_out = CreatePipe }
>>   hSetBuffering h LineBuffering
>>   forever $ hGetLine h >>= putStrLn
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/ffea6298/attachment.html>

From allbery.b at gmail.com  Sat Aug  2 03:20:08 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 1 Aug 2014 23:20:08 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
References: <3a8ab3dd-6ae0-4132-90d7-c7af97d3fc87@googlegroups.com>
 <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
 <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
Message-ID: <CAKFCL4X_UB=kPD9r-8BH__dgJjOp0L7E1WT7iZ25q=KONZRong@mail.gmail.com>

On Fri, Aug 1, 2014 at 11:07 PM, Chris Myzie <cmyzie28 at gmail.com> wrote:

> As a workaround, I am able to trick the child haskell process into
> thinking it's running in an interactive terminal by wrapping it with
> /usr/bin/script:
>

We discussed this on IRC the other day. Haskell is doing the same thing
that C/C++ stdio / iostreams, and most other buffering systems, do: line
buffering on terminal-like devices, block buffering on files and pipes.
This is generally expected behavior; although it can be confusing to new
programmers, ultimately it is more efficient for most programs.

Interactive use like this, especially over pipes, is fairly unusual;
normally you're just copying data around /en masse/, and block buffering is
far more efficient. Note that line buffering is not and can not be
implemented at the kernel level for ordinary files or pipes, so the kernel
interface is actually character buffering which is extremely inefficient
(at least one context switch per individual character).

You might want to search for something like "buffering line block pipes
files" to see quite a lot of discussion about it, in pretty much every
language you can think of.

By the way, more efficient than using script(1) is, as I told you in IRC,
to use the mechanism it is using directly: pseudo-terminals (ptys). See
http://hackage.haskell.org/package/unix-2.7.0.1/docs/System-Posix-Terminal.html#g:6
for the standard pty stuff or
http://hackage.haskell.org/package/posix-pty-0.1.0/docs/System-Posix-Pty.html
for what is claimed to be a simpler interface intended for what you are
doing.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/83b09de7/attachment.html>

From vigalchin at gmail.com  Sat Aug  2 06:28:41 2014
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Sat, 2 Aug 2014 01:28:41 -0500
Subject: [Haskell-cafe] Functional programming and William Lawvere's notion
 of "variable sets"(vs topos of "static sets") in a Topos ...
Message-ID: <CA+0XtC-1x8M-=nYcHe6v57SpxLFYqj38Y6b2ORxpHGW-RdcXiQ@mail.gmail.com>

Hello Haskellers,

     I have been re-reading William Lawvere's description of "variable
sets" (a functor category) in "a elementary topoi" on a discrete
poset/preset vs a "abstract sets" in the topos of abstract sets . In
Haskell( and other FPLs .. ) aren't "pure" computations just over the
topos of abstract sets and "mutable" /"time-varying/stateful"
computations aren't just "variable sets" (i.e. a functor over a
discrete preset-poset)?? Please forgive my bad English :-( If
uncertain aboyt my Englsih, please say so.

Kind regards,

Vasya

P.S. Yes I am familiar with Eugenio Moggi's papers on using monads for
stateful computations ..

From elliot.robinson at argiopetech.com  Sat Aug  2 06:32:46 2014
From: elliot.robinson at argiopetech.com (Elliot Robinson)
Date: Sat, 2 Aug 2014 02:32:46 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <CAKFCL4X_UB=kPD9r-8BH__dgJjOp0L7E1WT7iZ25q=KONZRong@mail.gmail.com>
References: <3a8ab3dd-6ae0-4132-90d7-c7af97d3fc87@googlegroups.com>
 <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
 <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
 <CAKFCL4X_UB=kPD9r-8BH__dgJjOp0L7E1WT7iZ25q=KONZRong@mail.gmail.com>
Message-ID: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>

I second pseudo-terminals. I find the System.Posix.Terminal to be very
usable (though I've admittedly never tried System.Posix.Pty). I
occasionally dabble with "bots" for terminal-based games (e.g., Nethack),
and have used PTYs with some deal of success.

I've included some code from a Nethack bot attempt from several years ago.
Hopefully you'll find it useful. As a quick usage/rationale overview, I
feed an attoparsec parser by repeatedly calling receive (intermixed with
some intelligent use of `transmit` to deal with messages and other
incomplete screen updates) until I receive a valid map. `hGetNonBlocking`
bypasses the standard buffering mechanisms and returns whatever is in the
PTY buffer (which may be nothing) rather than waiting for the specified
line/block/whatever buffer to fill. `stop` and `start` should be obvious in
their purpose, if not their implementation.

data Local = Local { pty :: Handle }

class Connection a where
    transmit :: a -> ByteString -> IO ()
    receive  :: a -> IO ByteString
    stop     :: a -> IO ()
    start    :: IO a

instance Connection Local where
    transmit l s = B.hPut (pty l) s
    receive  l   = B.hGetNonBlocking (pty l) 4096
    stop     l   = hClose $ pty l
    start        = do
        (fd1, fd2) <- openPseudoTerminal
        (hPty) <- fdToHandle fd1
        slave <- fdToHandle fd2
        _<- createProcess (proc "sh" ["-c", "/usr/games/bin/nethack"]){
std_in = (UseHandle slave), std_out = (UseHandle slave) }
        return $ Local hPty


Cheers,
Elliot Robinson
Phone: (321) 252-9660
Site: www.argiopetech.com
Email: elliot.robinson at argiopetech.com

PGP Fingerprint: 0xD1E72E6A9D0610FFBBF838A6FFB5205A9FEDE59A


On Fri, Aug 1, 2014 at 11:20 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Fri, Aug 1, 2014 at 11:07 PM, Chris Myzie <cmyzie28 at gmail.com> wrote:
>
>> As a workaround, I am able to trick the child haskell process into
>> thinking it's running in an interactive terminal by wrapping it with
>> /usr/bin/script:
>>
>
> We discussed this on IRC the other day. Haskell is doing the same thing
> that C/C++ stdio / iostreams, and most other buffering systems, do: line
> buffering on terminal-like devices, block buffering on files and pipes.
> This is generally expected behavior; although it can be confusing to new
> programmers, ultimately it is more efficient for most programs.
>
> Interactive use like this, especially over pipes, is fairly unusual;
> normally you're just copying data around /en masse/, and block buffering is
> far more efficient. Note that line buffering is not and can not be
> implemented at the kernel level for ordinary files or pipes, so the kernel
> interface is actually character buffering which is extremely inefficient
> (at least one context switch per individual character).
>
> You might want to search for something like "buffering line block pipes
> files" to see quite a lot of discussion about it, in pretty much every
> language you can think of.
>
> By the way, more efficient than using script(1) is, as I told you in IRC,
> to use the mechanism it is using directly: pseudo-terminals (ptys). See
> http://hackage.haskell.org/package/unix-2.7.0.1/docs/System-Posix-Terminal.html#g:6
> for the standard pty stuff or
> http://hackage.haskell.org/package/posix-pty-0.1.0/docs/System-Posix-Pty.html
> for what is claimed to be a simpler interface intended for what you are
> doing.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/275fe31b/attachment.html>

From elliot.robinson at argiopetech.com  Sat Aug  2 06:49:27 2014
From: elliot.robinson at argiopetech.com (Elliot Robinson)
Date: Sat, 2 Aug 2014 02:49:27 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
References: <3a8ab3dd-6ae0-4132-90d7-c7af97d3fc87@googlegroups.com>
 <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
 <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
 <CAKFCL4X_UB=kPD9r-8BH__dgJjOp0L7E1WT7iZ25q=KONZRong@mail.gmail.com>
 <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
Message-ID: <CAG7kECP1=i+vWLO-xzu0BxLaxrLJLouCrbUv5YkWWirjUpW_Hw@mail.gmail.com>

It's worth noting that `hGetNonBlocking` only works as described with GHC
on *nix. Windows and non-GHC treat it as a blocking hGet. Also, unless I'm
mistaken, my example leaks the Handle for the slave PTY (though it would be
trivial to fix).

---
Elliot Robinson
Phone: (321) 252-9660
Site: www.argiopetech.com
Email: elliot.robinson at argiopetech.com

PGP Fingerprint: 0xD1E72E6A9D0610FFBBF838A6FFB5205A9FEDE59A


On Sat, Aug 2, 2014 at 2:32 AM, Elliot Robinson <
elliot.robinson at argiopetech.com> wrote:

> I second pseudo-terminals. I find the System.Posix.Terminal to be very
> usable (though I've admittedly never tried System.Posix.Pty). I
> occasionally dabble with "bots" for terminal-based games (e.g., Nethack),
> and have used PTYs with some deal of success.
>
> I've included some code from a Nethack bot attempt from several years ago.
> Hopefully you'll find it useful. As a quick usage/rationale overview, I
> feed an attoparsec parser by repeatedly calling receive (intermixed with
> some intelligent use of `transmit` to deal with messages and other
> incomplete screen updates) until I receive a valid map. `hGetNonBlocking`
> bypasses the standard buffering mechanisms and returns whatever is in the
> PTY buffer (which may be nothing) rather than waiting for the specified
> line/block/whatever buffer to fill. `stop` and `start` should be obvious in
> their purpose, if not their implementation.
>
> data Local = Local { pty :: Handle }
>
> class Connection a where
>     transmit :: a -> ByteString -> IO ()
>     receive  :: a -> IO ByteString
>     stop     :: a -> IO ()
>     start    :: IO a
>
> instance Connection Local where
>     transmit l s = B.hPut (pty l) s
>     receive  l   = B.hGetNonBlocking (pty l) 4096
>     stop     l   = hClose $ pty l
>     start        = do
>         (fd1, fd2) <- openPseudoTerminal
>         (hPty) <- fdToHandle fd1
>         slave <- fdToHandle fd2
>         _<- createProcess (proc "sh" ["-c", "/usr/games/bin/nethack"]){
> std_in = (UseHandle slave), std_out = (UseHandle slave) }
>         return $ Local hPty
>
>
> Cheers,
> Elliot Robinson
> Phone: (321) 252-9660
> Site: www.argiopetech.com
> Email: elliot.robinson at argiopetech.com
>
>  PGP Fingerprint: 0xD1E72E6A9D0610FFBBF838A6FFB5205A9FEDE59A
>
>
> On Fri, Aug 1, 2014 at 11:20 PM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Fri, Aug 1, 2014 at 11:07 PM, Chris Myzie <cmyzie28 at gmail.com> wrote:
>>
>>> As a workaround, I am able to trick the child haskell process into
>>> thinking it's running in an interactive terminal by wrapping it with
>>> /usr/bin/script:
>>>
>>
>> We discussed this on IRC the other day. Haskell is doing the same thing
>> that C/C++ stdio / iostreams, and most other buffering systems, do: line
>> buffering on terminal-like devices, block buffering on files and pipes.
>> This is generally expected behavior; although it can be confusing to new
>> programmers, ultimately it is more efficient for most programs.
>>
>> Interactive use like this, especially over pipes, is fairly unusual;
>> normally you're just copying data around /en masse/, and block buffering is
>> far more efficient. Note that line buffering is not and can not be
>> implemented at the kernel level for ordinary files or pipes, so the kernel
>> interface is actually character buffering which is extremely inefficient
>> (at least one context switch per individual character).
>>
>> You might want to search for something like "buffering line block pipes
>> files" to see quite a lot of discussion about it, in pretty much every
>> language you can think of.
>>
>> By the way, more efficient than using script(1) is, as I told you in IRC,
>> to use the mechanism it is using directly: pseudo-terminals (ptys). See
>> http://hackage.haskell.org/package/unix-2.7.0.1/docs/System-Posix-Terminal.html#g:6
>> for the standard pty stuff or
>> http://hackage.haskell.org/package/posix-pty-0.1.0/docs/System-Posix-Pty.html
>> for what is claimed to be a simpler interface intended for what you are
>> doing.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/617001e1/attachment-0001.html>

From vigalchin at gmail.com  Sat Aug  2 07:29:52 2014
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Sat, 2 Aug 2014 02:29:52 -0500
Subject: [Haskell-cafe] re-reading a Samson Abramsky paper ..
Message-ID: <CA+0XtC9cCFPRBv6V2OPTo3SUaLvRUQBPPt-vPUdwBX8=HDZtLA@mail.gmail.com>

http://staff.science.uva.nl/~ssimon/indjournal/pdf/abramsky.pdf .. no
words .. I will let Samson speak for himself .. :-)  Hopefully my
audience cam keep up with Abramsky's terseness .. he is very "cheeky"
...

From donn at avvanta.com  Sat Aug  2 07:54:47 2014
From: donn at avvanta.com (Donn Cave)
Date: Sat,  2 Aug 2014 00:54:47 -0700 (PDT)
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child processof
	createProcess
In-Reply-To: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
References: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
Message-ID: <20140802075447.2664893C2E@mail.avvanta.com>

quoth Elliot Robinson <elliot.robinson at argiopetech.com>,

>    As a quick usage/rationale overview, I
> feed an attoparsec parser by repeatedly calling receive (intermixed with
> some intelligent use of `transmit` to deal with messages and other
> incomplete screen updates) until I receive a valid map. `hGetNonBlocking`
> bypasses the standard buffering mechanisms and returns whatever is in the
> PTY buffer (which may be nothing) rather than waiting for the specified
> line/block/whatever buffer to fill.

If you don't really want non-blocking I/O (i.e., normally returns 0 bytes),
System.Posix.IO.ByteString.fdRead is a blocking read that returns available
unbuffered data.  Handles are for buffered I/O.

	Donn

From mathijs at bluescreen303.nl  Sat Aug  2 15:28:15 2014
From: mathijs at bluescreen303.nl (Mathijs Kwik)
Date: Sat, 02 Aug 2014 17:28:15 +0200
Subject: [Haskell-cafe] typed tagless-final interpretation examples broken
	with recent ghc
Message-ID: <874mxudi7k.fsf@bluescreen303.nl>

Hi all,

I've been reading up on typed tagless-final interpretations [1] and the
accompanying examples.

It seems the stuff about CPS transformations does no longer compile,
probably because of stricter typing rules. I tried both ghc 7.6 and ghc
7.8, which both give a different kind of error message. It's a bit much
and long to paste here though.

I would really like to get the example working, but couldn't manage by
only supplying type signatures. Perhaps there is some language pragma I
can turn on or off to get the old behaviour back?

The 2 files needed (no further libraries needed) are:
- http://okmij.org/ftp/tagless-final/course/TTF.hs (working) 
- http://okmij.org/ftp/tagless-final/course/CPS.hs (problem)

All help would be greatly appreciated.
Regards,
Mathijs


[1] http://okmij.org/ftp/tagless-final/course/index.html

From alexander.kjeldaas at gmail.com  Sat Aug  2 19:10:05 2014
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Sat, 2 Aug 2014 21:10:05 +0200
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
References: <3a8ab3dd-6ae0-4132-90d7-c7af97d3fc87@googlegroups.com>
 <19c8633a-8e36-448b-8c38-fc19b928c159@googlegroups.com>
 <678d92c9-e233-4a35-ba04-5458e0c02f26@googlegroups.com>
Message-ID: <CAHVSqQf7tu81COGjjY2QhH3NfuCh2eng74YpT3r97aWUm03pQQ@mail.gmail.com>

Line buffered would be an inefficient default. Stdout is fully buffered in
c99 if it can be determined that it is not attached to a terminal.

Alexander
On Aug 2, 2014 5:07 AM, "Chris Myzie" <cmyzie28 at gmail.com> wrote:

> I'm reposting this message because I think it only went to the google
> group and not the official haskell-cafe list:
>
> On Friday, August 1, 2014 10:06:32 AM UTC-4, Chris Myzie wrote:
>>
>> As a workaround, I am able to trick the child haskell process into
>> thinking it's running in an interactive terminal by wrapping it with
>> /usr/bin/script:
>>
>> createProcess (proc "/usr/bin/script" ["-qc","./A","/dev/null"]) {
>> std_out = CreatePipe }
>>
>> I still think haskell is using screwy defaults for stdout buffering..
>>
>> On Thursday, July 31, 2014 3:24:47 PM UTC-4, Chris Myzie wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to write a wrapper process that will be able to read any
>>> child process' stdout.  The problem I'm running into is that unless I force
>>> the child's stdout to LineBuffering, it defaults to BlockBuffering.  Is
>>> BlockBuffering really the default in this case?  I don't want to have to
>>> modify all of the child processes that I want to use with this wrapper.
>>>
>>> Below is a simple test case.  A.hs is the child process, and B.hs is the
>>> wrapper.  If I run B.hs, I will get no output unless I uncomment the line
>>> in A.hs.
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>> ------------------------------ A.hs ---------------------------
>>> import Control.Concurrent
>>> import System.IO
>>>
>>> main :: IO ()
>>> main = do
>>>   -- hSetBuffering stdout LineBuffering
>>>   putStrLn "test" >> threadDelay 1000000 >> main
>>>
>>>
>>> ------------------------------ B.hs ---------------------------
>>> import Control.Monad
>>> import System.IO
>>> import System.Process
>>>
>>> main :: IO ()
>>> main = do
>>>   (_,Just h,_,_) <- createProcess (proc "./A" []) { std_out = CreatePipe
>>> }
>>>   hSetBuffering h LineBuffering
>>>   forever $ hGetLine h >>= putStrLn
>>>
>>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/8d92c164/attachment.html>

From david.feuer at gmail.com  Sat Aug  2 19:56:01 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 2 Aug 2014 15:56:01 -0400
Subject: [Haskell-cafe] unfoldr with a little extra
In-Reply-To: <CAMgWh9uiDLsY8WCNhbnMAZfYgpfPwRD_LBabRNZSwLL1PgxXhQ@mail.gmail.com>
References: <CAMgWh9umr2zgD8_t09GRZTLhRMjzrFJE-05-Zokuyst6kuF1gw@mail.gmail.com>
 <CAMgWh9tOQoWgsjaZkrqt5ywzXTwztzjusr_wDjmz7aDsZw+vuA@mail.gmail.com>
 <CAMgWh9uiDLsY8WCNhbnMAZfYgpfPwRD_LBabRNZSwLL1PgxXhQ@mail.gmail.com>
Message-ID: <CAMgWh9tCvvfUaRVD4fWkxPJ9oEBwDHKvfAkrx+LontGuzntAVQ@mail.gmail.com>

Edward Kmett's NonEmpty module has a version of unfoldr (there just called
unfoldr) for non-empty lists that seems also to be useful when applied to
regular lists:

unfoldr1::(b -> (a, Maybe b)) -> b -> [a]
unfoldr1 f b= go b
  where
    go q = case f q of
      (a,may_b) -> a : maybe [] go may_b

My question is whether it is possible to write this function using the
usual unfoldr. I have the feeling there might be some way, but I just can't
see it.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/7c194860/attachment.html>

From roma at ro-che.info  Sat Aug  2 20:14:02 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 2 Aug 2014 23:14:02 +0300
Subject: [Haskell-cafe] typed tagless-final interpretation examples
 broken with recent ghc
In-Reply-To: <874mxudi7k.fsf@bluescreen303.nl>
References: <874mxudi7k.fsf@bluescreen303.nl>
Message-ID: <20140802201402.GA29421@sniper>

* Mathijs Kwik <mathijs at bluescreen303.nl> [2014-08-02 17:28:15+0200]
> I tried both ghc 7.6 and ghc 7.8, which both give a different kind of error
> message. It's a bit much and long to paste here though.

You could attach them as text files, or use http://lpaste.net/.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/c09f5145/attachment.sig>

From trebla at vex.net  Sat Aug  2 21:46:26 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sat, 02 Aug 2014 17:46:26 -0400
Subject: [Haskell-cafe] Does web-based email harm mailman lists?
In-Reply-To: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
References: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
Message-ID: <53DD5C32.20906@vex.net>

My points from the least immaterial to the most immaterial:

I am now agnostic to how people define the semantics of Reply-To, so I'm 
fine with Haskell-Cafe using it or not. This is because I have seen 
enough of different people having conflicting stakes on it.

I still have an opinion on Reply-To. This is because the modern headers 
List-Id, List-Post, etc. exist and are already in use. Haskell-Cafe has 
them, for example. They have taken off one burden from Reply-To; one 
fewer stakeholder group should be contending for it. Ideally, you should 
instead rally for all email clients to make use of List-Post. 
(Thunderbird does. It gives me a "reply to list" button.)

(Practically, we're talking about human society, it's hopeless.)

I am also on a mailing list that sets both List-Post and Reply-To to the 
mailing list address for the kick of it. This is because most members 
insist on using old clients, old enough to not know about List-Post at 
all. (And old enough to be text mode, that's why. They insist on text 
terminals.)

And lastly, to bring the mention of text terminals back to the mention 
of Haskell: a picture shared by someone in IRC #haskell-blah:
http://www.thenewsh.com/~newsham/x/art/terminal-ghci.png

(It occurs to me that it is today's powerful graphic cards that enable 
fast rendering of yesterday's distorted text!)

From allbery.b at gmail.com  Sun Aug  3 01:28:40 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 2 Aug 2014 21:28:40 -0400
Subject: [Haskell-cafe] Does web-based email harm mailman lists?
In-Reply-To: <53DD5C32.20906@vex.net>
References: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
 <53DD5C32.20906@vex.net>
Message-ID: <CAKFCL4VmW6ZQ_JTZgjCcSerDn5kZwJQf6Q3+aDowAGpCHcL3gQ@mail.gmail.com>

On Sat, Aug 2, 2014 at 5:46 PM, Albert Y. C. Lai <trebla at vex.net> wrote:

> And lastly, to bring the mention of text terminals back to the mention of
> Haskell: a picture shared by someone in IRC #haskell-blah:
> http://www.thenewsh.com/~newsham/x/art/terminal-ghci.png
>
> (It occurs to me that it is today's powerful graphic cards that enable
> fast rendering of yesterday's distorted text!)
>

Or even today's; somehow, I am thinking that's the display of an ATM. :)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/7d3a353a/attachment.html>

From bertram.felgenhauer at googlemail.com  Sun Aug  3 02:11:54 2014
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Sun, 3 Aug 2014 04:11:54 +0200
Subject: [Haskell-cafe] unfoldr with a little extra
In-Reply-To: <CAMgWh9tCvvfUaRVD4fWkxPJ9oEBwDHKvfAkrx+LontGuzntAVQ@mail.gmail.com>
References: <CAMgWh9umr2zgD8_t09GRZTLhRMjzrFJE-05-Zokuyst6kuF1gw@mail.gmail.com>
 <CAMgWh9tOQoWgsjaZkrqt5ywzXTwztzjusr_wDjmz7aDsZw+vuA@mail.gmail.com>
 <CAMgWh9uiDLsY8WCNhbnMAZfYgpfPwRD_LBabRNZSwLL1PgxXhQ@mail.gmail.com>
 <CAMgWh9tCvvfUaRVD4fWkxPJ9oEBwDHKvfAkrx+LontGuzntAVQ@mail.gmail.com>
Message-ID: <20140803021153.GC8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>

David Feuer wrote:
> unfoldr1::(b -> (a, Maybe b)) -> b -> [a]
> unfoldr1 f b= go b
>   where
>     go q = case f q of
>       (a,may_b) -> a : maybe [] go may_b
> 
> My question is whether it is possible to write this function using the
> usual unfoldr. I have the feeling there might be some way, but I just can't
> see it.

We need some common ground between f :: b -> (a, Maybe b) and the type
of the first argument of unfoldr, b -> Maybe (a, b); the best I can
see is (fmap f) :: Maybe b -> Maybe (a, Maybe b). So

  unfoldr1 f b = unfoldr (fmap f) (Just b)

Cheers,

Bertram

From mark.lentczner at gmail.com  Sun Aug  3 03:00:55 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sat, 2 Aug 2014 23:00:55 -0400
Subject: [Haskell-cafe] Haskell Platform 2014.2.0.0 Release Candidate 4
	(Windows only)
Message-ID: <CAAOoiFaVicxCjUATz0+bEFXpPJ_57xiOtoMsBAev9tTGbA3u_A@mail.gmail.com>

This is an update to the Windows RC2 candidates. These candidates fix three
problems with the installation scripts. The binary build of the packages
has not changed.

*Fixes:*

   - Fix the PATH to add the location where binaries are installed with
   "cabal install --global"
   - Fix the url shortcut that is installed, to point to the platform+ghc
   master indices, rather than just the ghc indices
   - Fix where a 32-bit HP installed on a 64-bit system was going

*Installers can be found here:*

   - HaskellPlatform-2014.2.0.0-i386-RC4-setup.exe
   <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-i386-RC4-setup.exe>
   - HaskellPlatform-2014.2.0.0-x86_64-RC4-setup.exe
   <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-x86_64-RC4-setup.exe>

- Mark

P.S.: You might have noticed that the server that hosted the RC files was
down intermittently yesterday and today. It suffered a double (!) disk
failure. It is back up with shiny new disks.

P.P.S: As always, for the reasonably wary:
shasum -a 256:
975e014d53cfdb84036889923d6e9598e4623baa9c69d53dc4d9372fe100cf95
 HaskellPlatform-2014.2.0.0-i386-RC4-setup.exe
05b39901cdc43de335583c461bcd77c0d8dd5765ab195ad387a0dc774a43bee2
 HaskellPlatform-2014.2.0.0-x86_64-RC4-setup.exe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140802/b3e098f9/attachment.html>

From michael at snoyman.com  Sun Aug  3 06:40:54 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 3 Aug 2014 09:40:54 +0300
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <20140801213029.GA8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
 <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
 <20140801213029.GA8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
Message-ID: <CAKA2Jg+4sHVtHxBU_4j2EjZ6iM+e-LfK+zcb34vjt=otRyn54A@mail.gmail.com>

On Sat, Aug 2, 2014 at 12:30 AM, Bertram Felgenhauer <
bertram.felgenhauer at googlemail.com> wrote:

> Carter Schonwald wrote:
> > I tried compiling your original codes with normal unsafePerformIO on ghc
> > 7.8.3, and I get the "B" result at -O0 and the "A" result at O1 and O2
> >
> > {-# LANGUAGE BangPatterns,  UnboxedTuples,MagicHash #-}
> >
> > import Data.ByteString.Internal (inlinePerformIO)
> > import qualified Data.Vector as V
> > import qualified Data.Vector.Mutable as VM
> >
> > import System.IO.Unsafe
> >
> > main :: IO ()
> > main = do
> >     vm <- VM.new 1
> >     VM.write vm 0 'A'
> >     !b<- return $! 'B'
> >     let !x = unsafePerformIO $! VM.write vm 0 b
> >     x `seq` (V.freeze vm >>= print)
>
> Note that the compiler sees through  !b<- return $! 'B', so it does
> not introduce a data dependency. Looking at the core, x is getting
> evaluated (writing 'B' to the array) before the writeArray# call
> resulting from VM.write vm 0 'A'.
>
> I'm not 100% sure that the compiler is within its rights for reordering
> code here; after all, writeArray# has a side effect, which will not
> be performed in the hypothetical case that evaluation of x diverges.
> But at least reordering effects is far less surprising than effects
> disappearing completely.
>
> [Michael Snoyman:]
> > > One last question on the GHC front, however. It *does* seem like
> there's
> > > still a bug in GHC here, since presumably case-ing on an unboxed tuple
> > > should force evaluation of both of its values.
>
> No, it should not. If it did,
>
>   main = return undefined >> print "Foo"
>
> would fail.
>
>
Ahh, good point, thanks.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/779f481c/attachment.html>

From david.feuer at gmail.com  Sun Aug  3 06:58:39 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 3 Aug 2014 02:58:39 -0400
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <CAKA2Jg+4sHVtHxBU_4j2EjZ6iM+e-LfK+zcb34vjt=otRyn54A@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
 <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
 <20140801213029.GA8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
 <CAKA2Jg+4sHVtHxBU_4j2EjZ6iM+e-LfK+zcb34vjt=otRyn54A@mail.gmail.com>
Message-ID: <CAMgWh9ss6ZE4Oe9zj4TZ+AnSeWqz4hooDRLiUGSZYvNGC7dV4w@mail.gmail.com>

Indeed unboxed tuples, unboxed vectors, and unboxed Ints are "unboxed"
in rather different ways. Unboxed vectors have no boxes inside of
them. Unboxed Ints have no boxes around them. Unboxed tuples ... I'm
not even sure why they're called that, but what they *really* are is a
mechanism for functions to return multiple values, a notion you may
have encountered if you've used Scheme. There are rather harsh
restrictions on their use to ensure that they work efficiently for
this purpose.

On Sun, Aug 3, 2014 at 2:40 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Sat, Aug 2, 2014 at 12:30 AM, Bertram Felgenhauer
> <bertram.felgenhauer at googlemail.com> wrote:
>>
>> Carter Schonwald wrote:
>> > I tried compiling your original codes with normal unsafePerformIO on ghc
>> > 7.8.3, and I get the "B" result at -O0 and the "A" result at O1 and O2
>> >
>> > {-# LANGUAGE BangPatterns,  UnboxedTuples,MagicHash #-}
>> >
>> > import Data.ByteString.Internal (inlinePerformIO)
>> > import qualified Data.Vector as V
>> > import qualified Data.Vector.Mutable as VM
>> >
>> > import System.IO.Unsafe
>> >
>> > main :: IO ()
>> > main = do
>> >     vm <- VM.new 1
>> >     VM.write vm 0 'A'
>> >     !b<- return $! 'B'
>> >     let !x = unsafePerformIO $! VM.write vm 0 b
>> >     x `seq` (V.freeze vm >>= print)
>>
>> Note that the compiler sees through  !b<- return $! 'B', so it does
>> not introduce a data dependency. Looking at the core, x is getting
>> evaluated (writing 'B' to the array) before the writeArray# call
>> resulting from VM.write vm 0 'A'.
>>
>> I'm not 100% sure that the compiler is within its rights for reordering
>> code here; after all, writeArray# has a side effect, which will not
>> be performed in the hypothetical case that evaluation of x diverges.
>> But at least reordering effects is far less surprising than effects
>> disappearing completely.
>>
>> [Michael Snoyman:]
>> > > One last question on the GHC front, however. It *does* seem like
>> > > there's
>> > > still a bug in GHC here, since presumably case-ing on an unboxed tuple
>> > > should force evaluation of both of its values.
>>
>> No, it should not. If it did,
>>
>>   main = return undefined >> print "Foo"
>>
>> would fail.
>>
>
> Ahh, good point, thanks.
>
> Michael
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From sebastian at spawnhost.de  Sun Aug  3 13:13:26 2014
From: sebastian at spawnhost.de (Sebastian Philipp)
Date: Sun, 03 Aug 2014 15:13:26 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
Message-ID: <53DE3576.6010401@spawnhost.de>

Hi Cafe,

Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
engine for Hackage packages, which allows you to search for functions,
data types and packages.

It is currently work in progress. Any feedback is greatly appreciated!

Hayoo uses Hunt <https://github.com/hunt-framework> for indexing and
searching, which is the successor of Holumbus. Hunt is a flexible,
lightweight search platform with a powerful query language and JSON API.

Example search requests are:

* Function names: map
<http://hayoo.fh-wedel.de/?query=map>

* Function signatures: (a->b)->f a->f b
<http://hayoo.fh-wedel.de/?query=%28a-%3Eb%29-%3Ef+a-%3Ef+b>

* Module names: Control.Loop
<http://hayoo.fh-wedel.de/?query=Control.Loop>

Have a look at the examples on <http://hayoo.fh-wedel.de/examples> for
some advances queries.

The old Hayoo and Holumbus are still online at
<http://holumbus-alt.fh-wedel.de/>

-- 
Sebastian Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/5e69323f/attachment.sig>

From allbery.b at gmail.com  Sun Aug  3 13:41:07 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 3 Aug 2014 09:41:07 -0400
Subject: [Haskell-cafe] Bad interaction of inlinePerformIO and mutable
	vectors
In-Reply-To: <CAMgWh9ss6ZE4Oe9zj4TZ+AnSeWqz4hooDRLiUGSZYvNGC7dV4w@mail.gmail.com>
References: <CAKA2JgLJbCWW--3DduooqBsv=jngu89Utb8dndysc9ydBdgkcA@mail.gmail.com>
 <53DA2A1C.3080103@gmail.com> <53DA5258.60509@gmail.com>
 <CAKA2JgKbBErAn=F4uc1-Z2bwHxx=0+zM9Ft9v7cN3C17mhBkHA@mail.gmail.com>
 <CAKA2JgLfhYz+f8s4oDVnO42pDGfbaW2hN4M=TBnSQkg0NSsRng@mail.gmail.com>
 <CAHYVw0yh+K2d5R=xvt=g7Q2J0NTGVs4y1ducXLFHUO6oGAR_9g@mail.gmail.com>
 <20140801213029.GA8496@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
 <CAKA2Jg+4sHVtHxBU_4j2EjZ6iM+e-LfK+zcb34vjt=otRyn54A@mail.gmail.com>
 <CAMgWh9ss6ZE4Oe9zj4TZ+AnSeWqz4hooDRLiUGSZYvNGC7dV4w@mail.gmail.com>
Message-ID: <CAKFCL4V6cwcmDOr3-Es0Z7DxCQn_ToJSNrV-vgDf2qsjTN7nrg@mail.gmail.com>

On Sun, Aug 3, 2014 at 2:58 AM, David Feuer <david.feuer at gmail.com> wrote:

> I'm
> not even sure why they're called that, but what they *really* are is a
> mechanism for functions to return multiple values
>

They are unboxed in a way similar to the way the others are: no constructor
in their internal representation. They *do* have an extra level of
indirection still, just not the constructor cell that normally goes with
it. (This is also why historically their use in GHC has been rather
restricted.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/f38efe35/attachment.html>

From doug at cs.dartmouth.edu  Sun Aug  3 14:39:56 2014
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 03 Aug 2014 10:39:56 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
 of createProcess
Message-ID: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>

>> I still think haskell is using screwy defaults for stdout buffering.

> Line buffered would be an inefficient default.  Stdout is fully buffered in
> c99 if it can be determined that it is not attached to a terminal.

Putting efficiency before efficacy is un-Haskellian. How can the required
determination be implemented?

Stdout may be attached to a terminal indirectly through a pipeline.
It may be "attached" through a file that another process is watching.
It may be attached to some other real-time device or system.

Buffering can cause unbounded delays in systems with sporadic input.
And it can cause deadlock in systems that employ feedback,
as most systems do. Terminals, for example, are unbuffered not  
merely because users are impatient, but more critically because
users are feedback agents.

Because the effects of buffering are not transparent, it would be 
wise to make it an optional optimization, not a default.

From allbery.b at gmail.com  Sun Aug  3 16:18:17 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 3 Aug 2014 12:18:17 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
Message-ID: <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>

On Sun, Aug 3, 2014 at 10:39 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Because the effects of buffering are not transparent, it would be
> wise to make it an optional optimization, not a default.
>

It's not just efficiency, it's also behaving compatibility with other
implementations. Or were you going to argue this with e.g. the ANSI C
committee too?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/cec1ec75/attachment.html>

From andrew.gibiansky at gmail.com  Sun Aug  3 16:33:06 2014
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Sun, 3 Aug 2014 09:33:06 -0700
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <53DE3576.6010401@spawnhost.de>
References: <53DE3576.6010401@spawnhost.de>
Message-ID: <CAF-LYK+q08c=Lk7OL77CSE0OLb1E485abrnzS_LV4OAXOGKMhg@mail.gmail.com>

Sebastian,

This looks great! I love the results for the example queries.

However, I have a few questions, which I think many people may share.
Namely, how is this different from Hoogle? For many of us, Hoogle is the
default tool, and has been thoroughly integrated into our workflow. What
differentiates Hayoo from Hoogle? Does it offer exactly the same service
but with a few different minor choices? (From a very brief glance, I prefer
the output I get from Hayoo, but without having used it extensively, I
don't know how it really compares.) I think that whatever answer you have
to this, it may be good to put on the "About" section of the Hayoo website.

(If the answer is is "it's the same but better in minor ways", that's also
perfectly alright. Incremental improvement is important. Not everything has
to be groundbreakingly different with strong differentiating points.)

Anyway, don't take any of these questions as criticism -- I'm a huge fan of
what I see here and will try to use Hayoo instead of Hoogle to see how it
compares in practice.

Best,

Andrew


On Sun, Aug 3, 2014 at 6:13 AM, Sebastian Philipp <sebastian at spawnhost.de>
wrote:

> Hi Cafe,
>
> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
> engine for Hackage packages, which allows you to search for functions,
> data types and packages.
>
> It is currently work in progress. Any feedback is greatly appreciated!
>
> Hayoo uses Hunt <https://github.com/hunt-framework> for indexing and
> searching, which is the successor of Holumbus. Hunt is a flexible,
> lightweight search platform with a powerful query language and JSON API.
>
> Example search requests are:
>
> * Function names: map
> <http://hayoo.fh-wedel.de/?query=map>
>
> * Function signatures: (a->b)->f a->f b
> <http://hayoo.fh-wedel.de/?query=%28a-%3Eb%29-%3Ef+a-%3Ef+b>
>
> * Module names: Control.Loop
> <http://hayoo.fh-wedel.de/?query=Control.Loop>
>
> Have a look at the examples on <http://hayoo.fh-wedel.de/examples> for
> some advances queries.
>
> The old Hayoo and Holumbus are still online at
> <http://holumbus-alt.fh-wedel.de/>
>
> --
> Sebastian Philipp
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/ca1c02f7/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Sun Aug  3 16:41:57 2014
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sun, 03 Aug 2014 18:41:57 +0200
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
 of createProcess
In-Reply-To: <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
 <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
Message-ID: <53DE6655.7080809@unicaen.fr>


Brandon Allbery:
> On Sun, Aug 3, 2014 at 10:39 AM, Doug McIlroy <doug at cs.dartmouth.edu 
> <mailto:doug at cs.dartmouth.edu>> wrote:
>
>     Because the effects of buffering are not transparent, it would be
>     wise to make it an optional optimization, not a default.
>
>
> It's not just efficiency, it's also behaving compatibility with other 
> implementations. Or were you going to argue this with e.g. the ANSI C 
> committee too?

I admit that I didn't follow this thread, so I might have skipped 
something, but ...
Is Brandon Albery suggesting that Haskell should progress in the 
direction  that makes it as compatible as possible with ANSI C?


Jerzy Karczmarczuk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/912038b0/attachment.html>

From tim at blitzcode.net  Sun Aug  3 12:52:16 2014
From: tim at blitzcode.net (Tim C. Schroeder)
Date: Sun, 3 Aug 2014 14:52:16 +0200
Subject: [Haskell-cafe] http://www.downforeveryoneorjustme.com/haskell.org
Message-ID: <6A1F6CD9-A0BC-4920-B14C-C8B5A1CFEC6F@blitzcode.net>

Thinks always break on the weekend, don?t they! Apologies if this is a scheduled outtake.

In the meantime, there?s fortunately a Haddock mirror on http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ ;-)

Cheers,
Tim

From allbery.b at gmail.com  Sun Aug  3 17:48:05 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 3 Aug 2014 13:48:05 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <53DE6655.7080809@unicaen.fr>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
 <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
 <53DE6655.7080809@unicaen.fr>
Message-ID: <CAKFCL4X+TikLBJojkcpAwzYRGtz0xSfz5XNmNxcdPSLvWRtFTA@mail.gmail.com>

On Sun, Aug 3, 2014 at 12:41 PM, Jerzy Karczmarczuk <
jerzy.karczmarczuk at unicaen.fr> wrote:

> I admit that I didn't follow this thread, so I might have skipped
> something, but ...
> Is Brandon Albery suggesting that Haskell should progress in the
> direction  that makes it as compatible as possible with ANSI C?
>

Brandon Allbery is suggesting that things that promote interoperability are
a good idea. I'm sorry you find this an unpalatable notion; perhaps Haskell
should forcibly reject all conceivable real world usage in order to
properly meet your expectations. (Note that this may well include the usage
that spawned this sorry thread; presumably a desire for interaction between
subprocesses is not because it's operating in a hermetically sealed
compartment isolated from the rest of the world.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/cf414e5e/attachment.html>

From elliot.robinson at argiopetech.com  Sun Aug  3 18:43:51 2014
From: elliot.robinson at argiopetech.com (Elliot Robinson)
Date: Sun, 3 Aug 2014 14:43:51 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child processof
	createProcess
In-Reply-To: <20140802075447.2664893C2E@mail.avvanta.com>
References: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
 <20140802075447.2664893C2E@mail.avvanta.com>
Message-ID: <CAG7kECPww_f9eqKspqX7S45gT5=zu02J3D0sFeDmoR37_4Ptqw@mail.gmail.com>

On Sat, Aug 2, 2014 at 3:54 AM, Donn Cave <donn at avvanta.com> wrote:

> Handles are for buffered I/O.


If this is the case, why is NoBuffering provided? Why does the
documentation for Handle explicitly mention non-existent and zero-length
buffers? If Handles are the standard cross-platform interface to buffered
file IO, what is the standard cross-platform interface to unbuffered IO
(output, specifically, since input is technically always at least 1 byte
buffered)?

---
Elliot Robinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/c18674f8/attachment.html>

From allbery.b at gmail.com  Sun Aug  3 19:08:39 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 3 Aug 2014 15:08:39 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child processof
	createProcess
In-Reply-To: <CAG7kECPww_f9eqKspqX7S45gT5=zu02J3D0sFeDmoR37_4Ptqw@mail.gmail.com>
References: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
 <20140802075447.2664893C2E@mail.avvanta.com>
 <CAG7kECPww_f9eqKspqX7S45gT5=zu02J3D0sFeDmoR37_4Ptqw@mail.gmail.com>
Message-ID: <CAKFCL4U-o4cBHo81oKsS8rB+imAbD7s=Eibehj2i+UzPQ7Xc-Q@mail.gmail.com>

On Sun, Aug 3, 2014 at 2:43 PM, Elliot Robinson <
elliot.robinson at argiopetech.com> wrote:

> On Sat, Aug 2, 2014 at 3:54 AM, Donn Cave <donn at avvanta.com> wrote:
>
>> Handles are for buffered I/O.
>
>
> If this is the case, why is NoBuffering provided? Why does the
> documentation for Handle explicitly mention non-existent and zero-length
> buffers? If Handles are the standard cross-platform interface to buffered
> file IO, what is the standard cross-platform interface to unbuffered IO
> (output, specifically, since input is technically always at least 1 byte
> buffered)?
>

Handles provide a non-buffered interface, but often if you truly need
unbuffered I/O you will be better suited by the platform's primitive
operations; for which abstractions that enable some kind of reasonably
platform independent interface may well cancel out the advantages of
unbuffered I/O for those cases.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/1930f51d/attachment.html>

From alan.zimm at gmail.com  Sun Aug  3 19:27:05 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 3 Aug 2014 21:27:05 +0200
Subject: [Haskell-cafe] "Standardising" Haskell AST for tooling
Message-ID: <CANma=H-eJvCqNbst7Y9e-1dd-==gR8JiNRxHFfS-182YOm-i=Q@mail.gmail.com>

Hi all

I am looking at updating HaRe for GHC 7.8.3, and I am fighting my way
through the AST changes.

One of the things I have had at the back of my mind for a while is to use
something like Kure universes or more generally lens to provide a set of
isomorphisms from the various flavours of AST into some kind of
standardised internal representation, allowing easier tool manipulation.

This could potentially decouple the tools from the specific
compiler/analyzer, so they could work across GHC 7.6.x, GHC 7.8.x,
haskell-src-exts, haste, etc..

Obviously there would be limitations to this where an advance in the
language brings in new features, but a lot of useful tool work can be done
that does not touch the new stuff.

I don't know if anything similar is planned in either ghc-server or another
toolchain.

My haskell-token-utils is a first limited attempt to bring source code
round tripping to a variety of backends, but a more general solution to the
AST phase would help tooling in general

So, is this worth doing? Is it being done already, or planned?


Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/2037a775/attachment.html>

From sebastian at spawnhost.de  Sun Aug  3 19:28:47 2014
From: sebastian at spawnhost.de (Sebastian Philipp)
Date: Sun, 03 Aug 2014 21:28:47 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <CAF-LYK+q08c=Lk7OL77CSE0OLb1E485abrnzS_LV4OAXOGKMhg@mail.gmail.com>
References: <53DE3576.6010401@spawnhost.de>
 <CAF-LYK+q08c=Lk7OL77CSE0OLb1E485abrnzS_LV4OAXOGKMhg@mail.gmail.com>
Message-ID: <53DE8D6F.4090801@spawnhost.de>

Hi Andrew,

the project goal is the same as Hoogle: to provide a search machine for
Hackage documentations. The main reasons for using Hayoo are:

* To provide a completion for search queries
* Get a direct link to the sources on Hackage
* Advanced queries, like searching for packages by Author:
<http://hayoo.fh-wedel.de/?query=Andrew+Gibiansky>
 or searching for package modules:
<http://hayoo.fh-wedel.de/?query=package%3A%21%27ghc-parser%27%20type%3A%21module>
* and Hayoo searches the whole Hackage.

Although, Hoogle has a better signature search.

Sebastian



Am 03.08.2014 um 18:33 schrieb Andrew Gibiansky:
> Sebastian,
> 
> This looks great! I love the results for the example queries.
> 
> However, I have a few questions, which I think many people may share.
> Namely, how is this different from Hoogle? For many of us, Hoogle is the
> default tool, and has been thoroughly integrated into our workflow. What
> differentiates Hayoo from Hoogle? Does it offer exactly the same service
> but with a few different minor choices? (From a very brief glance, I prefer
> the output I get from Hayoo, but without having used it extensively, I
> don't know how it really compares.) I think that whatever answer you have
> to this, it may be good to put on the "About" section of the Hayoo website.
> 
> (If the answer is is "it's the same but better in minor ways", that's also
> perfectly alright. Incremental improvement is important. Not everything has
> to be groundbreakingly different with strong differentiating points.)
> 
> Anyway, don't take any of these questions as criticism -- I'm a huge fan of
> what I see here and will try to use Hayoo instead of Hoogle to see how it
> compares in practice.
> 
> Best,
> 
> Andrew
> 
> 
> On Sun, Aug 3, 2014 at 6:13 AM, Sebastian Philipp <sebastian at spawnhost.de>
> wrote:
> 
>> Hi Cafe,
>>
>> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
>> engine for Hackage packages, which allows you to search for functions,
>> data types and packages.
>>
>> It is currently work in progress. Any feedback is greatly appreciated!
>>
>> Hayoo uses Hunt <https://github.com/hunt-framework> for indexing and
>> searching, which is the successor of Holumbus. Hunt is a flexible,
>> lightweight search platform with a powerful query language and JSON API.
>>
>> Example search requests are:
>>
>> * Function names: map
>> <http://hayoo.fh-wedel.de/?query=map>
>>
>> * Function signatures: (a->b)->f a->f b
>> <http://hayoo.fh-wedel.de/?query=%28a-%3Eb%29-%3Ef+a-%3Ef+b>
>>
>> * Module names: Control.Loop
>> <http://hayoo.fh-wedel.de/?query=Control.Loop>
>>
>> Have a look at the examples on <http://hayoo.fh-wedel.de/examples> for
>> some advances queries.
>>
>> The old Hayoo and Holumbus are still online at
>> <http://holumbus-alt.fh-wedel.de/>
>>
>> --
>> Sebastian Philipp
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
> 


-- 
Sebastian Philipp

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

From elliot.robinson at argiopetech.com  Sun Aug  3 20:05:38 2014
From: elliot.robinson at argiopetech.com (Elliot Robinson)
Date: Sun, 3 Aug 2014 16:05:38 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child processof
	createProcess
In-Reply-To: <CAKFCL4U-o4cBHo81oKsS8rB+imAbD7s=Eibehj2i+UzPQ7Xc-Q@mail.gmail.com>
References: <CAG7kECNLNFO6tqhjpVn5NBwwH9qZhUtmF5zXOMDv-JTpb54UUQ@mail.gmail.com>
 <20140802075447.2664893C2E@mail.avvanta.com>
 <CAG7kECPww_f9eqKspqX7S45gT5=zu02J3D0sFeDmoR37_4Ptqw@mail.gmail.com>
 <CAKFCL4U-o4cBHo81oKsS8rB+imAbD7s=Eibehj2i+UzPQ7Xc-Q@mail.gmail.com>
Message-ID: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>

On Sun, Aug 3, 2014 at 3:08 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sun, Aug 3, 2014 at 2:43 PM, Elliot Robinson <
> elliot.robinson at argiopetech.com> wrote:
>
>> On Sat, Aug 2, 2014 at 3:54 AM, Donn Cave <donn at avvanta.com> wrote:
>>
>>> Handles are for buffered I/O.
>>
>>
>> If this is the case, why is NoBuffering provided? Why does the
>> documentation for Handle explicitly mention non-existent and zero-length
>> buffers? If Handles are the standard cross-platform interface to buffered
>> file IO, what is the standard cross-platform interface to unbuffered IO
>> (output, specifically, since input is technically always at least 1 byte
>> buffered)?
>>
>
> Handles provide a non-buffered interface, but often if you truly need
> unbuffered I/O you will be better suited by the platform's primitive
> operations; for which abstractions that enable some kind of reasonably
> platform independent interface may well cancel out the advantages of
> unbuffered I/O for those cases.
>

As a platform-specific optimization, this makes total sense. Most of the
people who need this optimization know they need it. My fear is that
offering "handles are for buffered I/O" (and statements like it) as general
case rules leads to the "I'm new to <field> and I'm using System.Posix.IO
for unbuffered IO because Handles aren't good for that, and now my program
doesn't compile on <non-Posix OS>" ilk of Haskell-Cafe/SO questions.

---
Elliot Robinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/2e11de34/attachment.html>

From ok at cs.otago.ac.nz  Sun Aug  3 22:31:26 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Mon, 4 Aug 2014 10:31:26 +1200
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
 of createProcess
In-Reply-To: <53DE6655.7080809@unicaen.fr>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
 <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
 <53DE6655.7080809@unicaen.fr>
Message-ID: <54a2094481c9e2b9a1267b29c1ec1d68.squirrel@chasm.otago.ac.nz>

I find the idea of buffering as an optional optimisation
theoretically nice but practically, not so much.  I am
sick of having to tell students "Java does not buffer by
default, it is up to YOU to use BufferedReader and/or
BufferedWriter if you do not want I/O to be catastrophically
slow".




From allbery.b at gmail.com  Sun Aug  3 22:35:34 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 3 Aug 2014 18:35:34 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <54a2094481c9e2b9a1267b29c1ec1d68.squirrel@chasm.otago.ac.nz>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
 <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
 <53DE6655.7080809@unicaen.fr>
 <54a2094481c9e2b9a1267b29c1ec1d68.squirrel@chasm.otago.ac.nz>
Message-ID: <CAKFCL4U2pGsS0uz3ZCbL28dMJYfayLXQYRZSaNun7x_nz8z1cA@mail.gmail.com>

On Sun, Aug 3, 2014 at 6:31 PM, <ok at cs.otago.ac.nz> wrote:

> "Java does not buffer by
> default, it is up to YOU to use BufferedReader and/or
> BufferedWriter if you do not want I/O to be catastrophically
> slow".
>

Pretty much, yes. I'd forgotten that particular Java misfeature,
particularly since everyone else who'd considered changing the default
learned from the Java experience instead of repeating it.

(Granted, Java is something of a pessimal case.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140803/fbf42c53/attachment.html>

From amindfv at gmail.com  Mon Aug  4 02:47:21 2014
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 3 Aug 2014 22:47:21 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child process
	of createProcess
In-Reply-To: <CAKFCL4X+TikLBJojkcpAwzYRGtz0xSfz5XNmNxcdPSLvWRtFTA@mail.gmail.com>
References: <201408031439.s73EduvX032577@coolidge.cs.dartmouth.edu>
 <CAKFCL4UuujQq9GMYcqOXix4o2=GwgN15YCUn6qPh3xonfbtpSg@mail.gmail.com>
 <53DE6655.7080809@unicaen.fr>
 <CAKFCL4X+TikLBJojkcpAwzYRGtz0xSfz5XNmNxcdPSLvWRtFTA@mail.gmail.com>
Message-ID: <30A50F00-C5D4-44D7-84C0-482B1161A08D@gmail.com>

> I'm sorry you find this an unpalatable notion; perhaps Haskell should forcibly reject all conceivable real world usage in order to properly meet your expectations.

Take it down a notch, guys. We're usually very good at being a place where outsiders can be confident their (coherent) questions and ideas will be treated respectfully. If they can't be, many people with good ideas will stay silent or go elsewhere.

Tom



From amindfv at gmail.com  Mon Aug  4 02:50:56 2014
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Sun, 3 Aug 2014 22:50:56 -0400
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <53DE8D6F.4090801@spawnhost.de>
References: <53DE3576.6010401@spawnhost.de>
 <CAF-LYK+q08c=Lk7OL77CSE0OLb1E485abrnzS_LV4OAXOGKMhg@mail.gmail.com>
 <53DE8D6F.4090801@spawnhost.de>
Message-ID: <4760F57A-4725-4D48-8B53-7A49A8727CA0@gmail.com>

The fact that it searches all of hackage is the primary distinction, imo.

Tom

El Aug 3, 2014, a las 15:28, Sebastian Philipp <sebastian at spawnhost.de> escribi?:

> Hi Andrew,
> 
> the project goal is the same as Hoogle: to provide a search machine for
> Hackage documentations. The main reasons for using Hayoo are:
> 
> * To provide a completion for search queries
> * Get a direct link to the sources on Hackage
> * Advanced queries, like searching for packages by Author:
> <http://hayoo.fh-wedel.de/?query=Andrew+Gibiansky>
> or searching for package modules:
> <http://hayoo.fh-wedel.de/?query=package%3A%21%27ghc-parser%27%20type%3A%21module>
> * and Hayoo searches the whole Hackage.
> 
> Although, Hoogle has a better signature search.
> 
> Sebastian
> 
> 
> 
> Am 03.08.2014 um 18:33 schrieb Andrew Gibiansky:
>> Sebastian,
>> 
>> This looks great! I love the results for the example queries.
>> 
>> However, I have a few questions, which I think many people may share.
>> Namely, how is this different from Hoogle? For many of us, Hoogle is the
>> default tool, and has been thoroughly integrated into our workflow. What
>> differentiates Hayoo from Hoogle? Does it offer exactly the same service
>> but with a few different minor choices? (From a very brief glance, I prefer
>> the output I get from Hayoo, but without having used it extensively, I
>> don't know how it really compares.) I think that whatever answer you have
>> to this, it may be good to put on the "About" section of the Hayoo website.
>> 
>> (If the answer is is "it's the same but better in minor ways", that's also
>> perfectly alright. Incremental improvement is important. Not everything has
>> to be groundbreakingly different with strong differentiating points.)
>> 
>> Anyway, don't take any of these questions as criticism -- I'm a huge fan of
>> what I see here and will try to use Hayoo instead of Hoogle to see how it
>> compares in practice.
>> 
>> Best,
>> 
>> Andrew
>> 
>> 
>> On Sun, Aug 3, 2014 at 6:13 AM, Sebastian Philipp <sebastian at spawnhost.de>
>> wrote:
>> 
>>> Hi Cafe,
>>> 
>>> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
>>> engine for Hackage packages, which allows you to search for functions,
>>> data types and packages.
>>> 
>>> It is currently work in progress. Any feedback is greatly appreciated!
>>> 
>>> Hayoo uses Hunt <https://github.com/hunt-framework> for indexing and
>>> searching, which is the successor of Holumbus. Hunt is a flexible,
>>> lightweight search platform with a powerful query language and JSON API.
>>> 
>>> Example search requests are:
>>> 
>>> * Function names: map
>>> <http://hayoo.fh-wedel.de/?query=map>
>>> 
>>> * Function signatures: (a->b)->f a->f b
>>> <http://hayoo.fh-wedel.de/?query=%28a-%3Eb%29-%3Ef+a-%3Ef+b>
>>> 
>>> * Module names: Control.Loop
>>> <http://hayoo.fh-wedel.de/?query=Control.Loop>
>>> 
>>> Have a look at the examples on <http://hayoo.fh-wedel.de/examples> for
>>> some advances queries.
>>> 
>>> The old Hayoo and Holumbus are still online at
>>> <http://holumbus-alt.fh-wedel.de/>
>>> 
>>> --
>>> Sebastian Philipp
>>> 
>>> 
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> -- 
> Sebastian Philipp
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From donn at avvanta.com  Mon Aug  4 04:25:45 2014
From: donn at avvanta.com (Donn Cave)
Date: Sun,  3 Aug 2014 21:25:45 -0700 (PDT)
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child
	processofcreateProcess
In-Reply-To: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>
References: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>
Message-ID: <20140804042545.0A267F3935@mail.avvanta.com>

quoth Elliot Robinson <elliot.robinson at argiopetech.com>,

> As a platform-specific optimization, this makes total sense. Most of the
> people who need this optimization know they need it. My fear is that
> offering "handles are for buffered I/O" (and statements like it) as general
> case rules leads to the "I'm new to <field> and I'm using System.Posix.IO
> for unbuffered IO because Handles aren't good for that, and now my program
> doesn't compile on <non-Posix OS>" ilk of Haskell-Cafe/SO questions.

Your fears are misplaced.  No one is going to do that, ever.  Please
bear in mind that we're talking about a Posix Fd produced by another
Posix terminal function.  That is where you will see one programmer
after another feed this Fd into a Handle, under the mistaken impression
that it's the only legit way to do I/O on it in Haskell, and then have
various problems that we're talking about.  When it's for buffered I/O,
then it makes sense, otherwise it's probably an error.

To address J.K.'s (lest I misspell) probably ironic question seriously,
why I certainly say Haskell should strive to be as compatible as possible
with ANSI C, whatever Mr. Allbery may think.  Gratuitous difference in
functionality that's clearly based on C I/O would benefit no one.

	Donn

From allbery.b at gmail.com  Mon Aug  4 04:53:53 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 4 Aug 2014 00:53:53 -0400
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child
	processofcreateProcess
In-Reply-To: <20140804042545.0A267F3935@mail.avvanta.com>
References: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>
 <20140804042545.0A267F3935@mail.avvanta.com>
Message-ID: <CAKFCL4VE6Q64-WZ=o-oe9Z03veTC3JZP=krqOEgyF1BSH-2Nzg@mail.gmail.com>

On Mon, Aug 4, 2014 at 12:25 AM, Donn Cave <donn at avvanta.com> wrote:

> To address J.K.'s (lest I misspell) probably ironic question seriously,
> why I certainly say Haskell should strive to be as compatible as possible
> with ANSI C, whatever Mr. Allbery may think.  Gratuitous difference in
> functionality that's clearly based on C I/O would benefit no one.
>

I *don't* fully agree with this, just because ANSI C is partly in the
business of ensuring that ancient programs still behave to some extent, and
ancient programs often use buffered I/O in situations where it isn't ideal
but was typically better than unbuffered on ancient PDP11s, or vice versa.
:) (And often don't use line buffering, as --- if the program is old enough
--- it may predate it.)

That said, on many platforms pipes kinda give you a taste of that
environment; as IPC goes, they're fairly slow, so buffered I/O is often a
visibly faster option. (Which is why there are lighter but more complex or
less documented / characterized IPC mechanisms around on various Unix-like
systems.) And I do mean "visibly"; it's still, even on modern hardware, not
*that* difficult to end up with programs where you can see visible pauses
between emitted characters if you disable buffering completely, whereas
even with line buffering the program both loses the pauses and takes less
time to run.

But in any case, my main grump here is that anything that makes it harder
(or non-viably slower) to interface Haskell with other programs makes it
harder to use Haskell in practice. Stringing together programs with pipes
is still common in the unix world (despite the efforts of e.g. the Gnome
devs...) and Haskell defaulting to unbuffered (or line buffered, in the
case of short lines) I/O on pipes would be unfortunate.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140804/a101faff/attachment.html>

From apfelmus at quantentunnel.de  Mon Aug  4 10:28:06 2014
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Mon, 04 Aug 2014 12:28:06 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <53DE3576.6010401@spawnhost.de>
References: <53DE3576.6010401@spawnhost.de>
Message-ID: <lrnn7n$prh$1@ger.gmane.org>

Sebastian Philipp wrote:

> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
> engine for Hackage packages, which allows you to search for functions,
> data types and packages.
> 
> It is currently work in progress. Any feedback is greatly appreciated!

Thanks for this fabulous search engine that covers all of hackage! But I 
have feedback. :)

Yesterday, I was trying to search for the operator (^?!), but no 
results. Today, I found that I have to put it in quotes, so the 
following queries work: "(^?!)", "^?!". I guess that one of the three 
symbols has some special meaning in the query language, but would it be 
possible to change the lexical syntax to match Haskell's syntax? I.e. 
any valid Haskell identifier is also a valid search query. (I'm happy to 
put parentheses around operators.)

The inline Haddock documentation is great, but at the moment, the 
hyperlinks don't seem to work. The link

<http://hayoo.fh-wedel.de/?query=%28%28name%3A%21Fold%20package%3A%21lens%20module%3A%21%27Control.Lens.Fold%27%29%5ESC%20%7BunScore%20%3D%20100.0%7D%29%20OR%20%28%28name%3A%21Fold%20package%3A%21lens%29%5ESC%20%7BunScore%20%3D%2010.0%7D%29%20OR%20name%3A%21Fold>

gives an error message

   Internal Error: (line 1, column 57): unexpected "S" expecting digit


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From nicolas at incubaid.com  Mon Aug  4 10:35:21 2014
From: nicolas at incubaid.com (Nicolas Trangez)
Date: Mon, 04 Aug 2014 12:35:21 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <lrnn7n$prh$1@ger.gmane.org>
References: <53DE3576.6010401@spawnhost.de> <lrnn7n$prh$1@ger.gmane.org>
Message-ID: <1407148521.27138.8.camel@chi.nicolast.be>

On Mon, 2014-08-04 at 12:28 +0200, Heinrich Apfelmus wrote:
> Sebastian Philipp wrote:
> 
> > Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
> > engine for Hackage packages, which allows you to search for functions,
> > data types and packages.
> > 
> > It is currently work in progress. Any feedback is greatly appreciated!
> 
> Thanks for this fabulous search engine that covers all of hackage! But I 
> have feedback. :)
> 
> Yesterday, I was trying to search for the operator (^?!), but no 
> results. Today, I found that I have to put it in quotes, so the 
> following queries work: "(^?!)", "^?!". I guess that one of the three 
> symbols has some special meaning in the query language, but would it be 
> possible to change the lexical syntax to match Haskell's syntax? I.e. 
> any valid Haskell identifier is also a valid search query. (I'm happy to 
> put parentheses around operators.)

I experienced something similar/related by simply querying for
"foldl'" (without the quotes):

> Internal Error: (line 1, column 6): unexpected '\'' expecting "\\",
"^", space, white space, "++", "NEAR", "FOLLOW", "AND", "OR" or end of
input

The query succeeds when using "foldl'" with the quotes.

I'm not sure whether it's intentional for those queries to fail, but it
feels counter-intuitive.

Anyway, next to that: thanks for your work on Hayoo!

Nicolas


From jerzy.karczmarczuk at unicaen.fr  Mon Aug  4 11:25:19 2014
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Mon, 04 Aug 2014 13:25:19 +0200
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child
	processofcreateProcess
In-Reply-To: <20140804042545.0A267F3935@mail.avvanta.com>
References: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>
 <20140804042545.0A267F3935@mail.avvanta.com>
Message-ID: <53DF6D9F.5010205@unicaen.fr>


Le 04/08/2014 06:25, Donn Cave a ?crit :
> To address J.K.'s (lest I misspell) probably ironic question seriously,
> why I certainly say Haskell should strive to be as compatible as possible
> with ANSI C, whatever Mr. Allbery may think.  Gratuitous difference in
> functionality that's clearly based on C I/O would benefit no one.

Thank you. In fact, B.A. [probably] thinks that this compatibility is 
important, while I don't care so much.
Now, ironic or not ironic: I am afraid that your usage of: "gratuitous 
difference in functionality" is not correct. The languages are 
different, their /typical/ domains of application are not the same, and 
if somebody wants really to construct hybrid applications, I see no 
reason to mix-up Haskell and C within the same "niche": interfacing or 
sub-process creation, etc. Use one, or the other, why not?
I think that insisting on the Frankesteinism is "gratuitous".

Concerning buffering, when somebody (Richard O'K. presumably) says :
> I am sick of having to tell students "Java does not buffer by
> default, it is up to YOU to use BufferedReader and/or
> BufferedWriter if you do not want I/O to be catastrophically
> slow".
I would say that in many circumstances (Java EE services, etc.) this is 
far from being catastrophically slow.

The best.

Jerzy Karczmarczuk
Caen, France


From sebastian at spawnhost.de  Mon Aug  4 12:12:24 2014
From: sebastian at spawnhost.de (Sebastian Philipp)
Date: Mon, 04 Aug 2014 14:12:24 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <lrnn7n$prh$1@ger.gmane.org>
References: <53DE3576.6010401@spawnhost.de> <lrnn7n$prh$1@ger.gmane.org>
Message-ID: <53DF78A8.10408@spawnhost.de>

Am 04.08.2014 um 12:28 schrieb Heinrich Apfelmus:
> Sebastian Philipp wrote:
> 
>> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
>> engine for Hackage packages, which allows you to search for functions,
>> data types and packages.
>>
>> It is currently work in progress. Any feedback is greatly appreciated!
> 
> Yesterday, I was trying to search for the operator (^?!), but no
> results. Today, I found that I have to put it in quotes, so the
> following queries work: "(^?!)", "^?!". I guess that one of the three
> symbols has some special meaning in the query language, but would it be
> possible to change the lexical syntax to match Haskell's syntax? I.e.
> any valid Haskell identifier is also a valid search query. (I'm happy to
> put parentheses around operators.)
(^?!) and foldl' are indeed problematic. Thanks for finding the bug.
This will take a while, because we have to modify the query language.

> 
> The inline Haddock documentation is great, but at the moment, the
> hyperlinks don't seem to work. The link
> 
> <http://hayoo.fh-wedel.de/?query=%28%28name%3A%21Fold%20package%3A%21lens%20module%3A%21%27Control.Lens.Fold%27%29%5ESC%20%7BunScore%20%3D%20100.0%7D%29%20OR%20%28%28name%3A%21Fold%20package%3A%21lens%29%5ESC%20%7BunScore%20%3D%2010.0%7D%29%20OR%20name%3A%21Fold>
> 
That's now fixed ans will be online shortly.

Regards,

Sebastian Philipp


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Aug  4 14:07:10 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 4 Aug 2014 15:07:10 +0100
Subject: [Haskell-cafe] Functional programming and William Lawvere's
 notion of "variable sets"(vs topos of "static sets") in a Topos ...
In-Reply-To: <CA+0XtC-1x8M-=nYcHe6v57SpxLFYqj38Y6b2ORxpHGW-RdcXiQ@mail.gmail.com>
References: <CA+0XtC-1x8M-=nYcHe6v57SpxLFYqj38Y6b2ORxpHGW-RdcXiQ@mail.gmail.com>
Message-ID: <20140804140710.GV1587@henry>

On Sat, Aug 02, 2014 at 01:28:41AM -0500, Vasili I. Galchin wrote:
> In Haskell( and other FPLs ..  ) aren't "pure" computations just over the
> topos of abstract sets and "mutable" /"time-varying/stateful" computations
> aren't just "variable sets" (i.e.  a functor over a discrete
> preset-poset)??

If you think this is the case could you please make an exposition of the
correspondance.  It's unlikely anyone here will be able to understand your
conclusion without such.

Tom

From sean at functionaljobs.com  Mon Aug  4 16:00:02 2014
From: sean at functionaljobs.com (Functional Jobs)
Date: Mon, 4 Aug 2014 12:00:02 -0400
Subject: [Haskell-cafe] New Functional Programming Job Opportunities
Message-ID: <53dfae03227cd@functionaljobs.com>

Here are some functional programming job opportunities that were posted
recently:

Pragmatic Haskell Developer at Anchor Systems
http://functionaljobs.com/jobs/8729-pragmatic-haskell-developer-at-anchor-systems

Cheers,
Sean Murphy
FunctionalJobs.com


From me at khanson.io  Mon Aug  4 17:40:40 2014
From: me at khanson.io (Kyle Hanson)
Date: Mon, 4 Aug 2014 10:40:40 -0700
Subject: [Haskell-cafe] [ANN] StrappedTemplates - general purpose templates
Message-ID: <CAMJUouCLAgU-c5pSmCiE0=O8a2quVm=tCWOKQUYctTA3bA7sBg@mail.gmail.com>

Hello all,

I found that I wasn't quite satisfied by the template offerings (Heist,
Hastache, Shakespearean, etc..) of Haskell, so I built my own. The goal is
to have simple syntax that non-haskellers would be comfortable using,
resembles templates found in other languages (Jinja, Django, etc) and an
interface to render them that I don't have to think very hard to use.

Features include inheritance, logic, includes, functions, and relatively
speedy rendering (much faster than interpreted templates like Heist-I and
Hastache) .

Its very much a work in progress, but I felt that it was enough for an
initial release and get general feedback on it.  Comments are appreciated.

One thing that I want to improve is how functions are handled in the
template and in the "InputBucket", extend the syntax to allow you to do
more inside the template and be able to define your own block functions.
These will probably be added next major release.

http://hackage.haskell.org/package/StrappedTemplates
https://github.com/hansonkd/StrappedTemplates

Thanks!
Kyle Hanson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140804/0ae11e78/attachment.html>

From welcometothechango at gmail.com  Mon Aug  4 17:58:15 2014
From: welcometothechango at gmail.com (Ezequiel Alvarez)
Date: Mon, 4 Aug 2014 14:58:15 -0300
Subject: [Haskell-cafe] [ANN] StrappedTemplates - general purpose
	templates
In-Reply-To: <CAMJUouCLAgU-c5pSmCiE0=O8a2quVm=tCWOKQUYctTA3bA7sBg@mail.gmail.com>
References: <CAMJUouCLAgU-c5pSmCiE0=O8a2quVm=tCWOKQUYctTA3bA7sBg@mail.gmail.com>
Message-ID: <CAFVEAce98LYZ6mY3hjRao6gtEsfLkb5FKjpHcHcmnNKVzWiLLg@mail.gmail.com>

Very nice!


On Mon, Aug 4, 2014 at 2:40 PM, Kyle Hanson <me at khanson.io> wrote:

> Hello all,
>
> I found that I wasn't quite satisfied by the template offerings (Heist,
> Hastache, Shakespearean, etc..) of Haskell, so I built my own. The goal is
> to have simple syntax that non-haskellers would be comfortable using,
> resembles templates found in other languages (Jinja, Django, etc) and an
> interface to render them that I don't have to think very hard to use.
>
> Features include inheritance, logic, includes, functions, and relatively
> speedy rendering (much faster than interpreted templates like Heist-I and
> Hastache) .
>
> Its very much a work in progress, but I felt that it was enough for an
> initial release and get general feedback on it.  Comments are appreciated.
>
> One thing that I want to improve is how functions are handled in the
> template and in the "InputBucket", extend the syntax to allow you to do
> more inside the template and be able to define your own block functions.
> These will probably be added next major release.
>
> http://hackage.haskell.org/package/StrappedTemplates
> https://github.com/hansonkd/StrappedTemplates
>
> Thanks!
> Kyle Hanson
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140804/113f562d/attachment.html>

From ok at cs.otago.ac.nz  Tue Aug  5 01:48:10 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Tue, 5 Aug 2014 13:48:10 +1200
Subject: [Haskell-cafe] Fwd: Default stdout buffering of child
 processofcreateProcess
In-Reply-To: <53DF6D9F.5010205@unicaen.fr>
References: <CAG7kECMVXS-e9Trz0Rih0DkvfX=GvoxDBvhh39svAicnqj=OFg@mail.gmail.com>
 <20140804042545.0A267F3935@mail.avvanta.com>
 <53DF6D9F.5010205@unicaen.fr>
Message-ID: <4228663ac77563669a10aa772a4c81f0.squirrel@chasm.otago.ac.nz>

> Concerning buffering, when somebody (Richard O'K. presumably) says :
>> I am sick of having to tell students "Java does not buffer by
>> default, it is up to YOU to use BufferedReader and/or
>> BufferedWriter if you do not want I/O to be catastrophically
>> slow".
> I would say that in many circumstances (Java EE services, etc.) this is
> far from being catastrophically slow.

It was me, and we don't do Java EE services.  We *do* do information
retrieval and data mining and stuff, some stuff coming from files
and some stuff coming from files, and 'catastrophically slow' is
reliably observed behaviour for that kind of stuff.  I know so very
little about Java EE services that it never occurred to me that
people would use java.io.* for any significant amounts of data in
that area.

Is the usage of java.io.* in Java EE something that might find an
analogue in Haskell use, making unbuffered I/O something Haskell
programmers might need frequently?

(I'm drawing a distinction here between on the one hand buffered
I/O with careful flushing at interaction boundaries and on the
other hand unbuffered I/O where each program-level transput call
is a system-level transput operation.)



From alois.cochard at gmail.com  Tue Aug  5 08:47:54 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Tue, 5 Aug 2014 09:47:54 +0100
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <53DE3576.6010401@spawnhost.de>
References: <53DE3576.6010401@spawnhost.de>
Message-ID: <CAJHA+wooJgCL671t7aLPC9A70f9FhQdZqTz3KLBwtQk73KOOLw@mail.gmail.com>

Hi Sebastian,

Someone reported me a bug on twitter, please see:
https://twitter.com/blast_hardchese/status/496313816410357761

Thanks for your work, it's really promising!

Cheers

Alois


On 3 August 2014 14:13, Sebastian Philipp <sebastian at spawnhost.de> wrote:

> Hi Cafe,
>
> Hayoo <http://hayoo.fh-wedel.de> has been relaunched. Hayoo is a search
> engine for Hackage packages, which allows you to search for functions,
> data types and packages.
>
> It is currently work in progress. Any feedback is greatly appreciated!
>
> Hayoo uses Hunt <https://github.com/hunt-framework> for indexing and
> searching, which is the successor of Holumbus. Hunt is a flexible,
> lightweight search platform with a powerful query language and JSON API.
>
> Example search requests are:
>
> * Function names: map
> <http://hayoo.fh-wedel.de/?query=map>
>
> * Function signatures: (a->b)->f a->f b
> <http://hayoo.fh-wedel.de/?query=%28a-%3Eb%29-%3Ef+a-%3Ef+b>
>
> * Module names: Control.Loop
> <http://hayoo.fh-wedel.de/?query=Control.Loop>
>
> Have a look at the examples on <http://hayoo.fh-wedel.de/examples> for
> some advances queries.
>
> The old Hayoo and Holumbus are still online at
> <http://holumbus-alt.fh-wedel.de/>
>
> --
> Sebastian Philipp
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/f6aef66c/attachment.html>

From ruben.astud at gmail.com  Tue Aug  5 08:46:35 2014
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Tue, 05 Aug 2014 04:46:35 -0400
Subject: [Haskell-cafe] Applicative & Monad as interaction between categories
Message-ID: <53E099EB.2050207@gmail.com>

Hi all,

I recently came across of two blog posts[1][2] by Gabriel Gonzales where he
shows motivation for writing compositional functions -- and thus why the concept
of category is useful -- and motivation to write functors between them.

I wanted to know if something similar for has been done to `Applicative' and
`Monad' as design pattern and interaction between categories. I've searching but
I always hit the Monad tutorials and more info on how to use them.

Thanks in advance. Excuse my English.

[1]: http://www.haskellforall.com/2012/08/the-category-design-pattern.html
[2]: http://www.haskellforall.com/2012/09/the-functor-design-pattern.html

-- 
Ruben Astudillo. pgp: 0x3C332311 , usala en lo posible :-)
Crear un haiku, en diecisiete silabas, es complica...

From gergely at risko.hu  Tue Aug  5 09:19:25 2014
From: gergely at risko.hu (Gergely Risko)
Date: Tue, 05 Aug 2014 11:19:25 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
References: <53DE3576.6010401@spawnhost.de>
Message-ID: <87ha1rcmzm.fsf@gergely.risko.hu>

Hi,

This looks very nice, thanks for your work!

May I ask if it's possible to run this on my local machine for the times
when I don't have internet to use the JSON API?

http://hackage.haskell.org/package/Hayoo seems related, but it's last
upload date is in 2012.

It would be nice if there were an easy way to download the already
generated index from the server, so that the users don't have to rebuild
it on their own (which may be expensive).  Just redownload every once in
a while.

So if you have any comments on offline usage, I'm eager to hear!

Thanks,
Gergely


From sebastian at spawnhost.de  Tue Aug  5 11:43:16 2014
From: sebastian at spawnhost.de (Sebastian Philipp)
Date: Tue, 05 Aug 2014 13:43:16 +0200
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <87ha1rcmzm.fsf@gergely.risko.hu>
References: <53DE3576.6010401@spawnhost.de> <87ha1rcmzm.fsf@gergely.risko.hu>
Message-ID: <53E0C354.5050206@spawnhost.de>

Hi Gergely,

Am 05.08.2014 um 11:19 schrieb Gergely Risko:
> Hi,
> 
> May I ask if it's possible to run this on my local machine for the times
> when I don't have internet to use the JSON API?

Hayoo requires about 5GB of RAM for indexing complete Hackage at the
moment. I don't think is feasible to run a local Hayoo to index Hackage.
On the other hand, one might think about a Hayoo which indexes the local
Cabal sandbox. Unfortunately, this is not our top priority.

> 
> http://hackage.haskell.org/package/Hayoo seems related, but it's last
> upload date is in 2012.

The new Hayoo is based on the Hunt-Framework, which is not ready to be
released at the moment. We're going to make a separate announcement for
Hunt then. in the meantime, you can have a look at the GitHub repository
[0].

> 
> It would be nice if there were an easy way to download the already
> generated index from the server, so that the users don't have to rebuild
> it on their own (which may be expensive).  Just redownload every once in
> a while.
I could publish the serialized index of Hayoo, if you want to set up a
local Hayoo despite the memory usage.

regards,

Sebastian
> 
> So if you have any comments on offline usage, I'm eager to hear!

> 
> Thanks,
> Gergely
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

[0] https://github.com/hunt-framework

-- 
Sebastian Philipp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/0106fd21/attachment.sig>

From KAction at gnu.org  Tue Aug  5 12:00:18 2014
From: KAction at gnu.org (Dmitry Bogatov)
Date: Tue, 5 Aug 2014 16:00:18 +0400
Subject: [Haskell-cafe] Dealing with encodings
Message-ID: <20140805120018.GA13454@self.lan>

Hello!

How teach hxt to handle "KOI8-R" encoding of input file?

And it seems that so many great packages (like hxt, feed, curl) uses String.
Is it some work in progress to port them to Text?

--
Best regards, Dmitry Bogatov <KAction at gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/8db051e7/attachment.sig>

From ivan.miljenovic at gmail.com  Tue Aug  5 12:09:30 2014
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 5 Aug 2014 22:09:30 +1000
Subject: [Haskell-cafe] Dealing with encodings
In-Reply-To: <20140805120018.GA13454@self.lan>
References: <20140805120018.GA13454@self.lan>
Message-ID: <CA+u6gbz92xvF5FACCWmKfFcsHN-kq-H=75U4Bxap-MT-AN3BjQ@mail.gmail.com>

On 5 August 2014 22:00, Dmitry Bogatov <KAction at gnu.org> wrote:
> Hello!
>
> How teach hxt to handle "KOI8-R" encoding of input file?

http://hackage.haskell.org/package/text-icu ?

>
> And it seems that so many great packages (like hxt, feed, curl) uses String.
> Is it some work in progress to port them to Text?

Because no-one has changed them to do so.  Some of them probably also
predate the rise in popularity of text.

>
> --
> Best regards, Dmitry Bogatov <KAction at gnu.org>,
> Free Software supporter, esperantisto and netiquette guardian.
> GPG: 54B7F00D
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

From mike at izbicki.me  Tue Aug  5 14:57:45 2014
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 5 Aug 2014 07:57:45 -0700
Subject: [Haskell-cafe] Applicative & Monad as interaction between
	categories
In-Reply-To: <53E099EB.2050207@gmail.com>
References: <53E099EB.2050207@gmail.com>
Message-ID: <CAKKZoUXTX7r1X9CkoMHiYdcn9xoN5KOzWj87kmk3BE-T2DF34Q@mail.gmail.com>

I have a github repo called subhask that does this.  It uses the
ConstraintKinds extension and some other tricks to let us work in
subcategories of hask, and build endofunctors, applicatives, and
monads in those categories.  My particular application is building a
dsl for machine learning, so there's a category for linear maps, and a
category for lipschitz maps, among many others.  (Normal distributions
are monads in the category Vect, and most metric-based algorithms are
monads in the category of lipshitz maps.)  It's not quite ready for
release, but you can check out the in progress work if you want.

The most interesting bits for you are probably the category instances:
https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Category.hs

and the monad hierarchy:
https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Functor.hs

The monad definitions currently lack adequate documentation because
some things will still have to change to get the type checker to do
what I want.  For example, do notation doesn't work properly yet in
some subcategories.

On Tue, Aug 5, 2014 at 1:46 AM, Ruben Astudillo <ruben.astud at gmail.com> wrote:
> Hi all,
>
> I recently came across of two blog posts[1][2] by Gabriel Gonzales where he
> shows motivation for writing compositional functions -- and thus why the concept
> of category is useful -- and motivation to write functors between them.
>
> I wanted to know if something similar for has been done to `Applicative' and
> `Monad' as design pattern and interaction between categories. I've searching but
> I always hit the Monad tutorials and more info on how to use them.
>
> Thanks in advance. Excuse my English.
>
> [1]: http://www.haskellforall.com/2012/08/the-category-design-pattern.html
> [2]: http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
>
> --
> Ruben Astudillo. pgp: 0x3C332311 , usala en lo posible :-)
> Crear un haiku, en diecisiete silabas, es complica...
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From miguelimo38 at yandex.ru  Tue Aug  5 15:12:19 2014
From: miguelimo38 at yandex.ru (MigMit)
Date: Tue, 5 Aug 2014 19:12:19 +0400
Subject: [Haskell-cafe] Dealing with encodings
In-Reply-To: <20140805120018.GA13454@self.lan>
References: <20140805120018.GA13454@self.lan>
Message-ID: <140F6479-B7A3-4551-8EA9-712E30DF957E@yandex.ru>

Please, don't do that. The overabundance of cyrillic encodings caused great pain in the past; don't help this genie out of the bottle again. Especially since KOI8-R is the worst of cyrillic encodings.

On 05 Aug 2014, at 16:00, Dmitry Bogatov <KAction at gnu.org> wrote:

> Hello!
> 
> How teach hxt to handle "KOI8-R" encoding of input file?
> 
> And it seems that so many great packages (like hxt, feed, curl) uses String.
> Is it some work in progress to port them to Text?
> 
> --
> Best regards, Dmitry Bogatov <KAction at gnu.org>,
> Free Software supporter, esperantisto and netiquette guardian.
> GPG: 54B7F00D
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From andrew.gibiansky at gmail.com  Tue Aug  5 15:55:35 2014
From: andrew.gibiansky at gmail.com (Andrew Gibiansky)
Date: Tue, 5 Aug 2014 08:55:35 -0700
Subject: [Haskell-cafe] [ANN] Hayoo Relaunch
In-Reply-To: <53E0C354.5050206@spawnhost.de>
References: <53DE3576.6010401@spawnhost.de> <87ha1rcmzm.fsf@gergely.risko.hu>
 <53E0C354.5050206@spawnhost.de>
Message-ID: <CAF-LYKL5B3EF+4akHZVQjgPODx1VbepqaUDyY3ER4b=DBg1AMg@mail.gmail.com>

> Hayoo requires about 5GB of RAM for indexing complete Hackage at the
moment. I don't think is feasible to run a local Hayoo to index Hackage.
On the other hand, one might think about a Hayoo which indexes the local
Cabal sandbox. Unfortunately, this is not our top priority.

On my laptop, I have 16 GB RAM. 5 GB is not nothing, but it really isn't
that much -- if it requires only 5 GB, it's *definitely* feasible to run a
local Hayoo (well, memory-wise at least).

-- Andrew


On Tue, Aug 5, 2014 at 4:43 AM, Sebastian Philipp <sebastian at spawnhost.de>
wrote:

> Hi Gergely,
>
> Am 05.08.2014 um 11:19 schrieb Gergely Risko:
> > Hi,
> >
> > May I ask if it's possible to run this on my local machine for the times
> > when I don't have internet to use the JSON API?
>
> Hayoo requires about 5GB of RAM for indexing complete Hackage at the
> moment. I don't think is feasible to run a local Hayoo to index Hackage.
> On the other hand, one might think about a Hayoo which indexes the local
> Cabal sandbox. Unfortunately, this is not our top priority.
>
> >
> > http://hackage.haskell.org/package/Hayoo seems related, but it's last
> > upload date is in 2012.
>
> The new Hayoo is based on the Hunt-Framework, which is not ready to be
> released at the moment. We're going to make a separate announcement for
> Hunt then. in the meantime, you can have a look at the GitHub repository
> [0].
>
> >
> > It would be nice if there were an easy way to download the already
> > generated index from the server, so that the users don't have to rebuild
> > it on their own (which may be expensive).  Just redownload every once in
> > a while.
> I could publish the serialized index of Hayoo, if you want to set up a
> local Hayoo despite the memory usage.
>
> regards,
>
> Sebastian
> >
> > So if you have any comments on offline usage, I'm eager to hear!
>
> >
> > Thanks,
> > Gergely
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> [0] https://github.com/hunt-framework
>
> --
> Sebastian Philipp
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/8fa8d317/attachment.html>

From carter.schonwald at gmail.com  Tue Aug  5 16:03:15 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 5 Aug 2014 12:03:15 -0400
Subject: [Haskell-cafe] Applicative & Monad as interaction between
	categories
In-Reply-To: <CAKKZoUXTX7r1X9CkoMHiYdcn9xoN5KOzWj87kmk3BE-T2DF34Q@mail.gmail.com>
References: <53E099EB.2050207@gmail.com>
 <CAKKZoUXTX7r1X9CkoMHiYdcn9xoN5KOzWj87kmk3BE-T2DF34Q@mail.gmail.com>
Message-ID: <CAHYVw0yktSLT4nE_QW1wGmi7Yqcto+rxYDzsP0+qCfDAWCbYHQ@mail.gmail.com>

huh, that looks neat, i'll have to check it out when i have time.

I'd actually argue that the paper by Sam Lindley, Philip Wadler and Jeremy
Yallop is another interesting take
http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf

therein, the authors relate Applicatives, Monads and Arrows and their
respective expressivity in a categorical setting




On Tue, Aug 5, 2014 at 10:57 AM, Mike Izbicki <mike at izbicki.me> wrote:

> I have a github repo called subhask that does this.  It uses the
> ConstraintKinds extension and some other tricks to let us work in
> subcategories of hask, and build endofunctors, applicatives, and
> monads in those categories.  My particular application is building a
> dsl for machine learning, so there's a category for linear maps, and a
> category for lipschitz maps, among many others.  (Normal distributions
> are monads in the category Vect, and most metric-based algorithms are
> monads in the category of lipshitz maps.)  It's not quite ready for
> release, but you can check out the in progress work if you want.
>
> The most interesting bits for you are probably the category instances:
> https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Category.hs
>
> and the monad hierarchy:
> https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Functor.hs
>
> The monad definitions currently lack adequate documentation because
> some things will still have to change to get the type checker to do
> what I want.  For example, do notation doesn't work properly yet in
> some subcategories.
>
> On Tue, Aug 5, 2014 at 1:46 AM, Ruben Astudillo <ruben.astud at gmail.com>
> wrote:
> > Hi all,
> >
> > I recently came across of two blog posts[1][2] by Gabriel Gonzales where
> he
> > shows motivation for writing compositional functions -- and thus why the
> concept
> > of category is useful -- and motivation to write functors between them.
> >
> > I wanted to know if something similar for has been done to `Applicative'
> and
> > `Monad' as design pattern and interaction between categories. I've
> searching but
> > I always hit the Monad tutorials and more info on how to use them.
> >
> > Thanks in advance. Excuse my English.
> >
> > [1]:
> http://www.haskellforall.com/2012/08/the-category-design-pattern.html
> > [2]:
> http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
> >
> > --
> > Ruben Astudillo. pgp: 0x3C332311 , usala en lo posible :-)
> > Crear un haiku, en diecisiete silabas, es complica...
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/ec4e11db/attachment.html>

From KAction at gnu.org  Tue Aug  5 17:06:17 2014
From: KAction at gnu.org (Dmitry Bogatov)
Date: Tue, 5 Aug 2014 21:06:17 +0400
Subject: [Haskell-cafe] Dealing with encodings
In-Reply-To: <140F6479-B7A3-4551-8EA9-712E30DF957E@yandex.ru>
References: <20140805120018.GA13454@self.lan>
 <140F6479-B7A3-4551-8EA9-712E30DF957E@yandex.ru>
Message-ID: <20140805170617.GA23894@self.lan>

* MigMit <miguelimo38 at yandex.ru> [2014-08-05 19:12:19+0400]
> Please, don't do that. The overabundance of cyrillic encodings caused
> great pain in the past; don't help this genie out of the bottle
> again. Especially since KOI8-R is the worst of cyrillic encodings.

I totally agree that using anything, but utf-8 is crime.  But fact is
fact -- I need to parse html page, that is koi8 encoded. What should I do?

--
Best regards, Dmitry Bogatov <KAction at gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/7f37bdb2/attachment.sig>

From carter.schonwald at gmail.com  Tue Aug  5 17:58:35 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 5 Aug 2014 13:58:35 -0400
Subject: [Haskell-cafe] Dealing with encodings
In-Reply-To: <20140805170617.GA23894@self.lan>
References: <20140805120018.GA13454@self.lan>
 <140F6479-B7A3-4551-8EA9-712E30DF957E@yandex.ru>
 <20140805170617.GA23894@self.lan>
Message-ID: <CAHYVw0z2zxm8rJhNB6HP2raVTHEa3_Ct1gSQkgpsmCO=0vCT2Q@mail.gmail.com>

use text-icu and text to decode it into Text, then use the standard tools


On Tue, Aug 5, 2014 at 1:06 PM, Dmitry Bogatov <KAction at gnu.org> wrote:

> * MigMit <miguelimo38 at yandex.ru> [2014-08-05 19:12:19+0400]
> > Please, don't do that. The overabundance of cyrillic encodings caused
> > great pain in the past; don't help this genie out of the bottle
> > again. Especially since KOI8-R is the worst of cyrillic encodings.
>
> I totally agree that using anything, but utf-8 is crime.  But fact is
> fact -- I need to parse html page, that is koi8 encoded. What should I do?
>
> --
> Best regards, Dmitry Bogatov <KAction at gnu.org>,
> Free Software supporter, esperantisto and netiquette guardian.
> GPG: 54B7F00D
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140805/b2e18fe1/attachment.html>

From lazarev.michael at gmail.com  Tue Aug  5 19:49:02 2014
From: lazarev.michael at gmail.com (Michael Lazarev)
Date: Tue, 5 Aug 2014 23:49:02 +0400
Subject: [Haskell-cafe] Side-by-side pretty printing
Message-ID: <CACq8WdsaSr51MRFianUFTrxxQANY4MRD+emrut3xWz_Omvt8jw@mail.gmail.com>

Hi all,

When looking into Text.PrettyPrint, I stumbled upon <> (beside) combinator.
Is it true that multi-line documents can't be printed one beside other?

E.g. this

  let doc1 = vcat $ map text ["This", "is", "a", "document"]
  in doc1 <> doc1

prints this:

This
is
a
documentThis
        is
        a
        document

As well as if I would write `doc1 <> nest 50 doc1`.

What I was expecting, was

This    This
is      is
a       a
documentdocument

Do I get it right that Text.PrettyPrint was not intended for such things?

From stephen.tetley at gmail.com  Tue Aug  5 20:27:18 2014
From: stephen.tetley at gmail.com (Stephen Tetley)
Date: Tue, 5 Aug 2014 21:27:18 +0100
Subject: [Haskell-cafe] Side-by-side pretty printing
In-Reply-To: <CACq8WdsaSr51MRFianUFTrxxQANY4MRD+emrut3xWz_Omvt8jw@mail.gmail.com>
References: <CACq8WdsaSr51MRFianUFTrxxQANY4MRD+emrut3xWz_Omvt8jw@mail.gmail.com>
Message-ID: <CAB2TPRBReGD_wV+ZZCiDqCH3NR6r-SepW25yT7ufpr8urYVTDQ@mail.gmail.com>

Hi Michael

On 5 August 2014 20:49, Michael Lazarev <lazarev.michael at gmail.com> wrote:

> Do I get it right that Text.PrettyPrint was not intended for such things?

Yes - the common pretty printers do not handle column printing,
generally they are for laying out text with nesting - typically
program code.

Maybe someone has written a column-oriented pretty printer, it is not
so hard - I've written "internal" ones a few times, but never polished
one up enough to publish.

From lazarev.michael at gmail.com  Tue Aug  5 20:54:44 2014
From: lazarev.michael at gmail.com (Michael Lazarev)
Date: Wed, 6 Aug 2014 00:54:44 +0400
Subject: [Haskell-cafe] Side-by-side pretty printing
In-Reply-To: <CAB2TPRBReGD_wV+ZZCiDqCH3NR6r-SepW25yT7ufpr8urYVTDQ@mail.gmail.com>
References: <CACq8WdsaSr51MRFianUFTrxxQANY4MRD+emrut3xWz_Omvt8jw@mail.gmail.com>
 <CAB2TPRBReGD_wV+ZZCiDqCH3NR6r-SepW25yT7ufpr8urYVTDQ@mail.gmail.com>
Message-ID: <CACq8WdsehZAGK1UqR2V1ApAtYZicN4rAcSvj8Cu7qa=fW_FtNA@mail.gmail.com>

2014-08-06 0:27 GMT+04:00 Stephen Tetley <stephen.tetley at gmail.com>:
> Yes - the common pretty printers do not handle column printing,
> generally they are for laying out text with nesting - typically
> program code.
>
> Maybe someone has written a column-oriented pretty printer, it is not
> so hard - I've written "internal" ones a few times, but never polished
> one up enough to publish.

I sketched one on a blackboard today, during a workshop. It turned out
to be pretty easy in Haskell. Just wanted to double-check that I
understand capabilities of Text.PrettyPrint correctly, as it's hard
for me to understand the code closer to the end of this module. Thank
you very much for your help!

From danilovalexalex at yandex.ru  Wed Aug  6 05:25:54 2014
From: danilovalexalex at yandex.ru (Danilov Alexander)
Date: Wed, 06 Aug 2014 09:25:54 +0400
Subject: [Haskell-cafe] [OBORONA-SPAM]  Dealing with encodings
In-Reply-To: <20140805120018.GA13454@self.lan>
References: <20140805120018.GA13454@self.lan>
Message-ID: <53E1BC62.203@yandex.ru>

05.08.2014 16:00, Dmitry Bogatov ?????:
> Hello!
>
> How teach hxt to handle "KOI8-R" encoding of input file?
>
> And it seems that so many great packages (like hxt, feed, curl) uses String.
> Is it some work in progress to port them to Text?
> Prelude> :search encoding
Prelude> :search encoding
Searching for: encoding
package encoding
Data.Text.Encoding module Data.Text.Encoding
Data.Text.Lazy.Encoding module Data.Text.Lazy.Encoding
GHC.IO.Encoding module GHC.IO.Encoding
System.IO hGetEncoding :: Handle -> IO (Maybe TextEncoding)
GHC.IO.Handle hGetEncoding :: Handle -> IO (Maybe TextEncoding)
System.IO hSetEncoding :: Handle -> TextEncoding -> IO ()
GHC.IO.Handle hSetEncoding :: Handle -> TextEncoding -> IO ()
System.IO localeEncoding :: TextEncoding
GHC.IO.Encoding localeEncoding :: TextEncoding
System.IO mkTextEncoding :: String -> IO TextEncoding
GHC.IO.Encoding mkTextEncoding :: String -> IO TextEncoding

You can read file in any encoding available in system and later convert it into Text.


From KAction at gnu.org  Wed Aug  6 12:14:13 2014
From: KAction at gnu.org (Dmitry Bogatov)
Date: Wed, 6 Aug 2014 16:14:13 +0400
Subject: [Haskell-cafe] [OBORONA-SPAM]  Dealing with encodings
In-Reply-To: <53E1BC62.203@yandex.ru>
References: <20140805120018.GA13454@self.lan>
 <53E1BC62.203@yandex.ru>
Message-ID: <20140806121413.GA3414@self.lan>

* Danilov Alexander <danilovalexalex at yandex.ru> [2014-08-06 09:25:54+0400]
> 05.08.2014 16:00, Dmitry Bogatov ?????:
> >Hello!
> >
> >How teach hxt to handle "KOI8-R" encoding of input file?
> >
> >And it seems that so many great packages (like hxt, feed, curl) uses String.
> >Is it some work in progress to port them to Text?
> >Prelude> :search encoding
> Prelude> :search encoding
> Searching for: encoding
> package encoding
> Data.Text.Encoding module Data.Text.Encoding
> Data.Text.Lazy.Encoding module Data.Text.Lazy.Encoding
> GHC.IO.Encoding module GHC.IO.Encoding
> System.IO hGetEncoding :: Handle -> IO (Maybe TextEncoding)
> GHC.IO.Handle hGetEncoding :: Handle -> IO (Maybe TextEncoding)
> System.IO hSetEncoding :: Handle -> TextEncoding -> IO ()
> GHC.IO.Handle hSetEncoding :: Handle -> TextEncoding -> IO ()
> System.IO localeEncoding :: TextEncoding
> GHC.IO.Encoding localeEncoding :: TextEncoding
> System.IO mkTextEncoding :: String -> IO TextEncoding
> GHC.IO.Encoding mkTextEncoding :: String -> IO TextEncoding

Problem is that I have XML file from unknown source. I do not know
encoding A-priori, it's specified in file itself. And to get it, I need
to parse XML.

--
Best regards, Dmitry Bogatov <KAction at gnu.org>,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140806/6ecaebaf/attachment.sig>

From danilovalexalex at yandex.ru  Wed Aug  6 16:09:02 2014
From: danilovalexalex at yandex.ru (Danilov Alexander)
Date: Wed, 06 Aug 2014 20:09:02 +0400
Subject: [Haskell-cafe] [OBORONA-SPAM]  Dealing with encodings
In-Reply-To: <20140806121413.GA3414@self.lan>
References: <20140805120018.GA13454@self.lan> <53E1BC62.203@yandex.ru>
 <20140806121413.GA3414@self.lan>
Message-ID: <53E2531E.9010208@yandex.ru>

06.08.2014 16:14, Dmitry Bogatov ?????:
> * Danilov Alexander <danilovalexalex at yandex.ru> [2014-08-06 09:25:54+0400]
>> 05.08.2014 16:00, Dmitry Bogatov ?????:
>>> Hello!
>>>
>>> How teach hxt to handle "KOI8-R" encoding of input file?
>>>
>>> And it seems that so many great packages (like hxt, feed, curl) uses String.
>>> Is it some work in progress to port them to Text?
>>> Prelude> :search encoding
>> Prelude> :search encoding
>> Searching for: encoding
>> package encoding
>> Data.Text.Encoding module Data.Text.Encoding
>> Data.Text.Lazy.Encoding module Data.Text.Lazy.Encoding
>> GHC.IO.Encoding module GHC.IO.Encoding
>> System.IO hGetEncoding :: Handle -> IO (Maybe TextEncoding)
>> GHC.IO.Handle hGetEncoding :: Handle -> IO (Maybe TextEncoding)
>> System.IO hSetEncoding :: Handle -> TextEncoding -> IO ()
>> GHC.IO.Handle hSetEncoding :: Handle -> TextEncoding -> IO ()
>> System.IO localeEncoding :: TextEncoding
>> GHC.IO.Encoding localeEncoding :: TextEncoding
>> System.IO mkTextEncoding :: String -> IO TextEncoding
>> GHC.IO.Encoding mkTextEncoding :: String -> IO TextEncoding
> Problem is that I have XML file from unknown source. I do not know
> encoding A-priori, it's specified in file itself. And to get it, I need
> to parse XML.
>
>
Usually, encoding specified in xml file, and xml parser may recode text data itself.
I show you API to recode text, it xml parser unable to recode.


From dstcruz at gmail.com  Thu Aug  7 04:43:14 2014
From: dstcruz at gmail.com (Daniel Santa Cruz)
Date: Wed, 6 Aug 2014 22:43:14 -0600
Subject: [Haskell-cafe] Haskell Weekly News: Issue 301
Message-ID: <CA+V-9CxurdcOdjSCOqeuVyaRD3KXPeucMTNR06skWROT9R_BFQ@mail.gmail.com>

Welcome to issue 301 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers
from July 27 to August 2, 2014

Quotes of the Week

    * bernalex: I used to have a problem then I used lens now I have an
      abstraction problem?

   * trap_exit: haskell is like the 'and they lived happily ever after'
     of programming languages

Top Reddit Stories

   * The Comonad.Reader ? Letter to a Young Haskell Enthusiast
     Domain: comonad.com, Score: 236, Comments: 56
     Original: [1] http://goo.gl/Z5usp3
     On Reddit: [2] http://goo.gl/CpPKnC

   * seL4 is now open source: the world's first end-to-end verified OS
kernel
     Domain: github.com, Score: 87, Comments: 20
     Original: [3] http://goo.gl/Uz50bj
     On Reddit: [4] http://goo.gl/EQK0MQ

   * FP Haskell Center now free for open projects
     Domain: fpcomplete.com, Score: 81, Comments: 23
     Original: [5] http://goo.gl/ULc9ze
     On Reddit: [6] http://goo.gl/ZleWCk

   * -XOverlappingInstances and -XIncoherentInstances to be deprecated
     Domain: haskell.org, Score: 76, Comments: 64
     Original: [7] http://goo.gl/dokkrY
     On Reddit: [8] http://goo.gl/0AyqA2

   * First-Class "Statements": IO as data
     Domain: blog.jle.im, Score: 68, Comments: 32
     Original: [9] http://goo.gl/JNj2D1
     On Reddit: [10] http://goo.gl/h1v7yp

   * Foldable and Traversable in Haskell
     Domain: blog.jakubarnold.cz, Score: 61, Comments: 30
     Original: [11] http://goo.gl/mgI6Mg
     On Reddit: [12] http://goo.gl/nvwj6j

   * Minimalist GUI toolkit in GHCi
     Domain: github.com, Score: 61, Comments: 7
     Original: [13] http://goo.gl/9PvsUP
     On Reddit: [14] http://goo.gl/jQKyG7

   * early adopters rejoyce! Haskell Platform 2014.2.0.0 Release Candidate 2
     Domain: haskell.org, Score: 48, Comments: 27
     Original: [15] http://goo.gl/AGl5po
     On Reddit: [16] http://goo.gl/ThS3Wc

   * The Modular, Functional Client Side
     Domain: stackbuilders.com, Score: 46, Comments: 3
     Original: [17] http://goo.gl/eydkfz
     On Reddit: [18] http://goo.gl/z9q8hE

   * Beware of bracket
     Domain: ro-che.info, Score: 46, Comments: 18
     Original: [19] http://goo.gl/UYA2mF
     On Reddit: [20] http://goo.gl/ksMQVV

   * Real World Haskell: Shipping "Carnival", a Blog Commenting Service
     Domain: robots.thoughtbot.com, Score: 44, Comments: 5
     Original: [21] http://goo.gl/UmPyiL
     On Reddit: [22] http://goo.gl/4PRdpm

   * Flee traveller! Flee or you will be corrupted and devoured!
     Domain: github.com, Score: 41, Comments: 16
     Original: [23] http://goo.gl/e3sA6X
     On Reddit: [24] http://goo.gl/RuAZ4o

   * Reading files from the /proc filesystem
     Domain: yesodweb.com, Score: 35, Comments: 4
     Original: [25] http://goo.gl/mVfVyM
     On Reddit: [26] http://goo.gl/Bd2HBT

   * clckwrks CMS source now on github. A sad farewell to darcs and an
     optimistic look towards greater contributions from the community.
     Domain: clckwrks.com, Score: 33, Comments: 31
     Original: [27] http://goo.gl/ZLqVWl
     On Reddit: [28] http://goo.gl/q0za2l

   * Introduction to GHC.TypeLits with base 4.7, including runtime
conversion
     of symbols.
     Domain: ponies.io, Score: 32, Comments: 13
     Original: [29] http://goo.gl/6FtdyO
     On Reddit: [30] http://goo.gl/PpmkOc

   * Converting Make to Shake
     Domain: neilmitchell.blogspot.com, Score: 23, Comments: 14
     Original: [31] http://goo.gl/dOWVhV
     On Reddit: [32] http://goo.gl/cHYTmS

   * Learn Snap: Interactive Snap + Heist Examples
     Domain: learnsnap.chromaticleaves.com, Score: 21, Comments: 14
     Original: [33] http://goo.gl/Opwt40
     On Reddit: [34] http://goo.gl/06AneL

   * Hackage: ghc-server: A server interface to GHC.
     Domain: hackage.haskell.org, Score: 18, Comments: 14
     Original: [35] http://goo.gl/ZjhScl
     On Reddit: [36] http://goo.gl/b9wBfP

   * Bloggy Badger: Homemade FRP: a study in following the types
     Domain: gelisam.blogspot.com, Score: 17, Comments: 1
     Original: [37] http://goo.gl/T7ujN3
     On Reddit: [38] http://goo.gl/HAV1mR

Top StackOverflow Questions

   * IO/Monadic assign operator causing ghci to explode for infinite list
     votes: 16, answers: 1
     Read on SO: [39] http://goo.gl/TC0Snn

   * A performance conundrum
     votes: 14, answers: 1
     Read on SO: [40] http://goo.gl/b910ez

   * Does an unused let binding have any effect in Haskell?
     votes: 12, answers: 3
     Read on SO: [41] http://goo.gl/KEl13j

   * In Haskell, are guards or matchers preferable?
     votes: 12, answers: 1
     Read on SO: [42] http://goo.gl/LiXDjk

   * If MonadPlus is the ?generator? class, then what is the ?consumer?
class?
     votes: 12, answers: 2
     Read on SO: [43] http://goo.gl/eqRu3a

   * Why would using head/tail instead of pattern matching make evaluation
     terminate?
     votes: 12, answers: 3
     Read on SO: [44] http://goo.gl/LOjX0V

Until next time,
[45]+Daniel Santa Cruz

References

   1. http://comonad.com/reader/2014/letter-to-a-young-haskell-enthusiast/
   2.
http://www.reddit.com/r/haskell/comments/2cbbgf/the_comonadreader_letter_to_a_young_haskell/
   3. https://github.com/seL4/seL4
   4.
http://www.reddit.com/r/haskell/comments/2c1bnp/sel4_is_now_open_source_the_worlds_first_endtoend/
   5. https://www.fpcomplete.com/business/blog/fp-haskell-center-going-free/
   6.
http://www.reddit.com/r/haskell/comments/2c9u0g/fp_haskell_center_now_free_for_open_projects/
   7. http://www.haskell.org/pipermail/ghc-devs/2014-July/005830.html
   8.
http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_xincoherentinstances_to/
   9. http://blog.jle.im/entry/first-class-statements
  10.
http://www.reddit.com/r/haskell/comments/2byuhj/firstclass_statements_io_as_data/
  11. http://blog.jakubarnold.cz/2014/07/30/foldable-and-traversable.html
  12.
http://www.reddit.com/r/haskell/comments/2c8b87/foldable_and_traversable_in_haskell/
  13. https://github.com/divipp/lensref/wiki
  14.
http://www.reddit.com/r/haskell/comments/2cge6f/minimalist_gui_toolkit_in_ghci/
  15. http://www.haskell.org/pipermail/haskell/2014-July/024276.html
  16.
http://www.reddit.com/r/haskell/comments/2c0ep4/early_adopters_rejoyce_haskell_platform_2014200/
  17. http://www.stackbuilders.com/news/the-modular-functional-client-side
  18.
http://www.reddit.com/r/haskell/comments/2c21j0/the_modular_functional_client_side/
  19. http://ro-che.info/articles/2014-07-30-bracket.html
  20. http://www.reddit.com/r/haskell/comments/2c4li4/beware_of_bracket/
  21. http://robots.thoughtbot.com/ship-you-a-haskell
  22.
http://www.reddit.com/r/haskell/comments/2cfdms/real_world_haskell_shipping_carnival_a_blog/
  23.
https://github.com/haskell/bytestring/blob/2530b1c28f15d0f320a84701bf507d5650de6098/Data/ByteString/Internal.hs#L624-L634
  24.
http://www.reddit.com/r/haskell/comments/2cbgpz/flee_traveller_flee_or_you_will_be_corrupted_and/
  25. http://www.yesodweb.com/blog/2014/07/reading-files-proc-filesystem
  26.
http://www.reddit.com/r/haskell/comments/2buufk/reading_files_from_the_proc_filesystem/
  27. http://www.clckwrks.com/page/view-page-slug/12/clckwrks-now-on-github
  28.
http://www.reddit.com/r/haskell/comments/2cd26w/clckwrks_cms_source_now_on_github_a_sad_farewell/
  29. http://ponies.io/posts/2014-07-30-typelits.html
  30.
http://www.reddit.com/r/haskell/comments/2c8bfi/introduction_to_ghctypelits_with_base_47/
  31. http://neilmitchell.blogspot.com/2014/07/converting-make-to-shake.html
  32.
http://www.reddit.com/r/haskell/comments/2bukaj/converting_make_to_shake/
  33. http://learnsnap.chromaticleaves.com/
  34.
http://www.reddit.com/r/haskell/comments/2cdc36/learn_snap_interactive_snap_heist_examples/
  35. http://hackage.haskell.org/package/ghc-server-1.0
  36.
http://www.reddit.com/r/haskell/comments/2c17zz/hackage_ghcserver_a_server_interface_to_ghc/
  37.
http://gelisam.blogspot.com/2014/07/homemade-frp-study-in-following-types.html
  38.
http://www.reddit.com/r/haskell/comments/2c0vg4/bloggy_badger_homemade_frp_a_study_in_following/
  39.
http://stackoverflow.com/questions/24986296/io-monadic-assign-operator-causing-ghci-to-explode-for-infinite-list
  40. http://stackoverflow.com/questions/25089668/a-performance-conundrum
  41.
http://stackoverflow.com/questions/24984661/does-an-unused-let-binding-have-any-effect-in-haskell
  42.
http://stackoverflow.com/questions/25000929/in-haskell-are-guards-or-matchers-preferable
  43.
http://stackoverflow.com/questions/25070740/if-monadplus-is-the-generator-class-then-what-is-the-consumer-class
  44.
http://stackoverflow.com/questions/25078598/why-would-using-head-tail-instead-of-pattern-matching-make-evaluation-terminate
  45. https://plus.google.com/105107667630152149014/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140806/bba15d50/attachment.html>

From waldmann at imn.htwk-leipzig.de  Thu Aug  7 12:33:43 2014
From: waldmann at imn.htwk-leipzig.de (J. Waldmann)
Date: Thu, 7 Aug 2014 12:33:43 +0000 (UTC)
Subject: [Haskell-cafe] Side-by-side pretty printing
References: <CACq8WdsaSr51MRFianUFTrxxQANY4MRD+emrut3xWz_Omvt8jw@mail.gmail.com>
 <CAB2TPRBReGD_wV+ZZCiDqCH3NR6r-SepW25yT7ufpr8urYVTDQ@mail.gmail.com>
 <CACq8WdsehZAGK1UqR2V1ApAtYZicN4rAcSvj8Cu7qa=fW_FtNA@mail.gmail.com>
Message-ID: <loom.20140807T142947-462@post.gmane.org>

This is what I use

http://autolat.imn.htwk-leipzig.de/gitweb/?p=autolib;a=blob;f=todoc/Autolib/ToDoc/Beside.hs;hb=HEAD

it's of the works-but-looks-ugly-and-is-terribly-inefficient variety
but since it's applied to small Docs only (like, columns of matrices),
I don't really care.

- J.W.



From 6yearold at gmail.com  Thu Aug  7 14:16:57 2014
From: 6yearold at gmail.com (arrowdodger)
Date: Thu, 7 Aug 2014 18:16:57 +0400
Subject: [Haskell-cafe] Free monad based EDSL for writing LLVM programs.
Message-ID: <CALH631=EbZ8aTZi=oPdfsP97J2XrRCTf=DpX+uaZ5m9=0mxXhw@mail.gmail.com>

Hello. I'm new with Haskell and FP, so i wanted someone to give comments on
the package i've made [1]. It's, actually, my first attempt to create
something more or less real, so any feedback would be welcome.

I've used Free monad to create EDSL that allows writing LLVM IR code.
Afterwards it could be converted into pure AST structure provided by
llvm-general-pure[2] package. Currently, it supports almost every
instruction, but i haven't yet come up with sensible defaults for them.

Another thing that bugs me is the ability to transform the code in syb way.
I want take a user-supplied function that would pattern-match instruction
and produce another code block and apply this function everywhere in the
code, but still can't get my head around it. I've come up with extF
function, that unlike extM, would resort to wrap instead of return, but
that's all i've managed to do.

Thanks in advance.

[1] https://bitbucket.org/arrowdodger/llvm-general-edsl
[2] http://hackage.haskell.org/package/llvm-general-pure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/6d973f16/attachment.html>

From silly8888 at gmail.com  Thu Aug  7 14:25:23 2014
From: silly8888 at gmail.com (silly8888)
Date: Thu, 7 Aug 2014 15:25:23 +0100
Subject: [Haskell-cafe] parsec: problem combining lookAhead with many1 (bug?)
Message-ID: <CAMmzbfWA9S3YGjJ1iQaa72rKZyuV4psvEP3LsQuDGC3QED-YVw@mail.gmail.com>

Suppose that we have the following parser:

  p = lookAhead (char 'a') >> char 'b'

If we use it like so

  parse p "" "a"

we get the following error:

Left (line 1, column 1):
unexpected "a"
expecting "b"

What happened is that char 'a' succeeded by consuming the 'a' from the
input and then lookAhead rewinded the input stream (as it does on
success). Then, char 'b' tries to parse (again) the first character of
the input and fails. Everything works as expected.

Now let's slightly modify our parser:

  p' = lookAhead (many1 $ char 'a') >> char 'b'

I've only added a many1. I was expecting this parser to give the same
error as the previous one: many1 $ char 'a' will succeed consuming one
'a' and then lookAhead will rewind the input (as it does on success).
Thus when we call char 'b' we are going to be in the beginning of the
input again. Well, that doesn't happen:

Left (line 1, column 2):
unexpected end of input
expecting "b"

As you can see, lookAhead did not rewind the input as it was supposed to.

From reuleaux at web.de  Thu Aug  7 16:32:11 2014
From: reuleaux at web.de (Andreas Reuleaux)
Date: Thu, 07 Aug 2014 17:32:11 +0100
Subject: [Haskell-cafe] parsec: problem combining lookAhead with many1
	(bug?)
In-Reply-To: <CAMmzbfWA9S3YGjJ1iQaa72rKZyuV4psvEP3LsQuDGC3QED-YVw@mail.gmail.com>
 (silly's message of "Thu, 7 Aug 2014 15:25:23 +0100")
References: <CAMmzbfWA9S3YGjJ1iQaa72rKZyuV4psvEP3LsQuDGC3QED-YVw@mail.gmail.com>
Message-ID: <87y4v0z2es.fsf@web.de>

While I haven't tried out your example in parsec, I can at least confirm
that in trifecta it does work that way you expect it, ie. there is no
difference between the error messages in both of your cases:
(parsec's many1 = trifecta's some)


Prelude > :m +Text.Trifecta
Prelude Text.Trifecta > :m +Text.Parser.LookAhead
Prelude Text.Trifecta Text.Parser.LookAhead >
...
Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (char 'a') >> char 'b') "a"
...
Loading package reducers-3.10.2.1 ... linking ... done.
Loading package trifecta-1.5.1 ... linking ... done.
(interactive):1:1: error: expected: "b"
a<EOF> 
^      
Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (some $ char 'a') >> char 'b') "a"
(interactive):1:1: error: expected: "b"
a<EOF> 
^      
Prelude Text.Trifecta Text.Parser.LookAhead > 


Hope this helps.

-Andreas




silly8888 <silly8888 at gmail.com> writes:

> Suppose that we have the following parser:
>
>   p = lookAhead (char 'a') >> char 'b'
>
> If we use it like so
>
>   parse p "" "a"
>
> we get the following error:
>
> Left (line 1, column 1):
> unexpected "a"
> expecting "b"
>
> What happened is that char 'a' succeeded by consuming the 'a' from the
> input and then lookAhead rewinded the input stream (as it does on
> success). Then, char 'b' tries to parse (again) the first character of
> the input and fails. Everything works as expected.
>
> Now let's slightly modify our parser:
>
>   p' = lookAhead (many1 $ char 'a') >> char 'b'
>
> I've only added a many1. I was expecting this parser to give the same
> error as the previous one: many1 $ char 'a' will succeed consuming one
> 'a' and then lookAhead will rewind the input (as it does on success).
> Thus when we call char 'b' we are going to be in the beginning of the
> input again. Well, that doesn't happen:
>
> Left (line 1, column 2):
> unexpected end of input
> expecting "b"
>
> As you can see, lookAhead did not rewind the input as it was supposed to.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From me at khanson.io  Thu Aug  7 17:57:47 2014
From: me at khanson.io (Kyle Hanson)
Date: Thu, 7 Aug 2014 10:57:47 -0700
Subject: [Haskell-cafe] Performance of StateT and best practices for
	debugging
Message-ID: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>

Hello,

I was looking at cleaning up my refactoring a core loop of template
rendering to go from a loop with many parameters

loop :: RenderConfig -> BlockMap -> InputBucket m -> Builder -> [Pieces] ->
ExceptT StrapError m Builder

to a looped state monad transformer

loop :: [Pieces] -> RenderT m Builder

newtype RenderT m a = RenderT
  { runRenderT :: ExceptT StrapError (StateT (RenderState m) m) a
  } deriving ( Functor, Applicative, Monad, MonadIO )

data RenderState m = RenderState
  { position     :: SourcePos
  , renderConfig :: RenderConfig
  , blocks       :: BlockMap
  , bucket       :: InputBucket m
  }

however, there is a big slow down (about 6-10x) using a StateT. I think it
might have something to do with laziness but I am not exactly sure of where
to begin in tracking it down. Swapping out the Lazy State to a Strict State
helps a little (only a 5x slow down)

You can find some of the processing code here:

https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/src/Text/Strapped/Render.hs#L189

With my old loop commented out.

Its messy right now since I am just trying a number of different
approaches. I did some more work factoring out the lifts, trying different
iterations of foldlM and stuff but that didn't have that much of an effect
on performance.

After profiling I see in the StateT, the report has a lot more CAFs and
garbage collecting.

Here is the profiling report from my original version w/o StateT
http://lpaste.net/108995

Slow version with StateT
http://lpaste.net/108997

Here is the "makeBucket" function that is referenced (it is the same in
both state and nonstate):

https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24

Looking at stacked overflow and the official docs I have gotten an idea of
what is going on. The heaps generated between them tells me that a lot more
memory is being allocated to lists. These heaps were generated running my
render function against a template with nested loops and a list of elements.

http://imgur.com/a/2jOIf

I am hoping that maybe someone could give me a hint at what to look at
next. I've played around with Strictness and refactoring loops to no avail
and now am kind of stuck. Any help would be appreciated.

--
Kyle Hanson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/a82b99f5/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Thu Aug  7 19:07:02 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Thu, 07 Aug 2014 21:07:02 +0200
Subject: [Haskell-cafe] [ANN] rtorrent-state 0.1.0.0
Message-ID: <53E3CE56.6090500@fuuzetsu.co.uk>

Hi,

rtorrent-state is a library that allows working with rtorrent state
files (SOMEHASH.torrent.rtorrent) placed in your session directory.

If you're an rtorrent user and ever had to manually muck around with
those files, you should be able to use this library to make your life
easier.

For example, you can stop all torrents in your session directory with
just: ?overFilesIn "rtorrent/session/dir" stopTorrent?

The way it works is by parsing the session files, modifying the
resulting data type and serialising it back into the file. I did not do
optimisation but I had no problem with test sample of 100,000 files.

I need to add IOException handling and maybe extra utility functions but
otherwise I consider the library finished.

Thanks
-- 
Mateusz K.

From jwlato at gmail.com  Thu Aug  7 22:39:53 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 7 Aug 2014 15:39:53 -0700
Subject: [Haskell-cafe] Performance of StateT and best practices for
	debugging
In-Reply-To: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>
References: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>
Message-ID: <CAJ727GjPpMn3xMDs=4EmJGG0FpndsBwvq5Zkc97X6yQ-H21KEA@mail.gmail.com>

I haven't looked very closely, but I'm suspicious of this code from
"instance Block Piece"

  ListLike l -> forM l (\obj -> ...)
                    >>= (return . mconcat)

The "forM" means that "l" will be traversed once and create an output list,
which will then be mconcat'd together.  The list has to be created because
of the monadic structure imposed by forM, but if the result of the mconcat
isn't demanded right away it will be retained as a thunk that references
the newly-created list.

I'd suggest that you replace it with something like

  ListLike l -> foldM (\(!acc) obj -> ... >>= return . mappend acc) mempty l

Here I've justed added a bang pattern to the accumulator.  If whatever is
being returned has some lazy fields, you may want to change that to use
deepseq instead of a bang pattern.

Also, "foo >>= return . bar" is often regarded as a bit of a code smell, it
can be replaced with "bar <$> foo" or "bar `liftM` foo", or sometimes
something even simpler depending on circumstances (but IMHO sometimes it's
more clear to just leave it alone).

The heap profile does look like a space leak.  The line

 <StrappedTemplates-0.1.1.0:Text.Strapped.Render.sat_sc1z>

is a thunk (you can tell because it's in '<>' brackets), so whatever is
referencing that is not strict enough.  Sometimes another heap profile
report, e.g. "-hc" or maybe "-hy" will give more useful information that
lets you identify what exactly "sat_sc1z" is.  You could also try compiling
with -ddump-stg, which will dump the intermediate STG output which usually
shows those names.  But then you'll probably also need to re-run the
profile, since the names change between compilations.  Also IIRC some of
values aren't named until the cmm phase, but that's harder to map back to
Haskell so if you can identify the code from stg it's simpler.

If you haven't seen
http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-big-programs/,
I'd highly recommend it if you need to track down a space leak.

John L.



On Thu, Aug 7, 2014 at 10:57 AM, Kyle Hanson <me at khanson.io> wrote:

> Hello,
>
> I was looking at cleaning up my refactoring a core loop of template
> rendering to go from a loop with many parameters
>
> loop :: RenderConfig -> BlockMap -> InputBucket m -> Builder -> [Pieces]
> -> ExceptT StrapError m Builder
>
> to a looped state monad transformer
>
> loop :: [Pieces] -> RenderT m Builder
>
> newtype RenderT m a = RenderT
>   { runRenderT :: ExceptT StrapError (StateT (RenderState m) m) a
>   } deriving ( Functor, Applicative, Monad, MonadIO )
>
> data RenderState m = RenderState
>   { position     :: SourcePos
>   , renderConfig :: RenderConfig
>   , blocks       :: BlockMap
>   , bucket       :: InputBucket m
>   }
>
> however, there is a big slow down (about 6-10x) using a StateT. I think it
> might have something to do with laziness but I am not exactly sure of where
> to begin in tracking it down. Swapping out the Lazy State to a Strict State
> helps a little (only a 5x slow down)
>
> You can find some of the processing code here:
>
>
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/src/Text/Strapped/Render.hs#L189
>
> With my old loop commented out.
>
> Its messy right now since I am just trying a number of different
> approaches. I did some more work factoring out the lifts, trying different
> iterations of foldlM and stuff but that didn't have that much of an effect
> on performance.
>
> After profiling I see in the StateT, the report has a lot more CAFs and
> garbage collecting.
>
> Here is the profiling report from my original version w/o StateT
> http://lpaste.net/108995
>
> Slow version with StateT
> http://lpaste.net/108997
>
> Here is the "makeBucket" function that is referenced (it is the same in
> both state and nonstate):
>
>
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24
>
> Looking at stacked overflow and the official docs I have gotten an idea of
> what is going on. The heaps generated between them tells me that a lot more
> memory is being allocated to lists. These heaps were generated running my
> render function against a template with nested loops and a list of elements.
>
> http://imgur.com/a/2jOIf
>
> I am hoping that maybe someone could give me a hint at what to look at
> next. I've played around with Strictness and refactoring loops to no avail
> and now am kind of stuck. Any help would be appreciated.
>
> --
> Kyle Hanson
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/b4c26366/attachment.html>

From zhangjun.julian at gmail.com  Fri Aug  8 03:24:29 2014
From: zhangjun.julian at gmail.com (jun zhang)
Date: Fri, 8 Aug 2014 11:24:29 +0800
Subject: [Haskell-cafe] How to improve the zipwith's performance
Message-ID: <CAGjcJLcT0FAmNxFLbdaZZfMFg5aEL1rZDPEWOpRxvsKJsau3ew@mail.gmail.com>

Dear All

I write a code for Clustering with Data.Clustering.Hierarchical, but it's
slow.

I use the profiling and change some code, but I don't know why zipwith take
so many time? (even I change list to vector)

My code is as blow, Any one kindly give me some advices.
======================
main = do
    ....
    let cluster = dendrogram  SingleLinkage vectorList getVectorDistance
    ....

getExp2 v1 v2 = d*d
    where
        d = v1 - v2

getExp v1 v2
    | v1 == v2 = 0
    | otherwise = getExp2 v1 v2

tfoldl  d = DV.foldl1' (+) d

changeDataType:: Int -> Double
changeDataType d = fromIntegral d

getVectorDistance::(a,DV.Vector Int)->(a, DV.Vector Int )->Double
getVectorDistance v1 v2 = fromIntegral $ tfoldl dat
    where
        l1 = snd v1
        l2 = snd v2
        dat = DV.zipWith getExp l1 l2

=======================================

build with ghc -prof -fprof-auto -rtsopts -O2 log_cluster.hs

run with  log_cluster.exe +RTS -p

profiling result is

 log_cluster.exe +RTS -p -RTS

    total time  =        8.43 secs   (8433 ticks @ 1000 us, 1 processor)
    total alloc = 1,614,252,224 bytes  (excludes profiling overheads)

COST CENTRE            MODULE  %time %alloc

getVectorDistance.dat  Main     49.4   37.8
tfoldl                 Main      5.7    0.0
getExp                 Main      4.5    0.0
getExp2                Main      0.5    1.5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/d29aa298/attachment.html>

From spam at scientician.net  Fri Aug  8 04:31:49 2014
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 08 Aug 2014 06:31:49 +0200
Subject: [Haskell-cafe] Performance of StateT and best practices for
	debugging
In-Reply-To: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>
References: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>
Message-ID: <ls1jrl$7gp$1@ger.gmane.org>

On 2014-08-07 19:57, Kyle Hanson wrote:
> Hello,
> 
> Here is the "makeBucket" function that is referenced (it is the same in
> both state and nonstate):
> 
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24
> 

Just a shot in the dark, but I notice that you're using "modify" and not
"modify'" which was added in a recent version of transformers.

Strict.StateT is not always "strict enough" and you may need to use modify'.

At any rate, it's worth a shot, I think.

Regards,



From me at janpaulposma.nl  Fri Aug  8 05:30:25 2014
From: me at janpaulposma.nl (Jan Paul Posma)
Date: Thu, 7 Aug 2014 22:30:25 -0700
Subject: [Haskell-cafe] Visualising Haskell function execution
Message-ID: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>

Hey all,

Last weekend my friend Steve and I did a small project for visualising
Haskell function execution in the browser. It's meant to be used in
education, and uses a tiny custom parser. I figured it could be of interest
for anyone here learning or teaching Haskell:
https://stevekrouse.github.io/hs.js/

To see it in action, scroll a bit down to the red bordered box, and click
on "map", and then keep clicking on each new line.

I hope it can be useful to someone.

Cheers, JP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/3c4dabe9/attachment.html>

From jwlato at gmail.com  Fri Aug  8 06:56:43 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 7 Aug 2014 23:56:43 -0700
Subject: [Haskell-cafe] Performance of StateT and best practices for
	debugging
In-Reply-To: <ls1jrl$7gp$1@ger.gmane.org>
References: <CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ@mail.gmail.com>
 <ls1jrl$7gp$1@ger.gmane.org>
Message-ID: <CAJ727GipLL12TXfrMBeLJBX2_GdoD0W-CKJd4U1cu48CvnkrBg@mail.gmail.com>

On Thu, Aug 7, 2014 at 9:31 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 2014-08-07 19:57, Kyle Hanson wrote:
> > Hello,
> >
> > Here is the "makeBucket" function that is referenced (it is the same in
> > both state and nonstate):
> >
> >
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24
> >
>
> Just a shot in the dark, but I notice that you're using "modify" and not
> "modify'" which was added in a recent version of transformers.
>
> Strict.StateT is not always "strict enough" and you may need to use
> modify'.
>
> At any rate, it's worth a shot, I think.
>

Good point.  I think that even modify' will not be strict enough without
adding strictness to RenderState as well.

John L.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/ce617687/attachment.html>

From nicola.gigante at gmail.com  Fri Aug  8 14:34:00 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Fri, 8 Aug 2014 16:34:00 +0200
Subject: [Haskell-cafe] Get out structured data from a C/C++ library in
	Haskell
Message-ID: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>

Hello everybody.

I'm new to the list so I'd like to say hello to you.
I'm a student of computer science and early practitioner of Haskell.

I've decided to implement the next project in Haskell but I need to
interface a C++ library. I've read all the wikis material about the matter
and I have an understanding of how FFI to C works in general.

The library in question is a SAT solver for LTL formulas, and all I need
to do is to be able to create the AST of the formula (Haskell will do the
parsing) and pass it to the library, and then get back the reply.

From the C++ point of view, the AST of the formulas consists simply
of objects linked together with raw pointers. Nodes are of the same type,
with an internal enum that specifies the type of node, so it's not an
inheritance hierarchy or fancy things...
What I would like to do is to be able to declare an algebraic data type
that represents the AST and somehow mangle it to a form that can
be passed to the C++ function of the library (that I can wrap into an
extern "C" function to be able to use it through FFI if needed).

How can I do that? In general, I've only seen example of how to exchange
primitive types with C functions through the FFI, but not for example
structures or pointers to structures.

Note that I have control over the source code of the C++ library too,
so the question includes suggestions about how to structure the C++
data as well, to ease the integration.

Thank you for your help,
Nicola

From carter.schonwald at gmail.com  Fri Aug  8 14:53:43 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 8 Aug 2014 10:53:43 -0400
Subject: [Haskell-cafe] Get out structured data from a C/C++ library in
	Haskell
In-Reply-To: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
Message-ID: <CAHYVw0ym5BjKh0w+4Hu9iCHyFzMb6nuNk=G3Gs0keC_eVwN-rg@mail.gmail.com>

if you want to see a REALLY nice example of mapping (back and forth!)
between a C++ AST and an Haskell AST, llvm-general is a pretty good role
model
http://hackage.haskell.org/package/llvm-general


On Fri, Aug 8, 2014 at 10:34 AM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Hello everybody.
>
> I'm new to the list so I'd like to say hello to you.
> I'm a student of computer science and early practitioner of Haskell.
>
> I've decided to implement the next project in Haskell but I need to
> interface a C++ library. I've read all the wikis material about the matter
> and I have an understanding of how FFI to C works in general.
>
> The library in question is a SAT solver for LTL formulas, and all I need
> to do is to be able to create the AST of the formula (Haskell will do the
> parsing) and pass it to the library, and then get back the reply.
>
> From the C++ point of view, the AST of the formulas consists simply
> of objects linked together with raw pointers. Nodes are of the same type,
> with an internal enum that specifies the type of node, so it's not an
> inheritance hierarchy or fancy things...
> What I would like to do is to be able to declare an algebraic data type
> that represents the AST and somehow mangle it to a form that can
> be passed to the C++ function of the library (that I can wrap into an
> extern "C" function to be able to use it through FFI if needed).
>
> How can I do that? In general, I've only seen example of how to exchange
> primitive types with C functions through the FFI, but not for example
> structures or pointers to structures.
>
> Note that I have control over the source code of the C++ library too,
> so the question includes suggestions about how to structure the C++
> data as well, to ease the integration.
>
> Thank you for your help,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/35687f10/attachment.html>

From nicola.gigante at gmail.com  Fri Aug  8 15:22:57 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Fri, 8 Aug 2014 17:22:57 +0200
Subject: [Haskell-cafe] Get out structured data from a C/C++ library in
	Haskell
In-Reply-To: <CAHYVw0ym5BjKh0w+4Hu9iCHyFzMb6nuNk=G3Gs0keC_eVwN-rg@mail.gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
 <CAHYVw0ym5BjKh0w+4Hu9iCHyFzMb6nuNk=G3Gs0keC_eVwN-rg@mail.gmail.com>
Message-ID: <E6F57AAB-8449-4012-BCAA-308498C6ABE1@gmail.com>


Il giorno 08/ago/2014, alle ore 16:53, Carter Schonwald <carter.schonwald at gmail.com> ha scritto:

> if you want to see a REALLY nice example of mapping (back and forth!) between a C++ AST and an Haskell AST, llvm-general is a pretty good role model
> http://hackage.haskell.org/package/llvm-general

Thank you very much!

The source code is quite complex, given the complexities of the LLVM IR.
Any pointer to understand what's going on?

Thank you,
Nicola

From matt.w.giles at gmail.com  Fri Aug  8 15:27:15 2014
From: matt.w.giles at gmail.com (Matt Giles)
Date: Fri, 8 Aug 2014 08:27:15 -0700
Subject: [Haskell-cafe] Free monad based EDSL for writing LLVM programs.
In-Reply-To: <mailman.9.1407499203.14824.haskell-cafe@haskell.org>
References: <mailman.9.1407499203.14824.haskell-cafe@haskell.org>
Message-ID: <etPan.53e4ec53.5bd062c2.5e8@matt.local>

For transforming the code, have you checked out the uniplate package? It seems like it could fit your problem pretty well.



On 8 August, 2014 at 5:00:19 AM, haskell-cafe-request at haskell.org (haskell-cafe-request at haskell.org) wrote:

Send Haskell-Cafe mailing list submissions to 
haskell-cafe at haskell.org 

To subscribe or unsubscribe via the World Wide Web, visit 
http://www.haskell.org/mailman/listinfo/haskell-cafe 
or, via email, send a message with subject or body 'help' to 
haskell-cafe-request at haskell.org 

You can reach the person managing the list at 
haskell-cafe-owner at haskell.org 

When replying, please edit your Subject line so it is more specific 
than "Re: Contents of Haskell-Cafe digest..." 


Today's Topics: 

1. Re: Side-by-side pretty printing (J. Waldmann) 
2. Free monad based EDSL for writing LLVM programs. (arrowdodger) 
3. parsec: problem combining lookAhead with many1 (bug?) (silly8888) 
4. Re: parsec: problem combining lookAhead with many1	(bug?) 
(Andreas Reuleaux) 
5. Performance of StateT and best practices for	debugging 
(Kyle Hanson) 
6. [ANN] rtorrent-state 0.1.0.0 (Mateusz Kowalczyk) 
7. Re: Performance of StateT and best practices for	debugging 
(John Lato) 
8. How to improve the zipwith's performance (jun zhang) 
9. Re: Performance of StateT and best practices for	debugging 
(Bardur Arantsson) 
10. Visualising Haskell function execution (Jan Paul Posma) 
11. Re: Performance of StateT and best practices for	debugging 
(John Lato) 


---------------------------------------------------------------------- 

Message: 1 
Date: Thu, 7 Aug 2014 12:33:43 +0000 (UTC) 
From: J. Waldmann <waldmann at imn.htwk-leipzig.de> 
To: haskell-cafe at haskell.org 
Subject: Re: [Haskell-cafe] Side-by-side pretty printing 
Message-ID: <loom.20140807T142947-462 at post.gmane.org> 
Content-Type: text/plain; charset=us-ascii 

This is what I use 

http://autolat.imn.htwk-leipzig.de/gitweb/?p=autolib;a=blob;f=todoc/Autolib/ToDoc/Beside.hs;hb=HEAD 

it's of the works-but-looks-ugly-and-is-terribly-inefficient variety 
but since it's applied to small Docs only (like, columns of matrices), 
I don't really care. 

- J.W. 




------------------------------ 

Message: 2 
Date: Thu, 7 Aug 2014 18:16:57 +0400 
From: arrowdodger <6yearold at gmail.com> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] Free monad based EDSL for writing LLVM 
programs. 
Message-ID: 
<CALH631=EbZ8aTZi=oPdfsP97J2XrRCTf=DpX+uaZ5m9=0mxXhw at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

Hello. I'm new with Haskell and FP, so i wanted someone to give comments on 
the package i've made [1]. It's, actually, my first attempt to create 
something more or less real, so any feedback would be welcome. 

I've used Free monad to create EDSL that allows writing LLVM IR code. 
Afterwards it could be converted into pure AST structure provided by 
llvm-general-pure[2] package. Currently, it supports almost every 
instruction, but i haven't yet come up with sensible defaults for them. 

Another thing that bugs me is the ability to transform the code in syb way. 
I want take a user-supplied function that would pattern-match instruction 
and produce another code block and apply this function everywhere in the 
code, but still can't get my head around it. I've come up with extF 
function, that unlike extM, would resort to wrap instead of return, but 
that's all i've managed to do. 

Thanks in advance. 

[1] https://bitbucket.org/arrowdodger/llvm-general-edsl 
[2] http://hackage.haskell.org/package/llvm-general-pure 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/6d973f16/attachment-0001.html> 

------------------------------ 

Message: 3 
Date: Thu, 7 Aug 2014 15:25:23 +0100 
From: silly8888 <silly8888 at gmail.com> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] parsec: problem combining lookAhead with many1 
(bug?) 
Message-ID: 
<CAMmzbfWA9S3YGjJ1iQaa72rKZyuV4psvEP3LsQuDGC3QED-YVw at mail.gmail.com> 
Content-Type: text/plain; charset=UTF-8 

Suppose that we have the following parser: 

p = lookAhead (char 'a') >> char 'b' 

If we use it like so 

parse p "" "a" 

we get the following error: 

Left (line 1, column 1): 
unexpected "a" 
expecting "b" 

What happened is that char 'a' succeeded by consuming the 'a' from the 
input and then lookAhead rewinded the input stream (as it does on 
success). Then, char 'b' tries to parse (again) the first character of 
the input and fails. Everything works as expected. 

Now let's slightly modify our parser: 

p' = lookAhead (many1 $ char 'a') >> char 'b' 

I've only added a many1. I was expecting this parser to give the same 
error as the previous one: many1 $ char 'a' will succeed consuming one 
'a' and then lookAhead will rewind the input (as it does on success). 
Thus when we call char 'b' we are going to be in the beginning of the 
input again. Well, that doesn't happen: 

Left (line 1, column 2): 
unexpected end of input 
expecting "b" 

As you can see, lookAhead did not rewind the input as it was supposed to. 


------------------------------ 

Message: 4 
Date: Thu, 07 Aug 2014 17:32:11 +0100 
From: Andreas Reuleaux <reuleaux at web.de> 
To: silly8888 <silly8888 at gmail.com> 
Cc: haskell-cafe at haskell.org 
Subject: Re: [Haskell-cafe] parsec: problem combining lookAhead with 
many1	(bug?) 
Message-ID: <87y4v0z2es.fsf at web.de> 
Content-Type: text/plain 

While I haven't tried out your example in parsec, I can at least confirm 
that in trifecta it does work that way you expect it, ie. there is no 
difference between the error messages in both of your cases: 
(parsec's many1 = trifecta's some) 


Prelude > :m +Text.Trifecta 
Prelude Text.Trifecta > :m +Text.Parser.LookAhead 
Prelude Text.Trifecta Text.Parser.LookAhead > 
... 
Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (char 'a') >> char 'b') "a" 
... 
Loading package reducers-3.10.2.1 ... linking ... done. 
Loading package trifecta-1.5.1 ... linking ... done. 
(interactive):1:1: error: expected: "b" 
a<EOF> 
^ 
Prelude Text.Trifecta Text.Parser.LookAhead > parseTest (lookAhead (some $ char 'a') >> char 'b') "a" 
(interactive):1:1: error: expected: "b" 
a<EOF> 
^ 
Prelude Text.Trifecta Text.Parser.LookAhead > 


Hope this helps. 

-Andreas 




silly8888 <silly8888 at gmail.com> writes: 

> Suppose that we have the following parser: 
> 
> p = lookAhead (char 'a') >> char 'b' 
> 
> If we use it like so 
> 
> parse p "" "a" 
> 
> we get the following error: 
> 
> Left (line 1, column 1): 
> unexpected "a" 
> expecting "b" 
> 
> What happened is that char 'a' succeeded by consuming the 'a' from the 
> input and then lookAhead rewinded the input stream (as it does on 
> success). Then, char 'b' tries to parse (again) the first character of 
> the input and fails. Everything works as expected. 
> 
> Now let's slightly modify our parser: 
> 
> p' = lookAhead (many1 $ char 'a') >> char 'b' 
> 
> I've only added a many1. I was expecting this parser to give the same 
> error as the previous one: many1 $ char 'a' will succeed consuming one 
> 'a' and then lookAhead will rewind the input (as it does on success). 
> Thus when we call char 'b' we are going to be in the beginning of the 
> input again. Well, that doesn't happen: 
> 
> Left (line 1, column 2): 
> unexpected end of input 
> expecting "b" 
> 
> As you can see, lookAhead did not rewind the input as it was supposed to. 
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskell-Cafe at haskell.org 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 


------------------------------ 

Message: 5 
Date: Thu, 7 Aug 2014 10:57:47 -0700 
From: Kyle Hanson <me at khanson.io> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] Performance of StateT and best practices for 
debugging 
Message-ID: 
<CAMJUouBqFbSi+ifFsbYdXpba7pPVoP8BkyZxZaUoqLNuHc7VzQ at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

Hello, 

I was looking at cleaning up my refactoring a core loop of template 
rendering to go from a loop with many parameters 

loop :: RenderConfig -> BlockMap -> InputBucket m -> Builder -> [Pieces] -> 
ExceptT StrapError m Builder 

to a looped state monad transformer 

loop :: [Pieces] -> RenderT m Builder 

newtype RenderT m a = RenderT 
{ runRenderT :: ExceptT StrapError (StateT (RenderState m) m) a 
} deriving ( Functor, Applicative, Monad, MonadIO ) 

data RenderState m = RenderState 
{ position :: SourcePos 
, renderConfig :: RenderConfig 
, blocks :: BlockMap 
, bucket :: InputBucket m 
} 

however, there is a big slow down (about 6-10x) using a StateT. I think it 
might have something to do with laziness but I am not exactly sure of where 
to begin in tracking it down. Swapping out the Lazy State to a Strict State 
helps a little (only a 5x slow down) 

You can find some of the processing code here: 

https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/src/Text/Strapped/Render.hs#L189 

With my old loop commented out. 

Its messy right now since I am just trying a number of different 
approaches. I did some more work factoring out the lifts, trying different 
iterations of foldlM and stuff but that didn't have that much of an effect 
on performance. 

After profiling I see in the StateT, the report has a lot more CAFs and 
garbage collecting. 

Here is the profiling report from my original version w/o StateT 
http://lpaste.net/108995 

Slow version with StateT 
http://lpaste.net/108997 

Here is the "makeBucket" function that is referenced (it is the same in 
both state and nonstate): 

https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24 

Looking at stacked overflow and the official docs I have gotten an idea of 
what is going on. The heaps generated between them tells me that a lot more 
memory is being allocated to lists. These heaps were generated running my 
render function against a template with nested loops and a list of elements. 

http://imgur.com/a/2jOIf 

I am hoping that maybe someone could give me a hint at what to look at 
next. I've played around with Strictness and refactoring loops to no avail 
and now am kind of stuck. Any help would be appreciated. 

-- 
Kyle Hanson 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/a82b99f5/attachment-0001.html> 

------------------------------ 

Message: 6 
Date: Thu, 07 Aug 2014 21:07:02 +0200 
From: Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] [ANN] rtorrent-state 0.1.0.0 
Message-ID: <53E3CE56.6090500 at fuuzetsu.co.uk> 
Content-Type: text/plain; charset=windows-1252 

Hi, 

rtorrent-state is a library that allows working with rtorrent state 
files (SOMEHASH.torrent.rtorrent) placed in your session directory. 

If you're an rtorrent user and ever had to manually muck around with 
those files, you should be able to use this library to make your life 
easier. 

For example, you can stop all torrents in your session directory with 
just: ?overFilesIn "rtorrent/session/dir" stopTorrent? 

The way it works is by parsing the session files, modifying the 
resulting data type and serialising it back into the file. I did not do 
optimisation but I had no problem with test sample of 100,000 files. 

I need to add IOException handling and maybe extra utility functions but 
otherwise I consider the library finished. 

Thanks 
-- 
Mateusz K. 


------------------------------ 

Message: 7 
Date: Thu, 7 Aug 2014 15:39:53 -0700 
From: John Lato <jwlato at gmail.com> 
To: Kyle Hanson <me at khanson.io> 
Cc: haskell-cafe <haskell-cafe at haskell.org> 
Subject: Re: [Haskell-cafe] Performance of StateT and best practices 
for	debugging 
Message-ID: 
<CAJ727GjPpMn3xMDs=4EmJGG0FpndsBwvq5Zkc97X6yQ-H21KEA at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

I haven't looked very closely, but I'm suspicious of this code from 
"instance Block Piece" 

ListLike l -> forM l (\obj -> ...) 
>>= (return . mconcat) 

The "forM" means that "l" will be traversed once and create an output list, 
which will then be mconcat'd together. The list has to be created because 
of the monadic structure imposed by forM, but if the result of the mconcat 
isn't demanded right away it will be retained as a thunk that references 
the newly-created list. 

I'd suggest that you replace it with something like 

ListLike l -> foldM (\(!acc) obj -> ... >>= return . mappend acc) mempty l 

Here I've justed added a bang pattern to the accumulator. If whatever is 
being returned has some lazy fields, you may want to change that to use 
deepseq instead of a bang pattern. 

Also, "foo >>= return . bar" is often regarded as a bit of a code smell, it 
can be replaced with "bar <$> foo" or "bar `liftM` foo", or sometimes 
something even simpler depending on circumstances (but IMHO sometimes it's 
more clear to just leave it alone). 

The heap profile does look like a space leak. The line 

<StrappedTemplates-0.1.1.0:Text.Strapped.Render.sat_sc1z> 

is a thunk (you can tell because it's in '<>' brackets), so whatever is 
referencing that is not strict enough. Sometimes another heap profile 
report, e.g. "-hc" or maybe "-hy" will give more useful information that 
lets you identify what exactly "sat_sc1z" is. You could also try compiling 
with -ddump-stg, which will dump the intermediate STG output which usually 
shows those names. But then you'll probably also need to re-run the 
profile, since the names change between compilations. Also IIRC some of 
values aren't named until the cmm phase, but that's harder to map back to 
Haskell so if you can identify the code from stg it's simpler. 

If you haven't seen 
http://blog.ezyang.com/2011/06/pinpointing-space-leaks-in-big-programs/, 
I'd highly recommend it if you need to track down a space leak. 

John L. 



On Thu, Aug 7, 2014 at 10:57 AM, Kyle Hanson <me at khanson.io> wrote: 

> Hello, 
> 
> I was looking at cleaning up my refactoring a core loop of template 
> rendering to go from a loop with many parameters 
> 
> loop :: RenderConfig -> BlockMap -> InputBucket m -> Builder -> [Pieces] 
> -> ExceptT StrapError m Builder 
> 
> to a looped state monad transformer 
> 
> loop :: [Pieces] -> RenderT m Builder 
> 
> newtype RenderT m a = RenderT 
> { runRenderT :: ExceptT StrapError (StateT (RenderState m) m) a 
> } deriving ( Functor, Applicative, Monad, MonadIO ) 
> 
> data RenderState m = RenderState 
> { position :: SourcePos 
> , renderConfig :: RenderConfig 
> , blocks :: BlockMap 
> , bucket :: InputBucket m 
> } 
> 
> however, there is a big slow down (about 6-10x) using a StateT. I think it 
> might have something to do with laziness but I am not exactly sure of where 
> to begin in tracking it down. Swapping out the Lazy State to a Strict State 
> helps a little (only a 5x slow down) 
> 
> You can find some of the processing code here: 
> 
> 
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/src/Text/Strapped/Render.hs#L189 
> 
> With my old loop commented out. 
> 
> Its messy right now since I am just trying a number of different 
> approaches. I did some more work factoring out the lifts, trying different 
> iterations of foldlM and stuff but that didn't have that much of an effect 
> on performance. 
> 
> After profiling I see in the StateT, the report has a lot more CAFs and 
> garbage collecting. 
> 
> Here is the profiling report from my original version w/o StateT 
> http://lpaste.net/108995 
> 
> Slow version with StateT 
> http://lpaste.net/108997 
> 
> Here is the "makeBucket" function that is referenced (it is the same in 
> both state and nonstate): 
> 
> 
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24 
> 
> Looking at stacked overflow and the official docs I have gotten an idea of 
> what is going on. The heaps generated between them tells me that a lot more 
> memory is being allocated to lists. These heaps were generated running my 
> render function against a template with nested loops and a list of elements. 
> 
> http://imgur.com/a/2jOIf 
> 
> I am hoping that maybe someone could give me a hint at what to look at 
> next. I've played around with Strictness and refactoring loops to no avail 
> and now am kind of stuck. Any help would be appreciated. 
> 
> -- 
> Kyle Hanson 
> 
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskell-Cafe at haskell.org 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
> 
> 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/b4c26366/attachment-0001.html> 

------------------------------ 

Message: 8 
Date: Fri, 8 Aug 2014 11:24:29 +0800 
From: jun zhang <zhangjun.julian at gmail.com> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] How to improve the zipwith's performance 
Message-ID: 
<CAGjcJLcT0FAmNxFLbdaZZfMFg5aEL1rZDPEWOpRxvsKJsau3ew at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

Dear All 

I write a code for Clustering with Data.Clustering.Hierarchical, but it's 
slow. 

I use the profiling and change some code, but I don't know why zipwith take 
so many time? (even I change list to vector) 

My code is as blow, Any one kindly give me some advices. 
====================== 
main = do 
.... 
let cluster = dendrogram SingleLinkage vectorList getVectorDistance 
.... 

getExp2 v1 v2 = d*d 
where 
d = v1 - v2 

getExp v1 v2 
| v1 == v2 = 0 
| otherwise = getExp2 v1 v2 

tfoldl d = DV.foldl1' (+) d 

changeDataType:: Int -> Double 
changeDataType d = fromIntegral d 

getVectorDistance::(a,DV.Vector Int)->(a, DV.Vector Int )->Double 
getVectorDistance v1 v2 = fromIntegral $ tfoldl dat 
where 
l1 = snd v1 
l2 = snd v2 
dat = DV.zipWith getExp l1 l2 

======================================= 

build with ghc -prof -fprof-auto -rtsopts -O2 log_cluster.hs 

run with log_cluster.exe +RTS -p 

profiling result is 

log_cluster.exe +RTS -p -RTS 

total time = 8.43 secs (8433 ticks @ 1000 us, 1 processor) 
total alloc = 1,614,252,224 bytes (excludes profiling overheads) 

COST CENTRE MODULE %time %alloc 

getVectorDistance.dat Main 49.4 37.8 
tfoldl Main 5.7 0.0 
getExp Main 4.5 0.0 
getExp2 Main 0.5 1.5 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/d29aa298/attachment-0001.html> 

------------------------------ 

Message: 9 
Date: Fri, 08 Aug 2014 06:31:49 +0200 
From: Bardur Arantsson <spam at scientician.net> 
To: haskell-cafe at haskell.org 
Subject: Re: [Haskell-cafe] Performance of StateT and best practices 
for	debugging 
Message-ID: <ls1jrl$7gp$1 at ger.gmane.org> 
Content-Type: text/plain; charset=utf-8 

On 2014-08-07 19:57, Kyle Hanson wrote: 
> Hello, 
> 
> Here is the "makeBucket" function that is referenced (it is the same in 
> both state and nonstate): 
> 
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24 
> 

Just a shot in the dark, but I notice that you're using "modify" and not 
"modify'" which was added in a recent version of transformers. 

Strict.StateT is not always "strict enough" and you may need to use modify'. 

At any rate, it's worth a shot, I think. 

Regards, 




------------------------------ 

Message: 10 
Date: Thu, 7 Aug 2014 22:30:25 -0700 
From: Jan Paul Posma <me at janpaulposma.nl> 
To: haskell-cafe at haskell.org 
Subject: [Haskell-cafe] Visualising Haskell function execution 
Message-ID: 
<CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

Hey all, 

Last weekend my friend Steve and I did a small project for visualising 
Haskell function execution in the browser. It's meant to be used in 
education, and uses a tiny custom parser. I figured it could be of interest 
for anyone here learning or teaching Haskell: 
https://stevekrouse.github.io/hs.js/ 

To see it in action, scroll a bit down to the red bordered box, and click 
on "map", and then keep clicking on each new line. 

I hope it can be useful to someone. 

Cheers, JP 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/3c4dabe9/attachment-0001.html> 

------------------------------ 

Message: 11 
Date: Thu, 7 Aug 2014 23:56:43 -0700 
From: John Lato <jwlato at gmail.com> 
To: Bardur Arantsson <spam at scientician.net> 
Cc: haskell-cafe <haskell-cafe at haskell.org> 
Subject: Re: [Haskell-cafe] Performance of StateT and best practices 
for	debugging 
Message-ID: 
<CAJ727GipLL12TXfrMBeLJBX2_GdoD0W-CKJd4U1cu48CvnkrBg at mail.gmail.com> 
Content-Type: text/plain; charset="utf-8" 

On Thu, Aug 7, 2014 at 9:31 PM, Bardur Arantsson <spam at scientician.net> 
wrote: 

> On 2014-08-07 19:57, Kyle Hanson wrote: 
> > Hello, 
> > 
> > Here is the "makeBucket" function that is referenced (it is the same in 
> > both state and nonstate): 
> > 
> > 
> https://github.com/hansonkd/StrappedTemplates/blob/321a88168d54943fc217553c873f188797c0d4f5/examples/big_example.hs#L24 
> > 
> 
> Just a shot in the dark, but I notice that you're using "modify" and not 
> "modify'" which was added in a recent version of transformers. 
> 
> Strict.StateT is not always "strict enough" and you may need to use 
> modify'. 
> 
> At any rate, it's worth a shot, I think. 
> 

Good point. I think that even modify' will not be strict enough without 
adding strictness to RenderState as well. 

John L. 
-------------- next part -------------- 
An HTML attachment was scrubbed... 
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140807/ce617687/attachment-0001.html> 

------------------------------ 

Subject: Digest Footer 

_______________________________________________ 
Haskell-Cafe mailing list 
Haskell-Cafe at haskell.org 
http://www.haskell.org/mailman/listinfo/haskell-cafe 


------------------------------ 

End of Haskell-Cafe Digest, Vol 132, Issue 11 
********************************************* 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/23dbf2aa/attachment.html>

From donn at avvanta.com  Fri Aug  8 15:29:21 2014
From: donn at avvanta.com (Donn Cave)
Date: Fri,  8 Aug 2014 08:29:21 -0700 (PDT)
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
Message-ID: <20140808152921.C0E35F3935@mail.avvanta.com>

> How can I do that? In general, I've only seen example of how to exchange
> primitive types with C functions through the FFI, but not for example
> structures or pointers to structures.

Foreign.Storable is the key to packing and unpacking a struct.  The
hsc2hs utility adds some support for struct member names, which will
make your code more convenient and robust.  You will also find "peek"
and "poke" functions in Foreign.Storable, for pointer access.

	Donn

From djsamperi at gmail.com  Fri Aug  8 15:52:38 2014
From: djsamperi at gmail.com (Dominick Samperi)
Date: Fri, 8 Aug 2014 11:52:38 -0400
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
Message-ID: <CADUbQ5i909x=FcSO61kmozTLNeodUwE+QauW9nu7cac3dtooag@mail.gmail.com>

If I recall correctly the Leksah IDE shows GHC reduction step-by-step
(using GHC debug info). Unfortunately, the last update was in 2012, so
it appears
that it has not been following the latest GHC releases.

On Fri, Aug 8, 2014 at 1:30 AM, Jan Paul Posma <me at janpaulposma.nl> wrote:
> Hey all,
>
> Last weekend my friend Steve and I did a small project for visualising
> Haskell function execution in the browser. It's meant to be used in
> education, and uses a tiny custom parser. I figured it could be of interest
> for anyone here learning or teaching Haskell:
> https://stevekrouse.github.io/hs.js/
>
> To see it in action, scroll a bit down to the red bordered box, and click on
> "map", and then keep clicking on each new line.
>
> I hope it can be useful to someone.
>
> Cheers, JP
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From nicola.gigante at gmail.com  Fri Aug  8 17:51:16 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Fri, 8 Aug 2014 19:51:16 +0200
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <20140808152921.C0E35F3935@mail.avvanta.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
 <20140808152921.C0E35F3935@mail.avvanta.com>
Message-ID: <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>


Il giorno 08/ago/2014, alle ore 17:29, Donn Cave <donn at avvanta.com> ha scritto:

>> How can I do that? In general, I've only seen example of how to exchange
>> primitive types with C functions through the FFI, but not for example
>> structures or pointers to structures.
> 
> Foreign.Storable is the key to packing and unpacking a struct.  The
> hsc2hs utility adds some support for struct member names, which will
> make your code more convenient and robust.  You will also find "peek"
> and "poke" functions in Foreign.Storable, for pointer access.

Thanks! 

Is this the approach used by the llvm-general library?
Moreover, I see that peek and poke return IO a, so I 
can't pretend that the interface that I'm wrapping is pure,
can I?

Nicola


From hesselink at gmail.com  Fri Aug  8 18:45:43 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Fri, 8 Aug 2014 20:45:43 +0200
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
 <20140808152921.C0E35F3935@mail.avvanta.com>
 <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
Message-ID: <CAPeieQG+TDffD2TuZEW8gz=jXaJzw5+EON-naf1PiiSO8k-gbA@mail.gmail.com>

On Fri, Aug 8, 2014 at 7:51 PM, Nicola Gigante <nicola.gigante at gmail.com> wrote:
> Moreover, I see that peek and poke return IO a, so I
> can't pretend that the interface that I'm wrapping is pure,
> can I?

I believe that providing a pure interface to FFI functions was in fact
the reason unsafePerformIO was introduced. So if you know the function
you're wrapping is in fact pure, you can use it to provide a pure
Haskell interface to it.

Erik

From carter.schonwald at gmail.com  Fri Aug  8 19:43:14 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 8 Aug 2014 15:43:14 -0400
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <CAPeieQG+TDffD2TuZEW8gz=jXaJzw5+EON-naf1PiiSO8k-gbA@mail.gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
 <20140808152921.C0E35F3935@mail.avvanta.com>
 <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
 <CAPeieQG+TDffD2TuZEW8gz=jXaJzw5+EON-naf1PiiSO8k-gbA@mail.gmail.com>
Message-ID: <CAHYVw0yfkeezha86OgXui=7K-3p61x8oHpLDERR9b5v9veDDOw@mail.gmail.com>

yup! But first write it correctly then make it pretty :)


On Fri, Aug 8, 2014 at 2:45 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> On Fri, Aug 8, 2014 at 7:51 PM, Nicola Gigante <nicola.gigante at gmail.com>
> wrote:
> > Moreover, I see that peek and poke return IO a, so I
> > can't pretend that the interface that I'm wrapping is pure,
> > can I?
>
> I believe that providing a pure interface to FFI functions was in fact
> the reason unsafePerformIO was introduced. So if you know the function
> you're wrapping is in fact pure, you can use it to provide a pure
> Haskell interface to it.
>
> Erik
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/89f28872/attachment.html>

From ky3 at atamo.com  Fri Aug  8 21:35:12 2014
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Sat, 9 Aug 2014 04:35:12 +0700
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
Message-ID: <CAPY+ZdRHkxetNLnVPLeb_m1ZYAvZc4uFEgpQbCELpfFPFbesVw@mail.gmail.com>

On Fri, Aug 8, 2014 at 12:30 PM, Jan Paul Posma <me at janpaulposma.nl> wrote:

> Last weekend my friend Steve and I did a small project for visualising
> Haskell function execution in the browser. It's meant to be used in
> education, and uses a tiny custom parser. I figured it could be of interest
> for anyone here learning or teaching Haskell:
> https://stevekrouse.github.io/hs.js/
>

Mind if I suggest posting to the haskell reddit /r/haskell ?

Tons of people would find it useful there and share it forward.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/d55b8314/attachment.html>

From donn at avvanta.com  Fri Aug  8 21:48:12 2014
From: donn at avvanta.com (Donn Cave)
Date: Fri,  8 Aug 2014 14:48:12 -0700 (PDT)
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
References: <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
Message-ID: <20140808214812.36FC2276C41@mail.avvanta.com>

Nicola Gigante <nicola.gigante at gmail.com>,
> Il giorno 08/ago/2014, alle ore 17:29, Donn Cave <donn at avvanta.com> ha scritto:
>> Foreign.Storable is the key to packing and unpacking a struct.  The
>> hsc2hs utility adds some support for struct member names, which will
>> make your code more convenient and robust.  You will also find "peek"
>> and "poke" functions in Foreign.Storable, for pointer access.

...
> Moreover, I see that peek and poke return IO a, so I 
> can't pretend that the interface that I'm wrapping is pure,
> can I?

Funny you should ask ... I just happened to notice something about
pretending an external function is pure, in the library documentation
for Foreign.Marshall.unsafeLocalState.  I can't say for sure whether
it would serve your purpose here or not - the documentation could be
read to say it does, anyway, and the function signature is IO a -> a.

I meant to say, about hsc2hs, documentation can be found in the
GHC user manual, chapter 12 or thereabouts.

	Donn

From me at janpaulposma.nl  Fri Aug  8 23:18:04 2014
From: me at janpaulposma.nl (Jan Paul Posma)
Date: Fri, 8 Aug 2014 16:18:04 -0700
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CAPY+ZdRHkxetNLnVPLeb_m1ZYAvZc4uFEgpQbCELpfFPFbesVw@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
 <CAPY+ZdRHkxetNLnVPLeb_m1ZYAvZc4uFEgpQbCELpfFPFbesVw@mail.gmail.com>
Message-ID: <CAPtY9n+Sz1nEhrJgXiha4rWmU-YAv+scgkU6Y-ynHoAWoc3aAQ@mail.gmail.com>

Of course, thanks!

Also, the code is open source and can easily be used in other courses, that
page is just our example.

JP


On Fri, Aug 8, 2014 at 2:35 PM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>
> On Fri, Aug 8, 2014 at 12:30 PM, Jan Paul Posma <me at janpaulposma.nl>
> wrote:
>
>> Last weekend my friend Steve and I did a small project for visualising
>> Haskell function execution in the browser. It's meant to be used in
>> education, and uses a tiny custom parser. I figured it could be of interest
>> for anyone here learning or teaching Haskell:
>> https://stevekrouse.github.io/hs.js/
>>
>
> Mind if I suggest posting to the haskell reddit /r/haskell ?
>
> Tons of people would find it useful there and share it forward.
>
> -- Kim-Ee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140808/fddde996/attachment.html>

From jerzy.karczmarczuk at unicaen.fr  Sat Aug  9 00:06:34 2014
From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk)
Date: Sat, 09 Aug 2014 02:06:34 +0200
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CAPtY9n+Sz1nEhrJgXiha4rWmU-YAv+scgkU6Y-ynHoAWoc3aAQ@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
 <CAPY+ZdRHkxetNLnVPLeb_m1ZYAvZc4uFEgpQbCELpfFPFbesVw@mail.gmail.com>
 <CAPtY9n+Sz1nEhrJgXiha4rWmU-YAv+scgkU6Y-ynHoAWoc3aAQ@mail.gmail.com>
Message-ID: <53E5660A.701@unicaen.fr>

Jan Paul Posma <me at janpaulposma.nl <mailto:me at janpaulposma.nl>> wrote:

>     Last weekend my friend Steve and I did a small project for
>     visualising Haskell function execution in the browser. It's meant
>     to be used in education, and uses a tiny custom parser. I figured
>     it could be of interest for anyone here learning or teaching
>     Haskell: https://stevekrouse.github.io/hs.js/
>

Indeed, this is a nice, and potentially useful initiative, thanks.

I have some observations, though.

1. Before its "wide distribution" as suggested by Kim-Ee, it would be 
nice to provide a minimum documentation on the project page.

2. It is not always clear what is the relation between the work of the 
system, the expression expansion, and what Haskell REALLY does.
For, say: (foldr plus 0 [1 2 3 4 5]) the development/reduction depends 
on what you click. You may get

(plus1(plus2(foldrplus0[3 45]))) or
(1+(foldrplus0[2 345]))

and a beginner might have serious problems to understand what really 
happens in a true Haskell program.

3. The system accepts typing abominations, say, (foldlplus[][1 234 5]) 
and joyfully develops the structure, which cannot be finally reduced.

4. I don't understand the relation between the typing and the behaviour. 
I tested foldl with my own function put into the function editor: const 
x y = x without type declaration.
The expression is expanded, but never reduced, const remains in the 
final expression. When const type is declared, it is reduced.

5.  I tried to define my own recursive function (a factorial) and test 
it replacing one of the standard examples. This breaks the system. If it 
is not allowed, please say so explicitly. If I did something silly, 
please see my point (1).

My best regards, and thank you once more.

Jerzy Karczmarczuk
Caen, France


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/0e447503/attachment-0001.html>

From nicola.gigante at gmail.com  Sat Aug  9 07:50:52 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sat, 9 Aug 2014 09:50:52 +0200
Subject: [Haskell-cafe] Free monad based EDSL for writing LLVM programs.
In-Reply-To: <CALH631=EbZ8aTZi=oPdfsP97J2XrRCTf=DpX+uaZ5m9=0mxXhw@mail.gmail.com>
References: <CALH631=EbZ8aTZi=oPdfsP97J2XrRCTf=DpX+uaZ5m9=0mxXhw@mail.gmail.com>
Message-ID: <555E5905-B40A-41A6-ABF8-8A34B9AC50E9@gmail.com>

Il giorno 07/ago/2014, alle ore 16:16, arrowdodger <6yearold at gmail.com> ha scritto:
> 
> Hello. I'm new with Haskell and FP, so i wanted someone to give comments on the package i've made [1]. It's, actually, my first attempt to create something more or less real, so any feedback would be welcome.
> 
> I've used Free monad to create EDSL that allows writing LLVM IR code. Afterwards it could be converted into pure AST structure provided by llvm-general-pure[2] package. Currently, it supports almost every instruction, but i haven't yet come up with sensible defaults for them.
> 
> Another thing that bugs me is the ability to transform the code in syb way. I want take a user-supplied function that would pattern-match instruction and produce another code block and apply this function everywhere in the code, but still can't get my head around it. I've come up with extF function, that unlike extM, would resort to wrap instead of return, but that's all i've managed to do.

> Thanks in advance.
> 

That is great!! I think I'll try to use it in an upcoming project that will involve LLVM! I'll tell you what happens :)

Bye,
Nicola

From roma at ro-che.info  Sat Aug  9 12:57:28 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 9 Aug 2014 15:57:28 +0300
Subject: [Haskell-cafe] ANN: immortal-0.1
Message-ID: <20140809125728.GA19454@sniper>

I am pleased to announce the first release of the "immortal" package.

Immortal allows you to create threads that never die. If the action executed by
such a thread finishes or is killed by an exception, it is automatically
restarted.

Such a behavior is often desired when writing servers, so I decided to release a
package that does exactly that.

http://hackage.haskell.org/package/immortal
https://github.com/feuerbach/immortal

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/81b3b600/attachment.sig>

From gdweber at iue.edu  Sat Aug  9 19:29:02 2014
From: gdweber at iue.edu (Gregory D. Weber)
Date: Sat, 9 Aug 2014 15:29:02 -0400
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <53E5660A.701@unicaen.fr>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
 <CAPY+ZdRHkxetNLnVPLeb_m1ZYAvZc4uFEgpQbCELpfFPFbesVw@mail.gmail.com>
 <CAPtY9n+Sz1nEhrJgXiha4rWmU-YAv+scgkU6Y-ynHoAWoc3aAQ@mail.gmail.com>
 <53E5660A.701@unicaen.fr>
Message-ID: <20140809192902.GB5088@lady>

On 2014-Aug-09, Jerzy Karczmarczuk wrote:
> Jan Paul Posma <me at janpaulposma.nl <mailto:me at janpaulposma.nl>> wrote:
> 
> >    Last weekend my friend Steve and I did a small project for
> >    visualising Haskell function execution in the browser. It's meant
> >    to be used in education, and uses a tiny custom parser. I figured
> >    it could be of interest for anyone here learning or teaching
> >    Haskell: https://stevekrouse.github.io/hs.js/
> >
> 
> Indeed, this is a nice, and potentially useful initiative, thanks.
> 
> I have some observations, though.
> 
> 1. Before its "wide distribution" as suggested by Kim-Ee, it would
> be nice to provide a minimum documentation on the project page.
> 
> 2. It is not always clear what is the relation between the work of
> the system, the expression expansion, and what Haskell REALLY does.
> For, say: (foldr plus 0 [1 2 3 4 5]) the development/reduction
> depends on what you click. You may get
> 
> (plus1(plus2(foldrplus0[3 45]))) or
> (1+(foldrplus0[2 345]))
> 
> and a beginner might have serious problems to understand what really
> happens in a true Haskell program.
> 
> 3. The system accepts typing abominations, say, (foldlplus[][1 234
> 5]) and joyfully develops the structure, which cannot be finally
> reduced.
> 
> 4. I don't understand the relation between the typing and the
> behaviour. I tested foldl with my own function put into the function
> editor: const x y = x without type declaration.
> The expression is expanded, but never reduced, const remains in the
> final expression. When const type is declared, it is reduced.
> 
> 5.  I tried to define my own recursive function (a factorial) and
> test it replacing one of the standard examples. This breaks the
> system. If it is not allowed, please say so explicitly. If I did
> something silly, please see my point (1).

>From the pink error messages I'm seeing today (though I don't remember
seeing them yesterday when I tried something similar), it looks like
the * operator is not supported; the only numerical operators are + and - 

> 
> My best regards, and thank you once more.
> 
> Jerzy Karczmarczuk
> Caen, France
> 
> 

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


-- 
Gregory D. Weber, Ph. D.                  http://mypage.iu.edu/~gdweber/
Associate Professor of Informatics        Tel (765) 973-8420
Indiana University East                   FAX (765) 973-8550


From bob at redivi.com  Sat Aug  9 20:08:26 2014
From: bob at redivi.com (Bob Ippolito)
Date: Sat, 9 Aug 2014 13:08:26 -0700
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
Message-ID: <CACwMPm8Bpcd_+A7Bv32FtndxeOGTjw8G0abVOkNT8z_CgEZ1HA@mail.gmail.com>

On Thu, Aug 7, 2014 at 10:30 PM, Jan Paul Posma <me at janpaulposma.nl> wrote:

> Hey all,
>
> Last weekend my friend Steve and I did a small project for visualising
> Haskell function execution in the browser. It's meant to be used in
> education, and uses a tiny custom parser. I figured it could be of interest
> for anyone here learning or teaching Haskell:
> https://stevekrouse.github.io/hs.js/
>
> To see it in action, scroll a bit down to the red bordered box, and click
> on "map", and then keep clicking on each new line.
>
> I hope it can be useful to someone.
>

Thanks for posting this! It looks potentially quite useful, especially in
an educational context. I think the part that's missing for me is that it
doesn't make it so explicit that pattern matching is what typically forces
evaluation, here you simply decide where to evaluate by clicking on that
part of the term. Maybe there could be an implicit "print" forcing
evaluation or something like that could be useful?

-bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/2bb6ae8a/attachment.html>

From mark.lentczner at gmail.com  Sat Aug  9 22:28:47 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sat, 9 Aug 2014 18:28:47 -0400
Subject: [Haskell-cafe] Haskell Platform 2014.2.0.0 is Released!
Message-ID: <CAAOoiFbWCLZzmvkeW7Lzw6CLf8p5aFqR214koDBPGgFJg1k0hw@mail.gmail.com>

On behalf of the Haskell Platform team, I'm happy to announce the release of

*Haskell Platform 2014.2.0.0*
featuring:

GHC 7.8.3
53 packages
860+ public modules
4 tools


This release features a major upgrade to OpenGL and GLUT. In addition,
"behind the scenes", this release of the platform is produced with a new
build system, and many improvements to the installations on all three OS
families.

Get it now:

Download Haskell Platform <http://www.haskell.org/platform/>
? for Windows <http://www.haskell.org/platform/windows.html>
? for Mac OS X <http://www.haskell.org/platform/mac.html>
? for Linux <http://www.haskell.org/platform/linux.html> (and similar
systems)


N.B.: You may need to explicitly re-fresh those links when visiting in your
browser - those pages tend to get cached for very long periods of time.

? Mark "platform wrangler" Lentczner

P.S.: I realize this one was a long time a'comin'. I take the
responsibility for the decisions that lead up to being this late, including
deciding it was worth it to wait for GHC 7.8, and that this was the right
time to re-write the platform build system. I hope the speed that we can
now turn the platform will be evident in future releases.

Haskell Platform is created by a team of many hands. Special call out to
Randy Polen for the new Windows build, and Yitzchak Gale and Neil Mitchell
for help with the new build system. Thanks also to all the intrepid folks
that tried out the early alphas and release candidates. Additional help is
always welcome!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/00a5b71c/attachment.html>

From hjgtuyl at chello.nl  Sat Aug  9 22:54:16 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Sun, 10 Aug 2014 00:54:16 +0200
Subject: [Haskell-cafe] Haskell Platform 2014.2.0.0 is Released!
In-Reply-To: <CAAOoiFbWCLZzmvkeW7Lzw6CLf8p5aFqR214koDBPGgFJg1k0hw@mail.gmail.com>
References: <CAAOoiFbWCLZzmvkeW7Lzw6CLf8p5aFqR214koDBPGgFJg1k0hw@mail.gmail.com>
Message-ID: <op.xkckkuippz0j5l@alquantor>

On Sun, 10 Aug 2014 00:28:47 +0200, Mark Lentczner  
<mark.lentczner at gmail.com> wrote:

> On behalf of the Haskell Platform team, I'm happy to announce the  
> release of
>
> *Haskell Platform 2014.2.0.0*
:
> Download Haskell Platform <http://www.haskell.org/platform/>
> ? for Windows <http://www.haskell.org/platform/windows.html>
> ? for Mac OS X <http://www.haskell.org/platform/mac.html>
> ? for Linux <http://www.haskell.org/platform/linux.html> (and similar
> systems)

The links on these pages are missing ".0" in several places, they should  
be:
http://www.haskell.org/platform/download/2014.2.0.0/HaskellPlatform-2014.2.0.0-i386-setup.exe
http://www.haskell.org/platform/download/2014.2.0.0/HaskellPlatform-2014.2.0.0-x86_64-setup.exe

http://www.haskell.org/platform/download/2014.2.0.0/Haskell%20Platform%202014.2.0.0%2064bit.signed.pkg

http://www.haskell.org/platform/download/2014.2.0.0/haskell-platform-2014.2.0.0-unknown-linux-x86_64.tar.gz

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 mark.lentczner at gmail.com  Sat Aug  9 23:01:13 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sat, 9 Aug 2014 19:01:13 -0400
Subject: [Haskell-cafe] Haskell Platform 2014.2.0.0 is Released!
In-Reply-To: <op.xkckkuippz0j5l@alquantor>
References: <CAAOoiFbWCLZzmvkeW7Lzw6CLf8p5aFqR214koDBPGgFJg1k0hw@mail.gmail.com>
 <op.xkckkuippz0j5l@alquantor>
Message-ID: <CAAOoiFben63JBMwv6h8_wow4HHki1JHZBf28=zAYgD0hRH6qXg@mail.gmail.com>

Thanks for the quick catch... All links fixed. You may need to refresh in
your browser.

- Mark
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140809/9786cae2/attachment.html>

From christian at ponies.io  Sun Aug 10 05:35:48 2014
From: christian at ponies.io (Christian Marie)
Date: Sun, 10 Aug 2014 15:35:48 +1000
Subject: [Haskell-cafe] ANN: immortal-0.1
In-Reply-To: <20140809125728.GA19454@sniper>
References: <20140809125728.GA19454@sniper>
Message-ID: <20140810053548.GA2901@cucumber.iiNet>

On Sat, Aug 09, 2014 at 03:57:28PM +0300, Roman Cheplyaka wrote:
> I am pleased to announce the first release of the "immortal" package.
> 
> Immortal allows you to create threads that never die. If the action executed by
> such a thread finishes or is killed by an exception, it is automatically
> restarted.
> 
> Such a behavior is often desired when writing servers, so I decided to release a
> package that does exactly that.
> 
> http://hackage.haskell.org/package/immortal
> https://github.com/feuerbach/immortal

This is excellent! I've written this myself a few times now and it's always
fiddly. Thank you.

I'll almost certainly use this, after a bit of review.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140810/66ef4488/attachment.sig>

From nicola.gigante at gmail.com  Sun Aug 10 13:31:29 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 10 Aug 2014 15:31:29 +0200
Subject: [Haskell-cafe] Get out structured data from a C/C++ library
	inHaskell
In-Reply-To: <CAPeieQG+TDffD2TuZEW8gz=jXaJzw5+EON-naf1PiiSO8k-gbA@mail.gmail.com>
References: <155770D5-D596-4F49-BF9C-CAE28BAEE795@gmail.com>
 <20140808152921.C0E35F3935@mail.avvanta.com>
 <5CDCABE0-4CEA-4BFE-ABEE-BC4F97C8969A@gmail.com>
 <CAPeieQG+TDffD2TuZEW8gz=jXaJzw5+EON-naf1PiiSO8k-gbA@mail.gmail.com>
Message-ID: <30E44A49-75E8-4313-85F1-798462E8EDFD@gmail.com>


Il giorno 08/ago/2014, alle ore 20:45, Erik Hesselink <hesselink at gmail.com> ha scritto:

> On Fri, Aug 8, 2014 at 7:51 PM, Nicola Gigante <nicola.gigante at gmail.com> wrote:
>> Moreover, I see that peek and poke return IO a, so I
>> can't pretend that the interface that I'm wrapping is pure,
>> can I?
> 
> I believe that providing a pure interface to FFI functions was in fact
> the reason unsafePerformIO was introduced. So if you know the function
> you're wrapping is in fact pure, you can use it to provide a pure
> Haskell interface to it.
> 

Yes it makes sense, thank you :)

> Erik

Nicola

From martin.drautzburg at web.de  Sun Aug 10 18:20:50 2014
From: martin.drautzburg at web.de (martin)
Date: Sun, 10 Aug 2014 20:20:50 +0200
Subject: [Haskell-cafe] Irritating Referential Transparency behavior?
Message-ID: <53E7B802.5030006@web.de>

Hello all,

I came across something strange:

This code compiles:

------------------------------------------------------------
data LProcess a = LP {lstep :: Writer [String] (Event a -> ([Event a], LProcess a))}
------------------------------------------------------------

exProcess2 :: ProcState -> Location -> LProcess EvtData
exProcess2 pState loc = LP {lstep = xxx}
        where
            xxx = myStep pState
            myStep _ = return $ \(E t l _) ->  ([E (t+1) l Wakeup], (proc' pState))
            proc' state = exProcess2 (trc state) loc


but when I replace xxx by myStep pState as in

exProcess2 pState loc = LP {lstep = myStep pState}
        where
            xxx = myStep pState
            myStep _ = return $ \(E t l _) ->  ([E (t+1) l Wakeup], (proc' pState))
            proc' state = exProcess2 (trc state) loc

I get

    No instance for (Monad m0) arising from a use of `myStep'
    The type variable `m0' is ambiguous
    Possible fix: add a type signature that fixes these type variable(s)

It compiles again when I remove the xxx = line. Why is that so?

From allbery.b at gmail.com  Sun Aug 10 18:36:59 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 10 Aug 2014 14:36:59 -0400
Subject: [Haskell-cafe] Irritating Referential Transparency behavior?
In-Reply-To: <53E7B802.5030006@web.de>
References: <53E7B802.5030006@web.de>
Message-ID: <CAKFCL4XEgwqpj0i1hRykRXOdFiyDpf2whsgKQJUHZz4wtASiDQ@mail.gmail.com>

On Sun, Aug 10, 2014 at 2:20 PM, martin <martin.drautzburg at web.de> wrote:

> but when I replace xxx by myStep pState as in
>
> exProcess2 pState loc = LP {lstep = myStep pState}
>         where
>             xxx = myStep pState
>             myStep _ = return $ \(E t l _) ->  ([E (t+1) l Wakeup], (proc'
> pState))
>             proc' state = exProcess2 (trc state) loc
>
> I get
>
>     No instance for (Monad m0) arising from a use of `myStep'
>     The type variable `m0' is ambiguous
>     Possible fix: add a type signature that fixes these type variable(s)
>
> It compiles again when I remove the xxx = line. Why is that so?
>

It has to assign some kind of concrete type to `xxx`. If you are using it
as in the example I elided, it has enough information to type it; if you do
not have it at all, it obviously does not need to type it; if you define it
but do not use it, it doesn't know it should ignore the definition (being
an unused local binding, this is safe) and dies trying to infer a type for
it anyway. Referential transparency is not involved (except perhaps
incidentally).

If there is a bug here, it is that it doesn't recognize that it should
simply drop/ignore (with a warning) the definition of `xxx` because it's
not reachable. Arguably, however, that is programmer error.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140810/826f6045/attachment.html>

From trebla at vex.net  Sun Aug 10 18:52:21 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Sun, 10 Aug 2014 14:52:21 -0400
Subject: [Haskell-cafe] Irritating Referential Transparency behavior?
In-Reply-To: <53E7B802.5030006@web.de>
References: <53E7B802.5030006@web.de>
Message-ID: <53E7BF65.9070404@vex.net>

On 14-08-10 02:20 PM, martin wrote:
> exProcess2 pState loc = LP {lstep = xxx}
>          where
>              xxx = myStep pState

vs

> exProcess2 pState loc = LP {lstep = myStep pState}
>          where
>              xxx = myStep pState

The monomorphism restriction requires assigning a monomorphic 
(non-polymorphic) type to xxx. The assignment could come from declaring 
xxx's type (which you didn't do) or inferring from use sites (which you 
had in one example but not in another). When both are lacking, a job 
that needs done can't be done, and it is an error.


From martin.drautzburg at web.de  Sun Aug 10 20:26:15 2014
From: martin.drautzburg at web.de (martin)
Date: Sun, 10 Aug 2014 22:26:15 +0200
Subject: [Haskell-cafe] Irritating Referential Transparency behavior?
In-Reply-To: <53E7BF65.9070404@vex.net>
References: <53E7B802.5030006@web.de> <53E7BF65.9070404@vex.net>
Message-ID: <53E7D567.3070300@web.de>

Am 08/10/2014 08:52 PM, schrieb Albert Y. C. Lai:
> On 14-08-10 02:20 PM, martin wrote:
>> exProcess2 pState loc = LP {lstep = xxx}
>>          where
>>              xxx = myStep pState
> 
> vs
> 
>> exProcess2 pState loc = LP {lstep = myStep pState}
>>          where
>>              xxx = myStep pState
> 
> The monomorphism restriction requires assigning a monomorphic (non-polymorphic) type to xxx. The assignment could come
> from declaring xxx's type (which you didn't do) or inferring from use sites (which you had in one example but not in
> another). When both are lacking, a job that needs done can't be done, and it is an error.

Very clear explanation. Thanks


From fuuzetsu at fuuzetsu.co.uk  Mon Aug 11 09:43:58 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 11 Aug 2014 11:43:58 +0200
Subject: [Haskell-cafe] Updating code to work with vinyl 0.4
Message-ID: <53E8905E.6000100@fuuzetsu.co.uk>

Hi,

I'm looking for some help in helping to migrate to vinyl-0.4 from
earlier version. I'll first outline how I currently have things set up
and then ask a few questions. For reference the whole project is at [1].
You can just skip to questions in the end if you want to.

I have a small project which goes out to a few sites, fetches some
similar XML data, parses some fields and returns a data type. My
original attempt was to generate a data type per site but that was very
ugly: couldn't reuse functions, accessors, anything. So I then turned to
vinyl and have the following solution:

I have a bunch of common fields defined like this:

--
file_url ? "file_url" ::: String
file_url = Field

parent_id ? "parent_id" ::: Maybe Integer
parent_id = Field
--
and so on.

I'm using HXT to process the XML I get from each site so I have created
many HXT arrows creating each field like this:

--
parent_idA ? (Functor (cat XmlTree), ArrowXml cat) ?
             cat XmlTree (PlainRec '["parent_id" ::: Maybe Integer])
parent_idA = (parent_id =:) . readMaybe <$> getAttrValue "parent_id"
--

Then for each site I define records like this

--
type GelbooruPost = PlainRec
  '[ "height" ::: Integer
   , "score" ::: Integer
   , "file_url" ::: String
   , "parent_id" ::: Maybe Integer
   , ?
   ]
--

and create the final HXT arrow which will parse and run my value parsers
on the whole output

--
parsePost ? (Functor (cat XmlTree), ArrowXml cat) ? cat XmlTree GelbooruPost
parsePost = hasName "post"
  >>> heightA <:+> scoreA <:+> file_urlA <:+> parent_idA <:+> sample_urlA
  <:+> sample_widthA <:+> sample_heightA <:+> preview_urlA <:+> ratingA
  <:+> tagsA <:+> idA <:+> widthA <:+> changeA <:+> md5A <:+> creator_idA
  <:+> has_childrenA <:+> created_atA <:+> statusA <:+> sourceA <:+>
has_notesA
  <:+> has_commentsA <:+> preview_widthA <:+> preview_heightA
--

This works OK: I have similar records for each site and vinyl let me use
the same accessors to work over the data from each site without much
hassle even though they all return slightly different things. But now
vinyl-0.4 is out and I have to update but I'm struggling.

As per tutorial I converted all my fields to this format:

--
data Fields = Height | Score | FileUrl | ParentId | SampleUrl | ?
--

Then generated singletons and made universe:

--
genSingletons [ ''Fields ]
makeUniverse' ''Fields "ElF"
semantics ''ElF [ 'Height :~> ''String
                , 'Score :~> ''Integer
                , 'FileUrl :~> ''String
                , 'ParentId :~> ''Integer -- Maybe Integer
                , 'SampleWidth :~> ''Integer
                , 'SampleHeight :~> ''Integer
                , 'PreviewUrl :~> ''String
                , 'Rating :~> ''Rating
                , 'Tags :~> ''String -- [String]
--

As you can see I have a problem here already: I don't know how to
specify ?Maybe Integer? or ?[String]? in the way that is accepted.
Previously I would just do "tags ::: [String]" and it worked.

I also wonder what things like:

--
PlainRec '["parent_id" ::: Maybe Integer])
--

now become. ?PlainRec ElF (ParentId ': '[])? works but is ugly, is there
a shorthand for singletons? This is assuming I can convince the ParentId
field to be Maybe Integer.

Lastly I'd like to know why trivial examples such as this

-- 
a ? PlainRec ElF (Score ': '[])
a = SScore =: 7
--

require a type signature. While I put down the signatures anyway, I
wonder if there's a way to skip them. I suppose using the field in an
annotated record somewhere might let me do this. I imagine the problem
here is that we need to specify ElF.

Perhaps I am meant to approach this whole thing differently which is why
I laid out the structure a bit rather than just asking about syntax. I
have watched the video at [2] and while the new records do sound better,
I can't find a good guide on how to use them. The tutorial on GitHub[3]
is rather lacking. If someone knows about more guides then I'd love to
hear about that too.

Thanks!

[1]: http://github.com/Fuuzetsu/h-booru
[2]: http://vimeo.com/102785458
[3]: https://github.com/VinylRecords/Vinyl/blob/master/tests/Intro.lhs

-- 
Mateusz K.

From vogt.adam at gmail.com  Mon Aug 11 15:04:47 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Mon, 11 Aug 2014 11:04:47 -0400
Subject: [Haskell-cafe] Updating code to work with vinyl 0.4
In-Reply-To: <53E8905E.6000100@fuuzetsu.co.uk>
References: <53E8905E.6000100@fuuzetsu.co.uk>
Message-ID: <CAHfjoWnT7K2u6yeZNBtK2ozwFqW19Ry_B10JJksa=R1SCxoKrw@mail.gmail.com>

Hi Mateusz,

You can write  'Foo :~> [t| Maybe String |] to make the generated code include a

  type instance App ElF Foo = Maybe String

Unfortunately the type of (:~>) includes some un-exported classes, so
you have to dig into vinyl's source to see which arguments are
actually allowed.


I'm not sure exactly what you mean by

> PlainRec ElF (ParentId ': '[])? works but is ugly

But maybe it's worth just using the Data.Vinyl.Universe.Field (ex.
http://lpaste.net/109203), if you would rather write

  PlainRec ElField '["parent_id" ::: Maybe Integer])

than,

  PlainRec ElF '[ParentId]

Or maybe you want to use Symbol together with your own universe:

  makeUniverse' ''Symbol "ElF"
  semantics ''ElF [ [t| "height" |] :~> [t| Maybe Int |] ]
  -- type instance App ElF "height" = Maybe Int -- or just write those by-hand

  height = Proxy :: Proxy "height" -- there seems to be no code
generation in Vinyl for these

which will give you a type like

  PlainRec ElF '["parent_id"]

Hopefully one of these options is not as ugly as the other.


Regards,
Adam

On Mon, Aug 11, 2014 at 5:43 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> Hi,
>
> I'm looking for some help in helping to migrate to vinyl-0.4 from
> earlier version. I'll first outline how I currently have things set up
> and then ask a few questions. For reference the whole project is at [1].
> You can just skip to questions in the end if you want to.
>
> I have a small project which goes out to a few sites, fetches some
> similar XML data, parses some fields and returns a data type. My
> original attempt was to generate a data type per site but that was very
> ugly: couldn't reuse functions, accessors, anything. So I then turned to
> vinyl and have the following solution:
>
> I have a bunch of common fields defined like this:
>
> --
> file_url ? "file_url" ::: String
> file_url = Field
>
> parent_id ? "parent_id" ::: Maybe Integer
> parent_id = Field
> --
> and so on.
>
> I'm using HXT to process the XML I get from each site so I have created
> many HXT arrows creating each field like this:
>
> --
> parent_idA ? (Functor (cat XmlTree), ArrowXml cat) ?
>              cat XmlTree (PlainRec '["parent_id" ::: Maybe Integer])
> parent_idA = (parent_id =:) . readMaybe <$> getAttrValue "parent_id"
> --
>
> Then for each site I define records like this
>
> --
> type GelbooruPost = PlainRec
>   '[ "height" ::: Integer
>    , "score" ::: Integer
>    , "file_url" ::: String
>    , "parent_id" ::: Maybe Integer
>    , ?
>    ]
> --
>
> and create the final HXT arrow which will parse and run my value parsers
> on the whole output
>
> --
> parsePost ? (Functor (cat XmlTree), ArrowXml cat) ? cat XmlTree GelbooruPost
> parsePost = hasName "post"
>   >>> heightA <:+> scoreA <:+> file_urlA <:+> parent_idA <:+> sample_urlA
>   <:+> sample_widthA <:+> sample_heightA <:+> preview_urlA <:+> ratingA
>   <:+> tagsA <:+> idA <:+> widthA <:+> changeA <:+> md5A <:+> creator_idA
>   <:+> has_childrenA <:+> created_atA <:+> statusA <:+> sourceA <:+>
> has_notesA
>   <:+> has_commentsA <:+> preview_widthA <:+> preview_heightA
> --
>
> This works OK: I have similar records for each site and vinyl let me use
> the same accessors to work over the data from each site without much
> hassle even though they all return slightly different things. But now
> vinyl-0.4 is out and I have to update but I'm struggling.
>
> As per tutorial I converted all my fields to this format:
>
> --
> data Fields = Height | Score | FileUrl | ParentId | SampleUrl | ?
> --
>
> Then generated singletons and made universe:
>
> --
> genSingletons [ ''Fields ]
> makeUniverse' ''Fields "ElF"
> semantics ''ElF [ 'Height :~> ''String
>                 , 'Score :~> ''Integer
>                 , 'FileUrl :~> ''String
>                 , 'ParentId :~> ''Integer -- Maybe Integer
>                 , 'SampleWidth :~> ''Integer
>                 , 'SampleHeight :~> ''Integer
>                 , 'PreviewUrl :~> ''String
>                 , 'Rating :~> ''Rating
>                 , 'Tags :~> ''String -- [String]
> --
>
> As you can see I have a problem here already: I don't know how to
> specify ?Maybe Integer? or ?[String]? in the way that is accepted.
> Previously I would just do "tags ::: [String]" and it worked.
>
> I also wonder what things like:
>
> --
> PlainRec '["parent_id" ::: Maybe Integer])
> --
>
> now become. ?PlainRec ElF (ParentId ': '[])? works but is ugly, is there
> a shorthand for singletons? This is assuming I can convince the ParentId
> field to be Maybe Integer.
>
> Lastly I'd like to know why trivial examples such as this
>
> --
> a ? PlainRec ElF (Score ': '[])
> a = SScore =: 7
> --
>
> require a type signature. While I put down the signatures anyway, I
> wonder if there's a way to skip them. I suppose using the field in an
> annotated record somewhere might let me do this. I imagine the problem
> here is that we need to specify ElF.
>
> Perhaps I am meant to approach this whole thing differently which is why
> I laid out the structure a bit rather than just asking about syntax. I
> have watched the video at [2] and while the new records do sound better,
> I can't find a good guide on how to use them. The tutorial on GitHub[3]
> is rather lacking. If someone knows about more guides then I'd love to
> hear about that too.
>
> Thanks!
>
> [1]: http://github.com/Fuuzetsu/h-booru
> [2]: http://vimeo.com/102785458
> [3]: https://github.com/VinylRecords/Vinyl/blob/master/tests/Intro.lhs
>
> --
> Mateusz K.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From sean at functionaljobs.com  Mon Aug 11 16:00:01 2014
From: sean at functionaljobs.com (Functional Jobs)
Date: Mon, 11 Aug 2014 12:00:01 -0400
Subject: [Haskell-cafe] New Functional Programming Job Opportunities
Message-ID: <53e8e8831f38f@functionaljobs.com>

Here are some functional programming job opportunities that were posted
recently:

Big Data Engineer / Data Scientist at Recruit IT
http://functionaljobs.com/jobs/8731-big-data-engineer-data-scientist-at-recruit-it

Cheers,
Sean Murphy
FunctionalJobs.com


From bneijt at gmail.com  Mon Aug 11 18:41:42 2014
From: bneijt at gmail.com (Bram Neijt)
Date: Mon, 11 Aug 2014 20:41:42 +0200
Subject: [Haskell-cafe] Any tips on "doing it right" for a small program?
Message-ID: <CADS_YUwPgMaF_+kumpArwSApaht15dznfksqCRnVvaTWr1VnTw@mail.gmail.com>

Dear reader,

I'm still new to haskell, and decided to convert a simple bash script
to a full-on-bells-and-whistles Haskell program (as a learning
experience). As you might guess I could use some help.

The program is very simple, in Bash it reads:
CMDPATTERN="$@"
while [[ "`pgrep --count --full "$CMDPATTERN"`" -gt 1 ]]; do
    sleep 5
done

AKA: while there is a command running with the given string, loop. I
called this script "after" and use it on the commandline to chain
commands from different terminals.

The Haskell version is available at https://github.com/bneijt/after

What I have done:
- Add Travis CI
- Add a first test case using test-framework
- Add commandline option parsing using "options"
- Implement a fork-join behavior using parallel-io

What I would like help with:
- How to add a --version that reflects the after.cabal version?
- Is there a library for what I'm doing in Process.hs (listing running
processes, etc.)?
- How to add "-p <pid>" support, so I can do "after -p 129 -p 402"
(after both pids)
- Should I move from exitcode-stdio-1.0 to detailed-1.0?
- Any and all other hints you might have

Also if you have projects you want to point to for inspiration, I'd be
happy to take a look.

Greetings,

Bram

From fuuzetsu at fuuzetsu.co.uk  Mon Aug 11 18:56:16 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Mon, 11 Aug 2014 20:56:16 +0200
Subject: [Haskell-cafe] Any tips on "doing it right" for a small program?
In-Reply-To: <CADS_YUwPgMaF_+kumpArwSApaht15dznfksqCRnVvaTWr1VnTw@mail.gmail.com>
References: <CADS_YUwPgMaF_+kumpArwSApaht15dznfksqCRnVvaTWr1VnTw@mail.gmail.com>
Message-ID: <53E911D0.1040403@fuuzetsu.co.uk>

On 08/11/2014 08:41 PM, Bram Neijt wrote:
> Dear reader,
> 
> I'm still new to haskell, and decided to convert a simple bash script
> to a full-on-bells-and-whistles Haskell program (as a learning
> experience). As you might guess I could use some help.
> 
> The program is very simple, in Bash it reads:
> CMDPATTERN="$@"
> while [[ "`pgrep --count --full "$CMDPATTERN"`" -gt 1 ]]; do
>     sleep 5
> done
> 
> AKA: while there is a command running with the given string, loop. I
> called this script "after" and use it on the commandline to chain
> commands from different terminals.
> 
> The Haskell version is available at https://github.com/bneijt/after
> 
> What I have done:
> - Add Travis CI
> - Add a first test case using test-framework
> - Add commandline option parsing using "options"
> - Implement a fork-join behavior using parallel-io
> 
> What I would like help with:
> - How to add a --version that reflects the after.cabal version?

You can use the symbols cabal generates at build time. See [1].

> - Is there a library for what I'm doing in Process.hs (listing running
> processes, etc.)?
> - How to add "-p <pid>" support, so I can do "after -p 129 -p 402"
> (after both pids)

Hm, I don't know. Seems like you could use waitForProcess from the
process package but it doesn't seem to expose a way to create a
ProcessHandle without spawning the process ourselves which is reasonable
I suppose. You might need to implement something yourself. If you find
out how to solve your previous question then this should become easy.

> - Should I move from exitcode-stdio-1.0 to detailed-1.0?
> - Any and all other hints you might have
> 
> Also if you have projects you want to point to for inspiration, I'd be
> happy to take a look.
> 
> Greetings,
> 
> Bram
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

[1]:
http://stackoverflow.com/questions/2892586/how-can-my-haskell-program-or-library-find-its-version-number

-- 
Mateusz K.

From wojtek at power.com.pl  Mon Aug 11 22:16:31 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 00:16:31 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
Message-ID: <53E940BF.5040500@power.com.pl>

Dear All,

Haskell is great for great many areas, let me name just two: - parsers, 
translators, interpreters, compilers; highly concurrent systems.

Haskell is however not great for GUIs. I've been thinking a little why 
this is so. I think one of the reasons might be that in Haskell it is 
unusual to deal with data that is incomplete or otherwise erroneous. Let 
me try to explain, what I mean, by example. If you declare Person class 
in Java, you automatically get a thingy that you can readily use in UI 
construction, because all the fields can temporarily be null, even the 
required ones. In Haskell you'd need two data types: the usual proper 
Haskell data type, and another which wraps every field in Maybe, 
facilitates editing, validation, etc. Perhaps it would be possible to 
generate one data type from the other, or generate both from a common 
specification.

Let me write the same thing in other words. It is not controversial to 
say on this list that specifying what is correct means, is a good idea. 
But for GUIs, in addition to the strong type, you need another relaxed 
type to hold the values temporarily, until the human manages to deliver 
correct data, often by trial and error.

Comments welcome.

-- 
Kind regards,
Wojtek Narczy?ski


From allbery.b at gmail.com  Mon Aug 11 22:25:26 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 11 Aug 2014 18:25:26 -0400
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E940BF.5040500@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
Message-ID: <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>

On Mon, Aug 11, 2014 at 6:16 PM, Wojtek Narczy?ski <wojtek at power.com.pl>
wrote:

> Let me write the same thing in other words. It is not controversial to say
> on this list that specifying what is correct means, is a good idea. But for
> GUIs, in addition to the strong type, you need another relaxed type to hold
> the values temporarily, until the human manages to deliver correct data,
> often by trial and error.


I think there are far larger issues to deal with first: you need to have a
sensible connection from Haskell to a GUI before you can worry about
getting data across it. At the moment, we have either mostly procedural
interfaces to common procedural toolkits (WxHaskell, gtk2hs) or a number of
still largely experimental FRP interfaces.

It is not particularly difficult to deal with the step that you highlight
once we have solved the basic interface to the GUI; you can do it with
Template Haskell, or generics, or lens, or with semi-typed interfaces
between Haskell and the GUI (for example, I can see Aeson sitting in this
layer). But figuring out how to work it in depends on knowing what we're
working it into.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140811/dc237d50/attachment.html>

From agocorona at gmail.com  Mon Aug 11 22:53:37 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 00:53:37 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
Message-ID: <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>

I think that the GUI people hace to embrace the formlet concept, used in
HTML interfaces sooner better than later. The GUI development has lost the
train by trying to interface C libraries that are decades old. The reactive
solutions complicates the problem rather than to simplify it. That means
that they are not the correct paradigm.


2014-08-12 0:25 GMT+02:00 Brandon Allbery <allbery.b at gmail.com>:

> On Mon, Aug 11, 2014 at 6:16 PM, Wojtek Narczy?ski <wojtek at power.com.pl>
> wrote:
>
>> Let me write the same thing in other words. It is not controversial to
>> say on this list that specifying what is correct means, is a good idea. But
>> for GUIs, in addition to the strong type, you need another relaxed type to
>> hold the values temporarily, until the human manages to deliver correct
>> data, often by trial and error.
>
>
> I think there are far larger issues to deal with first: you need to have a
> sensible connection from Haskell to a GUI before you can worry about
> getting data across it. At the moment, we have either mostly procedural
> interfaces to common procedural toolkits (WxHaskell, gtk2hs) or a number of
> still largely experimental FRP interfaces.
>
> It is not particularly difficult to deal with the step that you highlight
> once we have solved the basic interface to the GUI; you can do it with
> Template Haskell, or generics, or lens, or with semi-typed interfaces
> between Haskell and the GUI (for example, I can see Aeson sitting in this
> layer). But figuring out how to work it in depends on knowing what we're
> working it into.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/cab3ce7e/attachment.html>

From wojtek at power.com.pl  Mon Aug 11 22:57:44 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 00:57:44 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
Message-ID: <53E94A68.1070303@power.com.pl>


On 12.08.2014 00:53, Alberto G. Corona wrote:
> I think that the GUI people hace to embrace the formlet concept, used 
> in HTML interfaces sooner better than later. The GUI development has 
> lost the train by trying to interface C libraries that are decades 
> old. The reactive solutions complicates the problem rather than to 
> simplify it. That means that they are not the correct paradigm.
>
I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it 
explicitly upfront.

From agocorona at gmail.com  Mon Aug 11 23:14:41 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 01:14:41 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E94A68.1070303@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
Message-ID: <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>

Wojtek. What you say is exactly what has been solved time ago by fomlets in
Web interfaces.  There are many formlet library and almost all haskell web
framework use formlets.


2014-08-12 0:57 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

>
> On 12.08.2014 00:53, Alberto G. Corona wrote:
>
>> I think that the GUI people hace to embrace the formlet concept, used in
>> HTML interfaces sooner better than later. The GUI development has lost the
>> train by trying to interface C libraries that are decades old. The reactive
>> solutions complicates the problem rather than to simplify it. That means
>> that they are not the correct paradigm.
>>
>>  I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
> explicitly upfront.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/ab41ce85/attachment.html>

From tikhon at jelv.is  Mon Aug 11 23:21:17 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Mon, 11 Aug 2014 16:21:17 -0700
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E94A68.1070303@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
Message-ID: <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>

For the original question: take a look at functional reactive programming
(FRP). It takes a slightly different approach to the whole GUI problem,
but, I've found, obviates some of your issues.

You can quickly play around with FRP and HTML UIs by using threepenny-gui
and Reactive Banana. The former is a simple UI framework that lets you
create and interact with HTML in Haskell, and the latter in a nice library
for FRP. They work well together:

http://apfelmus.nfshost.com/blog/2013/08/02-reactive-banana-threepenny.html

There's a nice tutorial about FRP and Reactive Banana you can read on the
Haskell Wiki. I haven't had the chance to go through it myself, but it
looks promising.

http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana

If you're wondering about Haskell and UIs, I think FRP is the best place to
look?it provides the most pleasant semantics for programming UIs that I've
come across, although most of the libraries are still a bit experimental.
(Implementing the exact semantics we'd like turned out to be very
difficult!)

> The reactive solutions complicates the problem rather than to simplify
it. That means that they are not the correct paradigm.

That's a very hasty, superficial way to dismiss a whole paradigm!

FRP libraries have proven *difficult to implement*, but this does not mean
they somehow "complicate the problem". The real insight with FRP is
developing a nice semantics *for the end user* and making it simpler to
work with the libraries, at the expense of a more complex implementation.
It's a parallel to functional programming at large: we're willing to trade
complexity in GHC in return for a nicer high-level programming environment.

Formlets are an interesting concept, but they seem to be significantly more
narrow than FRP. How do formlets address continuous things like animations
or mouse movement?

Also, a lot of the examples (at least on the Haskell wiki[1]) seem pretty
amenable to FRP. How is

    chooseBool :: Form Bool
    chooseBool = enumRadio [(True, "Yes"), (False, "No")] True

significantly different from just providing a Behavior Bool in the spirit
of FRP?


On Mon, Aug 11, 2014 at 3:57 PM, Wojtek Narczy?ski <wojtek at power.com.pl>
wrote:

>
> On 12.08.2014 00:53, Alberto G. Corona wrote:
>
>> I think that the GUI people hace to embrace the formlet concept, used in
>> HTML interfaces sooner better than later. The GUI development has lost the
>> train by trying to interface C libraries that are decades old. The reactive
>> solutions complicates the problem rather than to simplify it. That means
>> that they are not the correct paradigm.
>>
>>  I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
> explicitly upfront.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140811/616e54d4/attachment.html>

From agocorona at gmail.com  Mon Aug 11 23:22:59 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 01:22:59 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
Message-ID: <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>

But formlets are implemented in the server side.  and you probably think in
applications with heavy use of JavaScript for validations, interaction
 etc. In this case, there is a formlet implementation in the client side,
which is my.. Ahem!... package hplaygroud:

https://github.com/agocorona/hplayground


2014-08-12 1:14 GMT+02:00 Alberto G. Corona <agocorona at gmail.com>:

> Wojtek. What you say is exactly what has been solved time ago by fomlets
> in Web interfaces.  There are many formlet library and almost all haskell
> web framework use formlets.
>
>
> 2014-08-12 0:57 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:
>
>
>> On 12.08.2014 00:53, Alberto G. Corona wrote:
>>
>>> I think that the GUI people hace to embrace the formlet concept, used in
>>> HTML interfaces sooner better than later. The GUI development has lost the
>>> train by trying to interface C libraries that are decades old. The reactive
>>> solutions complicates the problem rather than to simplify it. That means
>>> that they are not the correct paradigm.
>>>
>>>  I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
>> explicitly upfront.
>>
>
>
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/96429a29/attachment.html>

From ok at cs.otago.ac.nz  Tue Aug 12 03:31:04 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Tue, 12 Aug 2014 15:31:04 +1200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E940BF.5040500@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
Message-ID: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>

> If you declare Person class
> in Java, you automatically get a thingy that you can readily use in UI
> construction, because all the fields can temporarily be null, even the
> required ones. In Haskell you'd need two data types: the usual proper
> Haskell data type, and another which wraps every field in Maybe,
> facilitates editing, validation, etc. Perhaps it would be possible to
> generate one data type from the other, or generate both from a common
> specification.

You seem to be referring to the "incompletely initialised object"
anti-pattern.  The books I have about concurrency in Java/on the JVM
strongly recommend making Java objects immutable when you can.

Even in Visual Basic, if an object is "constructed" via a lengthy
sequence of steps, it is good design to distinguish between two
different things": a fully constructed Foo object and a FooBuilder
object.  Sometimes they need to be the same object, but there really
do need to be two *interfaces*.  Once past the construction phase,
you want to KNOW that the object is fully constructed, and there are
things the constructor might do that you DON'T want other objects to
do.

Reflecting on the use case you are talking about, it seems to be
that there are two conceptually very distinct objects here.
There is a FooForm object which is intimately connected to the
user interface and may only partially describe a Foo, and there
is a Foo object which is *not* connected to the user interface
or if it is, is connected in a quite different way, exposing
quite different behaviours.  Reflecting further, suppose I fill
out a form and press a button to commit this object, then I
edit the form to be a little different, and press the button
again.  Creating a new *object* by revising a single *form* is
clearly distinct from *editing* an existing object.

What I think about this, therefore, is that you want a clear
distinction between FooForms and Foos (at the very minimum a
distinction between FooForm and Foo interfaces) no matter WHAT
kind of programming language you are using, and I don't see
Haskell as anything special here.

> Let me write the same thing in other words. It is not controversial to
> say on this list that specifying what is correct means, is a good idea.
> But for GUIs, in addition to the strong type, you need another relaxed
> type to hold the values temporarily, until the human manages to deliver
> correct data, often by trial and error.

In short, we agree, that is indeed *ANOTHER* type.

Not only may a FooForm not yet hold information a Foo needs,
a FooForm may hold information that a Foo does *not* need.
For example, a FooForm might need to hold on to some credentials
to prove that it is authorised to create Foo objects, whereas a
Foo object might not.

In Smalltalk, Java, C#, &c one might look at ways of automatically
constructing FooForms from Foo classes + annotations.  Using some
sort of generic processing, one could also do this in Haskell.
Having two classes/types does not have to be twice as much work.




From dav.vire+haskell at gmail.com  Tue Aug 12 06:31:45 2014
From: dav.vire+haskell at gmail.com (David Virebayre)
Date: Tue, 12 Aug 2014 08:31:45 +0200
Subject: [Haskell-cafe] Any tips on "doing it right" for a small program?
In-Reply-To: <CADS_YUwPgMaF_+kumpArwSApaht15dznfksqCRnVvaTWr1VnTw@mail.gmail.com>
References: <CADS_YUwPgMaF_+kumpArwSApaht15dznfksqCRnVvaTWr1VnTw@mail.gmail.com>
Message-ID: <CAM_wFVsLvSg=GL=iezqP9-TFB6TQwd2bGhdnLV=UnvQbJyPmrw@mail.gmail.com>

2014-08-11 20:41 GMT+02:00 Bram Neijt <bneijt at gmail.com>:
>
> Dear reader,
...
> Also if you have projects you want to point to for inspiration, I'd be
> happy to take a look.

Hello,

Not really projects, but seeing your post I remembered Donal Stewart's
blog, especially:

http://donsbot.wordpress.com/2006/12/18/programming-haskell-argument-handling-and-a-complete-cat/
http://donsbot.wordpress.com/2007/03/10/practical-haskell-shell-scripting-with-error-handling-and-privilege-separation/

It's quite old, but I thought it was relevant.

Cheers,

David.

From althainz at gmail.com  Tue Aug 12 06:36:03 2014
From: althainz at gmail.com (Peter Althainz)
Date: Tue, 12 Aug 2014 08:36:03 +0200
Subject: [Haskell-cafe] HGamer3D - version 0.4
Message-ID: <CAKS-SOms=5mNA4yCtFkdd30mT5_8kagzBe30MPFmD28BL5RGfQ@mail.gmail.com>

You will find version 0.4 of HGamer3D on github and hackage now. It also
comes with some updated introductions on http://www.hgamer3d.org .

best regards
Peter (uotbw)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/4443fdc1/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Tue Aug 12 07:27:38 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 12 Aug 2014 09:27:38 +0200
Subject: [Haskell-cafe] Updating code to work with vinyl 0.4
In-Reply-To: <CAHfjoWnT7K2u6yeZNBtK2ozwFqW19Ry_B10JJksa=R1SCxoKrw@mail.gmail.com>
References: <53E8905E.6000100@fuuzetsu.co.uk>
 <CAHfjoWnT7K2u6yeZNBtK2ozwFqW19Ry_B10JJksa=R1SCxoKrw@mail.gmail.com>
Message-ID: <53E9C1EA.6040905@fuuzetsu.co.uk>

On 08/11/2014 05:04 PM, adam vogt wrote:
> Hi Mateusz,
> 
> You can write  'Foo :~> [t| Maybe String |] to make the generated code include a
> 
>   type instance App ElF Foo = Maybe String
> 
> Unfortunately the type of (:~>) includes some un-exported classes, so
> you have to dig into vinyl's source to see which arguments are
> actually allowed.
> 
> 
> I'm not sure exactly what you mean by
> 
>> PlainRec ElF (ParentId ': '[])? works but is ugly
> 
> But maybe it's worth just using the Data.Vinyl.Universe.Field (ex.
> http://lpaste.net/109203), if you would rather write
> 
>   PlainRec ElField '["parent_id" ::: Maybe Integer])
> 
> than,
> 
>   PlainRec ElF '[ParentId]
> 
> Or maybe you want to use Symbol together with your own universe:
> 
>   makeUniverse' ''Symbol "ElF"
>   semantics ''ElF [ [t| "height" |] :~> [t| Maybe Int |] ]
>   -- type instance App ElF "height" = Maybe Int -- or just write those by-hand
> 
>   height = Proxy :: Proxy "height" -- there seems to be no code
> generation in Vinyl for these
> 
> which will give you a type like
> 
>   PlainRec ElF '["parent_id"]
> 
> Hopefully one of these options is not as ugly as the other.
> 
> 
> Regards,
> Adam
> 

Hi,

I have managed to migrate to 0.4, thank you very much with these
instructions. I'll outline what I ended up having to do in case anyone
stumbles upon this thread in the future.

I ended up going with makeUniverse' ''Symbol "ElF" way. This made the
migration fairly mechanical. The reason for going this way rather than
the others is that I don't have to define separate field type and mess
around with singletons. For my application, it's important to me that
the field names match up what they are in raw data so it was great I
could keep using these.

First I turned all

foo :: "foo" ::: Bar
foo = Field

into

foo :: Proxy "foo"
foo = Proxy

Easy with a macro.

Likewise, I was able to turn the old field code into the

[t| "foo" |] :~> [t| Bar |]

style through some emacs macros.

I also used ?type R a = PlainRec ElF a?.

With all these things in place, I simply had to remove every occurance
of ? ::: SomeType? and replace all ?PlainRec whatever? with ?R
whatever?. I also had a single ?Rec? in a combinator I defined but that
also was easy to replace with ?R?.

Once again, thanks for your help!

-- 
Mateusz K.

From wojtek at power.com.pl  Tue Aug 12 07:55:20 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 09:55:20 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
Message-ID: <53E9C868.9090406@power.com.pl>

On 12.08.2014 05:31, ok at cs.otago.ac.nz wrote:
>> If you declare Person class
>> in Java, you automatically get a thingy that you can readily use in UI
>> construction, because all the fields can temporarily be null, even the
>> required ones. In Haskell you'd need two data types: the usual proper
>> Haskell data type, and another which wraps every field in Maybe,
>> facilitates editing, validation, etc. Perhaps it would be possible to
>> generate one data type from the other, or generate both from a common
>> specification.
> You seem to be referring to the "incompletely initialised object"
> anti-pattern.  The books I have about concurrency in Java/on the JVM
> strongly recommend making Java objects immutable when you can.
>
> Even in Visual Basic, if an object is "constructed" via a lengthy
> sequence of steps, it is good design to distinguish between two
> different things": a fully constructed Foo object and a FooBuilder
> object.  Sometimes they need to be the same object, but there really
> do need to be two *interfaces*.  Once past the construction phase,
> you want to KNOW that the object is fully constructed, and there are
> things the constructor might do that you DON'T want other objects to
> do.

Take a VAT Invoice as an example. You will have:

Invoice, InvoiceBuilder,
InvoiceLineItem, InvoiceLineItemBuilder,
InvoiceCustomer, InvoiceCustomerBuilder,
InvoiceSummary, (no Builder, as this is calculated)
(many, many more classes in a realistic system)

Now, where the rather complex validation belongs? Optional / mandatory 
requirements, lengths, ranges, regexps, control sums, field 
interdependencies, autocompletes, server sent notifications? Where to 
put all of this? To regular classes, to builder classes, or to both?

-- 
Wojtek

From jim.a.stuttard at gmail.com  Tue Aug 12 08:28:51 2014
From: jim.a.stuttard at gmail.com (Jim Stuttard)
Date: Tue, 12 Aug 2014 09:28:51 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9C868.9090406@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl>
Message-ID: <53E9D043.8010608@gmail.com>


On 08/12/2014 08:55 AM, Wojtek Narczy?ski wrote:
> On 12.08.2014 05:31, ok at cs.otago.ac.nz wrote:
>>> If you declare Person class
>>> in Java, you automatically get a thingy that you can readily use in UI
>>> construction, because all the fields can temporarily be null, even the
>>> required ones. In Haskell you'd need two data types: the usual proper
>>> Haskell data type, and another which wraps every field in Maybe,
>>> facilitates editing, validation, etc. Perhaps it would be possible to
>>> generate one data type from the other, or generate both from a common
>>> specification.
>> You seem to be referring to the "incompletely initialised object"
>> anti-pattern. The books I have about concurrency in Java/on the JVM
>> strongly recommend making Java objects immutable when you can.
>>
>> Even in Visual Basic, if an object is "constructed" via a lengthy
>> sequence of steps, it is good design to distinguish between two
>> different things": a fully constructed Foo object and a FooBuilder
>> object. Sometimes they need to be the same object, but there really
>> do need to be two *interfaces*. Once past the construction phase,
>> you want to KNOW that the object is fully constructed, and there are
>> things the constructor might do that you DON'T want other objects to
>> do.
>
> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs? Optional / mandatory 
> requirements, lengths, ranges, regexps, control sums, field 
> interdependencies, autocompletes, server sent notifications? Where to 
> put all of this? To regular classes, to builder classes, or to both?
These sound like cross-cutting concerns. I found this paper on monads 
and mixins for AOP.

http://i.cs.hku.hk/~bruno/papers/MixinAspects.pdf

hth


From wojtek at power.com.pl  Tue Aug 12 08:31:25 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 10:31:25 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
Message-ID: <53E9D0DD.8010906@power.com.pl>

On 12.08.2014 01:14, Alberto G. Corona wrote:
> Wojtek. What you say is exactly what has been solved time ago by 
> fomlets in Web interfaces.  There are many formlet library and almost 
> all haskell web framework use formlets.
>
AFAIK, formlets at the server are very much like PHP, only with neater 
syntax, strong typing, and the like. Formlets tutorials teach you to put 
all your validation into the GUI, you really can't do much worse.

But, Alberto, your client side formlets look very interesting. I printed 
your Monad.Reader paper, and I'm definitely going to explore your ideas.

-- 
Kind regards,
Wojtek Narczy?ski

From chriswarbo at googlemail.com  Tue Aug 12 09:30:43 2014
From: chriswarbo at googlemail.com (Chris Warburton)
Date: Tue, 12 Aug 2014 10:30:43 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9C868.9090406@power.com.pl> ("Wojtek =?utf-8?Q?Narczy?=
 =?utf-8?Q?=C5=84ski=22's?= message of
 "Tue, 12 Aug 2014 09:55:20 +0200")
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl>
Message-ID: <864mxi6on0.fsf@gmail.com>

Wojtek Narczy?ski <wojtek at power.com.pl> writes:

> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs? Optional / mandatory
> requirements, lengths, ranges, regexps, control sums, field
> interdependencies, autocompletes, server sent notifications? Where to
> put all of this? To regular classes, to builder classes, or to both?

The current trend in OOP Web frameworks Model-View-Controller.

In MVP, Invoice/InvoiceLineItem/InvoiceCustomer/InvoiceSummary/etc. are
the Model: they should form a standalone 'simulation' of an Invoice,
without concerning themselves with 'external' aspects.

Validation, bootstrapping (builders), etc. live in the Controller
layer.

If the server notifications are informing the user about the behaviour
of the Model, they're part of the View. If they facilitate interaction
they're part of the Controller.

There are many functional styles which suit Models:
 - The pseudo-imperative style of Applicative/Monad/Arrow/etc.
 - The 'interacting streams' style, eg. infinite [(Request, Response)]
   lists.
 - Functional Reactive Programming

Since Controllers can't mutate Models in Haskell, they must do one of
two things:
 - Influence some 'future' behaviour of the Model, eg. using FRP
 - Build a new Model from the given settings

To me the latter choice looks similar to a parsing problem. You say that
Haskell's "great" at parsing, which I think contradicts your statement
that "in Haskell it is unusual to deal with data that is incomplete or
otherwise erroneous".

In Haskell we deal with incomplete data all the time using lazy
evaluation. Erroneous data doesn't require Maybes all over our data: it
just needs one big Maybe in the 'parsing' function; or, more likely,
"Either [Error]" detailing the problems which were found.

Views are straightforward: recurse over the data, use FRP, etc.

Cheers,
Chris

From alois.cochard at gmail.com  Tue Aug 12 09:40:28 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Tue, 12 Aug 2014 10:40:28 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E940BF.5040500@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
Message-ID: <CAJHA+woX2K_AUiWg8QJtxi3+OU1kwakb6N=40+eP25-aSudRRA@mail.gmail.com>

I think the way Jon Sterling integrated validation in his extensible
library might give some inspiration about using a similar approach to solve
the specific problem you describe.

He did a great talk about it recently, I highly recommend it:
http://t.co/ZKceAY5zAz

Cheers

Alois



On 11 August 2014 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:

> Dear All,
>
> Haskell is great for great many areas, let me name just two: - parsers,
> translators, interpreters, compilers; highly concurrent systems.
>
> Haskell is however not great for GUIs. I've been thinking a little why
> this is so. I think one of the reasons might be that in Haskell it is
> unusual to deal with data that is incomplete or otherwise erroneous. Let me
> try to explain, what I mean, by example. If you declare Person class in
> Java, you automatically get a thingy that you can readily use in UI
> construction, because all the fields can temporarily be null, even the
> required ones. In Haskell you'd need two data types: the usual proper
> Haskell data type, and another which wraps every field in Maybe,
> facilitates editing, validation, etc. Perhaps it would be possible to
> generate one data type from the other, or generate both from a common
> specification.
>
> Let me write the same thing in other words. It is not controversial to say
> on this list that specifying what is correct means, is a good idea. But for
> GUIs, in addition to the strong type, you need another relaxed type to hold
> the values temporarily, until the human manages to deliver correct data,
> often by trial and error.
>
> Comments welcome.
>
> --
> Kind regards,
> Wojtek Narczy?ski
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/07583fe5/attachment.html>

From agocorona at gmail.com  Tue Aug 12 09:40:24 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 11:40:24 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
Message-ID: <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>

2014-08-12 1:21 GMT+02:00 Tikhon Jelvis <tikhon at jelv.is>:

> For the original question: take a look at functional reactive programming
> (FRP). It takes a slightly different approach to the whole GUI problem,
> but, I've found, obviates some of your issues.
>
> You can quickly play around with FRP and HTML UIs by using threepenny-gui
> and Reactive Banana. The former is a simple UI framework that lets you
> create and interact with HTML in Haskell, and the latter in a nice library
> for FRP. They work well together:
>
> http://apfelmus.nfshost.com/blog/2013/08/02-reactive-banana-threepenny.html
>
> There's a nice tutorial about FRP and Reactive Banana you can read on the
> Haskell Wiki. I haven't had the chance to go through it myself, but it
> looks promising.
>
> http://www.haskell.org/haskellwiki/FRP_explanation_using_reactive-banana
>
> If you're wondering about Haskell and UIs, I think FRP is the best place
> to look?it provides the most pleasant semantics for programming UIs that
> I've come across, although most of the libraries are still a bit
> experimental. (Implementing the exact semantics we'd like turned out to be
> very difficult!)
>
> > The reactive solutions complicates the problem rather than to simplify
> it. That means that they are not the correct paradigm.
>
> That's a very hasty, superficial way to dismiss a whole paradigm!
>

Yes!

 I was just trying to be a bit provoking. Sorry.

The objections about the use of  current FRP models for GUIs are here:

http://homepages.cwi.nl/~ploeg/papers/monfrp.pdf

and here:

https://www.fpcomplete.com/user/agocorona/a-monad-for-reactive-programming-part-1

Allthough FRP is too wide. Monadic FRP is more appropriate for GUIs for the
same reasons.  hplayground uses monadic FRP + formlets


> FRP libraries have proven *difficult to implement*, but this does not mean
> they somehow "complicate the problem". The real insight with FRP is
> developing a nice semantics *for the end user* and making it simpler to
> work with the libraries, at the expense of a more complex implementation.
> It's a parallel to functional programming at large: we're willing to trade
> complexity in GHC in return for a nicer high-level programming environment.
>
> Formlets are an interesting concept, but they seem to be significantly
> more narrow than FRP. How do formlets address continuous things like
> animations or mouse movement?
>
> Also, a lot of the examples (at least on the Haskell wiki[1]) seem pretty
> amenable to FRP. How is
>
>     chooseBool :: Form Bool
>     chooseBool = enumRadio [(True, "Yes"), (False, "No")] True
>
> significantly different from just providing a Behavior Bool in the spirit
> of FRP?
>
>
> On Mon, Aug 11, 2014 at 3:57 PM, Wojtek Narczy?ski <wojtek at power.com.pl>
> wrote:
>
>>
>> On 12.08.2014 00:53, Alberto G. Corona wrote:
>>
>>> I think that the GUI people hace to embrace the formlet concept, used in
>>> HTML interfaces sooner better than later. The GUI development has lost the
>>> train by trying to interface C libraries that are decades old. The reactive
>>> solutions complicates the problem rather than to simplify it. That means
>>> that they are not the correct paradigm.
>>>
>>>  I'm mainly interested in HTML/JS GUIs. Perhaps I should have stated it
>> explicitly upfront.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/f0c8644b/attachment-0001.html>

From agocorona at gmail.com  Tue Aug 12 10:05:29 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 12:05:29 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9D0DD.8010906@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <53E9D0DD.8010906@power.com.pl>
Message-ID: <CAArEJmaGAPQxbKNk0Dn5ae1gqAcLa9VNP6FrGp1LK2FxLxGEJA@mail.gmail.com>

2014-08-12 10:31 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

> On 12.08.2014 01:14, Alberto G. Corona wrote:
>
>> Wojtek. What you say is exactly what has been solved time ago by fomlets
>> in Web interfaces.  There are many formlet library and almost all haskell
>> web framework use formlets.
>>
>>  AFAIK, formlets at the server are very much like PHP, only with neater
> syntax, strong typing, and the like. Formlets tutorials teach you to put
> all your validation into the GUI, you really can't do much worse.
>

I think that this horizontal separating the GUI from his application logic
is a wrong conception of separation of concern.. as strange as it may
sound, since that makes applications and components non composable. The MVC
model is non composable!

A better separation of concern, for many purposes, is the vertical one in
which each functionality include its own interface, logic and data model.
The obstacle for implementing this kind of separation of concern is mainly
technological, because each of the three layes uses different languages, so
an horizontal separation is easier. But it is not appropriate for most
purposes. It is very bad for creating GUIs!!

http://haskell-web.blogspot.com.es/2014/05/separation-of-concerns-by-problem.html





>
> But, Alberto, your client side formlets look very interesting. I printed
> your Monad.Reader paper, and I'm definitely going to explore your ideas.


Thanks!

>
>
> --
> Kind regards,
> Wojtek Narczy?ski
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/d465b41a/attachment.html>

From wojtek at power.com.pl  Tue Aug 12 10:46:05 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 12:46:05 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <864mxi6on0.fsf@gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
Message-ID: <53E9F06D.5090804@power.com.pl>

W dniu 2014-08-12 11:30, Chris Warburton pisze:
> Wojtek Narczy?ski<wojtek at power.com.pl>  writes:
>
>> ut all of this? To regular classes, to builder classes, or to both?
> The current trend in OOP Web frameworks Model-View-Controller.
We've been doing this for 15 years, and believe me, it works only so-so.
> To me the latter choice looks similar to a parsing problem. You say that
> Haskell's "great" at parsing, which I think contradicts your statement
> that "in Haskell it is unusual to deal with data that is incomplete or
> otherwise erroneous".
Grammars have been tried for GUIs, without any success. I'm not aware of 
any even moderate size GUI constructed this way.
> In Haskell we deal with incomplete data all the time using lazy
> evaluation. Erroneous data doesn't require Maybes all over our data: it
> just needs one big Maybe in the 'parsing' function; or, more likely,
> "Either [Error]" detailing the problems which were found.
>
Continuing my VAT Invoice example, let us say a LineItem that does not 
have a product description (missing value), but it does have all the 
numeric fields filled in.  It is partly erroneous, but it can be 
included in calculation of the total. How would you handle it with 
Either [Error] Invoice style code?

--
Cheers,
Wojtek Narczy?ski

From agocorona at gmail.com  Tue Aug 12 10:54:05 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 12:54:05 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9F06D.5090804@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl>
Message-ID: <CAArEJmZs7SCUg0vC2b4N1g-qgy9F5mOmzAwswbWm4nqttMLYzg@mail.gmail.com>

2014-08-12 12:46 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

> W dniu 2014-08-12 11:30, Chris Warburton pisze:
>
>> Wojtek Narczy?ski<wojtek at power.com.pl>  writes:
>>
>>
>>  ut all of this? To regular classes, to builder classes, or to both?
>>>
>> The current trend in OOP Web frameworks Model-View-Controller.
>>
> We've been doing this for 15 years, and believe me, it works only so-so.
>
>  To me the latter choice looks similar to a parsing problem. You say that
>> Haskell's "great" at parsing, which I think contradicts your statement
>> that "in Haskell it is unusual to deal with data that is incomplete or
>> otherwise erroneous".
>>
> Grammars have been tried for GUIs, without any success. I'm not aware of
> any even moderate size GUI constructed this way.
>
> Well, a formlet is essentially an applicative parser of HTTP parameters +
a writer of HTML code. it works pretty well. and it can create the complete
logic of a page, not only the interface  if we add a monadic instance.


>  In Haskell we deal with incomplete data all the time using lazy
>> evaluation. Erroneous data doesn't require Maybes all over our data: it
>> just needs one big Maybe in the 'parsing' function; or, more likely,
>> "Either [Error]" detailing the problems which were found.
>>
>>  Continuing my VAT Invoice example, let us say a LineItem that does not
> have a product description (missing value), but it does have all the
> numeric fields filled in.  It is partly erroneous, but it can be included
> in calculation of the total. How would you handle it with Either [Error]
> Invoice style code?
>
> --
> Cheers,
> Wojtek Narczy?ski
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/4501657b/attachment.html>

From wojtek at power.com.pl  Tue Aug 12 11:03:28 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 13:03:28 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
Message-ID: <53E9F480.6050304@power.com.pl>

On 12.08.2014 11:40, Alberto G. Corona wrote:
>
>     > The reactive solutions complicates the problem rather than to
>     simplify it. That means that they are not the correct paradigm.
>
>     That's a very hasty, superficial way to dismiss a whole paradigm!
>
>
> Yes!
>
> I was just trying to be a bit provoking. Sorry.
>

I would really like to see a complex web form (think Facebook, VAT 
Invoice, Tax forms) done in FRP. The harsh reality is that FRP for GUIs 
still has to prove that its utility reaches beyond the game of Pong.

-- 
Wojtek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/bc28a455/attachment.html>

From dgorin at dc.uba.ar  Tue Aug 12 13:01:10 2014
From: dgorin at dc.uba.ar (=?utf-8?Q?Daniel_Gor=C3=ADn?=)
Date: Tue, 12 Aug 2014 14:01:10 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E940BF.5040500@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
Message-ID: <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>


On 11 Aug 2014, at 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:

> If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.

At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:

data Person f
  = Person {
    firstName :: f String
  ,lastName :: f String
  ,birthDate :: f Date
  ,height :: f Int
  }

Then you get:

 - "Person Id" is a person with every field set in stone.

 - "Person Maybe" is a person with missing information.

 - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.




From hjgtuyl at chello.nl  Tue Aug 12 16:37:10 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Tue, 12 Aug 2014 18:37:10 +0200
Subject: [Haskell-cafe] ANNOUNCE: wxHaskell 0.91.0.0
Message-ID: <op.xkhm38mupz0j5l@alquantor>


L.S.,

I am happy to announce a new version of wxHaskell. This version binds to
both wxWidgets 2.9 and 3.0 [0]. As wxWidgets 3.0 is significantly better,
I advice everyone, who is already using wxHaskell, to upgrade to wxWidgets
3.0.1


What is it?
-----------
wxHaskell[1] is a portable and native GUI library for Haskell. The goal of
the project is to provide an industrial strength GUI library for Haskell,
but without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore built on top of wxWidgets ? a comprehensive C++
library that is portable across all major GUI platforms; including GTK,
Windows, X11, and MacOS X. Furthermore, it is a mature library (in
development since 1992) that supports a wide range of widgets with the
native look-and-feel.


What's new?
-----------
  - Accept both wxWidgets 2.9 and 3.0, with a preference for 3.0
  - Added bindings for wxGraphicsContext::CreatePath
  - Use the same custom hook for `cabal copy` in wxc/Setup.hs
  - Many updates in definitions of constants and some 'deprecated'
    annotations
  - samples/wx/TestTaskBarIcon.hs now displays an icon in the taskbar
  - Parsec.hs can now handle lines starting with "//" properly
    (package wxdirect)
  - Fixed build issue that was caused by not having both
    the 2.9 and 3.0 versions of wxWidgets installed
  - Made samples/test/STCEvent.hs compilable
  - Solved warnings about deprecated methods and duplicate constant
    definition
  - Added -Wl to options for compiling wxc.dll
  - Adapted upper limit for packages process and array
  - Solved "deprecated" warning from GHC 7.8.2

Links
-----
See the homepage of wxHaskell for more information:
   https://www.haskell.org/haskellwiki/WxHaskell

The packages are:
  - wxc       https://hackage.haskell.org/package/wxc
  - wxdirect  https://hackage.haskell.org/package/wxdirect
  - wxcore    https://hackage.haskell.org/package/wxcore
  - wx        https://hackage.haskell.org/package/wx

Regards,
Henk-Jan van Tuyl


[0] https://www.wxwidgets.org
[1] https://www.haskell.org/haskellwiki/WxHaskell



--
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 wojtek at power.com.pl  Tue Aug 12 19:18:54 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qY2llY2ggTmFyY3p5xYRza2k=?=)
Date: Tue, 12 Aug 2014 21:18:54 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
Message-ID: <53EA689E.9080100@power.com.pl>

W dniu 2014-08-12 01:22, Alberto G. Corona pisze:
> But formlets are implemented in the server side.  and you probably 
> think in applications with heavy use of JavaScript for validations, 
> interaction  etc. In this case, there is a formlet implementation in 
> the client side, which is my.. Ahem!... package hplaygroud:
>
> https://github.com/agocorona/hplayground
>
Very interesting, please allow a few questions about your approach:

1. Would it be possible to save a snapshot of a paritally filled form on 
the server?
2. Would it be possible to display the sum before the values: 3 = [ 1] + 
[  2] <-- this is rendered HTML, not Haskell?

(I thought I would have more questions, but somehow I can't think of any 
right now...)

-- 
Kind regards,
Wojtek

From wojtek at power.com.pl  Tue Aug 12 19:23:35 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qY2llY2ggTmFyY3p5xYRza2k=?=)
Date: Tue, 12 Aug 2014 21:23:35 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>
References: <53E940BF.5040500@power.com.pl>
 <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>
Message-ID: <53EA69B7.7050307@power.com.pl>


W dniu 2014-08-12 15:01, Daniel Gor?n pisze:
> On 11 Aug 2014, at 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
>
>> If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.
> At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:
>
> data Person f
>    = Person {
>      firstName :: f String
>    ,lastName :: f String
>    ,birthDate :: f Date
>    ,height :: f Int
>    }
>
> Then you get:
>
>   - "Person Id" is a person with every field set in stone.
>
>   - "Person Maybe" is a person with missing information.
>
>   - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.
>
>
>
I saw in the presentation submitted in another post that a similar thing 
has been done in Vinyl. But this won't work so well, because in the 
"rigid" type some fields are still supposed to remain wrapped in Maybe.

-- 
Wojtek

From agocorona at gmail.com  Tue Aug 12 19:59:27 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 21:59:27 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA689E.9080100@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
Message-ID: <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>

2014-08-12 21:18 GMT+02:00 Wojciech Narczy?ski <wojtek at power.com.pl>:

> W dniu 2014-08-12 01:22, Alberto G. Corona pisze:
>
>> But formlets are implemented in the server side.  and you probably think
>> in applications with heavy use of JavaScript for validations, interaction
>>  etc. In this case, there is a formlet implementation in the client side,
>> which is my.. Ahem!... package hplaygroud:
>>
>> https://github.com/agocorona/hplayground
>>
>>  Very interesting, please allow a few questions about your approach:
>
> 1. Would it be possible to save a snapshot of a paritally filled form on
> the server?
>

hplayground is client side. but by means of Haste.Ajax it is possible to
send something to a server.

 do
         r  <- (+) <$> inputAndSend
                     <*> inputAndSend
         p  (show r) ++> noWidget
     where
     inputAndSend= do
         r <- inputInt Nothing `wake` OnKeyPress <++ br
         sendInt  r
         return r
     sendInt i=  send the int trough Haste.Ajax

 2. Would it be possible to display the sum before the values: 3 = [ 1] + [
>  2] <-- this is rendered HTML, not Haskell?
>
> yes, using "at":

 do
        wraw $ div  ! id "result" $ noHtml
         r  <- (+) <$> inputInt Nothing `wake` OnKeyPress <++ br
                     <*> inputInt Nothing `wake` OnKeyPress <++ br

         at "result" Html $ p  (show r) ++> noWidget


> (I thought I would have more questions, but somehow I can't think of any
> right now...)
>
> --
> Kind regards,
> Wojtek
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/16cad1bc/attachment.html>

From agocorona at gmail.com  Tue Aug 12 20:01:25 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 22:01:25 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
Message-ID: <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>

sorry:  instead of

at "result" Html $ ....

is

at "result" Insert $ ....


2014-08-12 21:59 GMT+02:00 Alberto G. Corona <agocorona at gmail.com>:

>
>
>
> 2014-08-12 21:18 GMT+02:00 Wojciech Narczy?ski <wojtek at power.com.pl>:
>
> W dniu 2014-08-12 01:22, Alberto G. Corona pisze:
>>
>>> But formlets are implemented in the server side.  and you probably think
>>> in applications with heavy use of JavaScript for validations, interaction
>>>  etc. In this case, there is a formlet implementation in the client side,
>>> which is my.. Ahem!... package hplaygroud:
>>>
>>> https://github.com/agocorona/hplayground
>>>
>>>  Very interesting, please allow a few questions about your approach:
>>
>> 1. Would it be possible to save a snapshot of a paritally filled form on
>> the server?
>>
>
> hplayground is client side. but by means of Haste.Ajax it is possible to
> send something to a server.
>
>  do
>          r  <- (+) <$> inputAndSend
>                      <*> inputAndSend
>          p  (show r) ++> noWidget
>      where
>      inputAndSend= do
>          r <- inputInt Nothing `wake` OnKeyPress <++ br
>          sendInt  r
>          return r
>      sendInt i=  send the int trough Haste.Ajax
>
>  2. Would it be possible to display the sum before the values: 3 = [ 1] +
>> [  2] <-- this is rendered HTML, not Haskell?
>>
>> yes, using "at":
>
>  do
>         wraw $ div  ! id "result" $ noHtml
>          r  <- (+) <$> inputInt Nothing `wake` OnKeyPress <++ br
>                      <*> inputInt Nothing `wake` OnKeyPress <++ br
>
>          at "result" Html $ p  (show r) ++> noWidget
>
>
>> (I thought I would have more questions, but somehow I can't think of any
>> right now...)
>>
>> --
>> Kind regards,
>> Wojtek
>>
>
>
>
> --
> Alberto.
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/b099e147/attachment.html>

From wojtek at power.com.pl  Tue Aug 12 20:51:15 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 22:51:15 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
Message-ID: <53EA7E43.3010502@power.com.pl>


On 12.08.2014 22:01, Alberto G. Corona wrote:
> sorry:  instead of
>
> at "result" Html $ ....
>
> is
>
> at "result" Insert $ ....
>
Oh, so basically, you create an element and later on replace it with the 
right content. I think it's a hack, but a neat one.

-- 
Wojtek

From agocorona at gmail.com  Tue Aug 12 21:27:56 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 12 Aug 2014 23:27:56 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA7E43.3010502@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
Message-ID: <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>

Well, it is not a hack. It is the way hplayground works . normally it
rewrite the HTML DOM of the implicit divs that are below  the event source.
"at" permits to assign freely that location.


2014-08-12 22:51 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

>
> On 12.08.2014 22:01, Alberto G. Corona wrote:
>
>> sorry:  instead of
>>
>> at "result" Html $ ....
>>
>> is
>>
>> at "result" Insert $ ....
>>
>>  Oh, so basically, you create an element and later on replace it with the
> right content. I think it's a hack, but a neat one.
>
> --
> Wojtek
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140812/736312a9/attachment.html>

From wojtek at power.com.pl  Tue Aug 12 21:42:31 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Tue, 12 Aug 2014 23:42:31 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
Message-ID: <53EA8A47.6070808@power.com.pl>

On 12.08.2014 23:27, Alberto G. Corona wrote:
> Well, it is not a hack. It is the way hplayground works . normally it 
> rewrite the HTML DOM of the implicit divs that are below  the event 
> source. "at" permits to assign freely that location.

Okay, I see.

3. Are you yourself aware of any serious limitations of your approach?

-- 
Wojtek

From apfelmus at quantentunnel.de  Tue Aug 12 21:50:54 2014
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Tue, 12 Aug 2014 23:50:54 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9F480.6050304@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl>
Message-ID: <lse27v$f90$1@ger.gmane.org>

Wojtek Narczy?ski wrote:
> I would really like to see a complex web form (think Facebook, VAT 
> Invoice, Tax forms) done in FRP. The harsh reality is that FRP for GUIs 
> still has to prove that its utility reaches beyond the game of Pong.

Like this?

   http://www.haskell.org/haskellwiki/Reactive-banana/Examples#crud

It's still a toy model, but I think it captures the essential 
difficulties. A full blown tax form would just be more of the same.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From agocorona at gmail.com  Tue Aug 12 22:13:09 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 13 Aug 2014 00:13:09 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA8A47.6070808@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
Message-ID: <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>

I did the todo application, (see todomvc.com) to check if the concept was
expressive and robust enough to do it:

https://github.com/agocorona/hplay-todo

 I think that the model works and the haste compiler works very well too. I
don?t know any serious limitation.  "wcallback" generates spurious DOM
elements and so on, but that can be fixed.






2014-08-12 23:42 GMT+02:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

> On 12.08.2014 23:27, Alberto G. Corona wrote:
>
>> Well, it is not a hack. It is the way hplayground works . normally it
>> rewrite the HTML DOM of the implicit divs that are below  the event source.
>> "at" permits to assign freely that location.
>>
>
> Okay, I see.
>
> 3. Are you yourself aware of any serious limitations of your approach?
>
> --
> Wojtek
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/26e18c28/attachment.html>

From dgorin at dc.uba.ar  Tue Aug 12 22:26:31 2014
From: dgorin at dc.uba.ar (=?utf-8?Q?Daniel_Gor=C3=ADn?=)
Date: Tue, 12 Aug 2014 23:26:31 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA69B7.7050307@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>
 <53EA69B7.7050307@power.com.pl>
Message-ID: <7D47F026-3575-4953-8CC7-198A97EFB0A7@dc.uba.ar>


On 12 Aug 2014, at 20:23, Wojciech Narczy?ski <wojtek at power.com.pl> wrote:

> 
> W dniu 2014-08-12 15:01, Daniel Gor?n pisze:
>> On 11 Aug 2014, at 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
>> 
>>> If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.
>> At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:
>> 
>> data Person f
>>   = Person {
>>     firstName :: f String
>>   ,lastName :: f String
>>   ,birthDate :: f Date
>>   ,height :: f Int
>>   }
>> 
>> Then you get:
>> 
>>  - "Person Id" is a person with every field set in stone.
>> 
>>  - "Person Maybe" is a person with missing information.
>> 
>>  - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.
>> 
>> 
>> 
> I saw in the presentation submitted in another post that a similar thing has been done in Vinyl. But this won't work so well, because in the "rigid" type some fields are still supposed to remain wrapped in Maybe.

That?s not necessary a problem. If you add a field:

  ,favoriteNumber :: f (Maybe Int)

Then, in Person Maybe, a value of Nothing in favoriteNumber would mean ?not entered? while Just Nothing would be ?none?. Maybe you have some specific problem in mind?


From wojtek at power.com.pl  Tue Aug 12 22:33:46 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 00:33:46 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <lse27v$f90$1@ger.gmane.org>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
Message-ID: <53EA964A.3000404@power.com.pl>

On 12.08.2014 23:50, Heinrich Apfelmus wrote:
> Wojtek Narczy?ski wrote:
>> I would really like to see a complex web form (think Facebook, VAT 
>> Invoice, Tax forms) done in FRP. The harsh reality is that FRP for 
>> GUIs still has to prove that its utility reaches beyond the game of 
>> Pong.
>
> Like this?
>
>   http://www.haskell.org/haskellwiki/Reactive-banana/Examples#crud
>
> It's still a toy model, but I think it captures the essential 
> difficulties. A full blown tax form would just be more of the same.
>
>
Is it live anywhere? I'd like to test it for HTML injection. The #1 
difficulty is validation. Is there any in this example? I can't see any. 
This really does not qualify as a complex web form.

You'll get _exponentially_ more of the same. See paper "Plato: A 
Compiler for Interactive Web Forms", 
http://www.cs.uic.edu/~hinrichs/papers/hinrichs2011plato.pdf

-- 
Wojtek

From wojtek at power.com.pl  Tue Aug 12 22:44:18 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 00:44:18 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <7D47F026-3575-4953-8CC7-198A97EFB0A7@dc.uba.ar>
References: <53E940BF.5040500@power.com.pl>
 <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>
 <53EA69B7.7050307@power.com.pl>
 <7D47F026-3575-4953-8CC7-198A97EFB0A7@dc.uba.ar>
Message-ID: <53EA98C2.3030506@power.com.pl>


On 13.08.2014 00:26, Daniel Gor?n wrote:
> On 12 Aug 2014, at 20:23, Wojciech Narczy?ski <wojtek at power.com.pl> wrote:
>
>> W dniu 2014-08-12 15:01, Daniel Gor?n pisze:
>>> On 11 Aug 2014, at 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
>>>
>>>> If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.
>>> At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:
>>>
>>> data Person f
>>>    = Person {
>>>      firstName :: f String
>>>    ,lastName :: f String
>>>    ,birthDate :: f Date
>>>    ,height :: f Int
>>>    }
>>>
>>> Then you get:
>>>
>>>   - "Person Id" is a person with every field set in stone.
>>>
>>>   - "Person Maybe" is a person with missing information.
>>>
>>>   - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.
>>>
>>>
>>>
>> I saw in the presentation submitted in another post that a similar thing has been done in Vinyl. But this won't work so well, because in the "rigid" type some fields are still supposed to remain wrapped in Maybe.
> That?s not necessary a problem. If you add a field:
>
>    ,favoriteNumber :: f (Maybe Int)
>
> Then, in Person Maybe, a value of Nothing in favoriteNumber would mean ?not entered? while Just Nothing would be ?none?. Maybe you have some specific problem in mind?
>
There is such a distinction in certain DBMSes: null vs "". It is 
confusing even to developers, not to mention users.

From wojtek at power.com.pl  Tue Aug 12 22:56:27 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 00:56:27 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
 <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
Message-ID: <53EA9B9B.3030508@power.com.pl>

On 13.08.2014 00:13, Alberto G. Corona wrote:
> I did the todo application, (see todomvc.com <http://todomvc.com>) to 
> check if the concept was expressive and robust enough to do it:
>
> https://github.com/agocorona/hplay-todo
>

I have seen the app running, I'm yet to take a look at the code.

>  I think that the model works and the haste compiler works very well 
> too. I don?t know any serious limitation.  "wcallback" generates 
> spurious DOM elements and so on, but that can be fixed.
>
>
Great. Overall, I'm impressed. This really looks like a practical way to 
keep the JS mess under the carpet.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/0ece2090/attachment.html>

From ok at cs.otago.ac.nz  Wed Aug 13 01:23:44 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Wed, 13 Aug 2014 13:23:44 +1200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9C868.9090406@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl>
Message-ID: <b01945bfe63f5fa6fe3042ee1e66b413.squirrel@chasm.otago.ac.nz>

> On 12.08.2014 05:31, ok at cs.otago.ac.nz wrote:

>> Even in Visual Basic, if an object is "constructed" via a lengthy
>> sequence of steps, it is good design to distinguish between two
>> different things": a fully constructed Foo object and a FooBuilder
>> object.  Sometimes they need to be the same object, but there really
>> do need to be two *interfaces*.  Once past the construction phase,
>> you want to KNOW that the object is fully constructed, and there are
>> things the constructor might do that you DON'T want other objects to
>> do.
>
> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs?

Follow the GRASP patterns.  Give the task to
the type/class that has enough information to do the job.
Remember, the goal is to not create invalid objects.
It makes no sense to have an Invoice validate itself,
because the whole aim is for invalid Invoices NEVER TO
EXIST.

Some validation is fairly shallow.  If you can check a
field as soon as it is typed, it might make sense to do
so.  (Or it might not.  That's a user interface design
question.)  Some validation is deeper, and can only be
done once you have full or nearly full information.
The obvious place to put deeper validation is
InvoiceBuilder; that, after all, is one of the principal
reasons to *have* an InvoiceBuilder.

By the way, I deny that you would have a delirious menagerie
of _Builder classes, as you seem to be implying.  There needs
to be something *separate* from an InvoiceLineItem that can
accumulate the information needed to build one, and can
validate that information before the thing is built, but an
InvoiceBuilder can take responsibility for building all the
components of an Invoice.

So which types/classes deserve their own _Builder and which
do not?
- First, the _Builder pattern applies for things that
  have to be built up *incrementally* and may be in
  incomplete or inconsistent states while they are being
  built.  If you can construct something all at once in a
  fully valid state, you should, and don't need a Builder.
  If you can build something in a complete valid state and
  then you want to revise it as part of normal operation,
  again you don't need a builder.
- Second, some things are "free-standing" and some only
  make sense as part of other things.  I'm not sure exactly
  what you have in mind by an InvoiceSummary, but let's
  assume that an InvoiceSummary belongs to one and only one
  Invoice and that it doesn't really make sense for an
  InvoiceSummary to exist on its own.  Then it can share
  its owner's Builder.

In OO terms, the pattern goes something like this:
  program creates an InvoiceBuilder x
  filling out and revising the form revises x.
  there is a "commit" button; when x processes that,
  it creates a new Invoice y.
  y fills itself in, calling back to x to get the
  information it needs.  y may create its dependents;
  in fact, since a dependent should be *born* knowing
  what it depends on, the dependents *can't* be created
  until y exists.  So it probably should be y that does
  the creation.
  Eventually y finishes initialising itself, and x is
  now able to make y visible elsewhere.

The term "Builder" may be a bit misleading: the job of a
Builder is to *accumulate the information needed for
complete construction*; the actual work of construction
may be done by the new object that is eventually created,
including the creation of its parts.

The key thing is that *incompletely or inconsistently objects
are never exposed*; the first time a thing is mentionable, it
is right.

> Optional / mandatory
> requirements, lengths, ranges, regexps, control sums, field
> interdependencies, autocompletes, server sent notifications? Where to
> put all of this? To regular classes, to builder classes, or to both?

There are two and only two honest answers to questions like that.
(A) This sounds like carping, not like a real question.
(B) "It depends."  Put it wherever it works best.

Invoices are actually a nice example.  I had a student once who
told me a bit about SAP.  (He made a lot more money as a SAP
expert than I make as a lecturer.)  As I understand it, one of the
key reasons to use SAP is that once a record has gone into the
data base, it cannot be changed or deleted.  It can be marked as
not to be used any more, but it can't go away.  It can be marked
as having been superseded by a corrected version, but it can't be
changed.  So if you want to create an invoice in SAP, you really
really want to use the Builder pattern (at least in spirit).
Once the various tuples that constitute the Invoice have been
inserted in the data base, changing them is very far from being
normal operation.  For SAP, at least, I can say "put all those
things anywhere you like EXCEPT in the (persistent) Invoice."

And of course in the real world, if you are old enough you have
had the experience of interacting with an InvoiceBuilder.
You the customer, in the act of buying carpet, are sitting
on one side of the desk.  On the desk is the Invoice.  On the
other side of the desk is the InvoiceBuilder, otherwise known as
"a salesman", who gathers information from you, and fills in the
invoice.  You don't interact with the Invoice.  It just sits there.
Once the Invoice leaves the desk, the information on it normally
should not change.  If it is to change, a corrected duplicate is
made, the old one crossed out, and the new one stapled to it.
Doing this might even require the customer's signature on the new one.
The rest of the business only deals with complete Invoices.

Of course, it _all_ depends.  If you are whipping up a prototype
and speed of development (so you can get to answer some high-risk
question soon) is a priority, cut all the corners you think
appropriate.



From ok at cs.otago.ac.nz  Wed Aug 13 01:27:03 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Wed, 13 Aug 2014 13:27:03 +1200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9C868.9090406@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl>
Message-ID: <4bb8dc2522b55e421f2446d58be93b2e.squirrel@chasm.otago.ac.nz>


> On 12.08.2014 05:31, ok at cs.otago.ac.nz wrote:

>> Even in Visual Basic, if an object is "constructed" via a lengthy
>> sequence of steps, it is good design to distinguish between two
>> different things": a fully constructed Foo object and a FooBuilder
>> object.  Sometimes they need to be the same object, but there really
>> do need to be two *interfaces*.  Once past the construction phase,
>> you want to KNOW that the object is fully constructed, and there are
>> things the constructor might do that you DON'T want other objects to
>> do.
>
> Take a VAT Invoice as an example. You will have:
>
> Invoice, InvoiceBuilder,
> InvoiceLineItem, InvoiceLineItemBuilder,
> InvoiceCustomer, InvoiceCustomerBuilder,
> InvoiceSummary, (no Builder, as this is calculated)
> (many, many more classes in a realistic system)
>
> Now, where the rather complex validation belongs?

Follow the GRASP patterns.  Give the task to
the type/class that has enough information to do the job.
Remember, the goal is to not create invalid objects.
It makes no sense to have an Invoice validate itself,
because the whole aim is for invalid Invoices NEVER TO
EXIST.

Some validation is fairly shallow.  If you can check a
field as soon as it is typed, it might make sense to do
so.  (Or it might not.  That's a user interface design
question.)  Some validation is deeper, and can only be
done once you have full or nearly full information.
The obvious place to put deeper validation is
InvoiceBuilder; that, after all, is one of the principal
reasons to *have* an InvoiceBuilder.

By the way, I deny that you would have a delirious menagerie
of _Builder classes, as you seem to be implying.  There needs
to be something *separate* from an InvoiceLineItem that can
accumulate the information needed to build one, and can
validate that information before the thing is built, but an
InvoiceBuilder can take responsibility for building all the
components of an Invoice.

So which types/classes deserve their own _Builder and which
do not?
- First, the _Builder pattern applies for things that
  have to be built up *incrementally* and may be in
  incomplete or inconsistent states while they are being
  built.  If you can construct something all at once in a
  fully valid state, you should, and don't need a Builder.
  If you can build something in a complete valid state and
  then you want to revise it as part of normal operation,
  again you don't need a builder.
- Second, some things are "free-standing" and some only
  make sense as part of other things.  I'm not sure exactly
  what you have in mind by an InvoiceSummary, but let's
  assume that an InvoiceSummary belongs to one and only one
  Invoice and that it doesn't really make sense for an
  InvoiceSummary to exist on its own.  Then it can share
  its owner's Builder.

In OO terms, the pattern goes something like this:
  program creates an InvoiceBuilder x
  filling out and revising the form revises x.
  there is a "commit" button; when x processes that,
  it creates a new Invoice y.
  y fills itself in, calling back to x to get the
  information it needs.  y may create its dependents;
  in fact, since a dependent should be *born* knowing
  what it depends on, the dependents *can't* be created
  until y exists.  So it probably should be y that does
  the creation.
  Eventually y finishes initialising itself, and x is
  now able to make y visible elsewhere.

The term "Builder" may be a bit misleading: the job of a
Builder is to *accumulate the information needed for
complete construction*; the actual work of construction
may be done by the new object that is eventually created,
including the creation of its parts.

The key thing is that *incompletely or inconsistently objects
are never exposed*; the first time a thing is mentionable, it
is right.

> Optional / mandatory
> requirements, lengths, ranges, regexps, control sums, field
> interdependencies, autocompletes, server sent notifications? Where to
> put all of this? To regular classes, to builder classes, or to both?

There are two and only two honest answers to questions like that.
(A) This sounds like carping, not like a real question.
(B) "It depends."  Put it wherever it works best.

Invoices are actually a nice example.  I had a student once who
told me a bit about SAP.  (He made a lot more money as a SAP
expert than I make as a lecturer.)  As I understand it, one of the
key reasons to use SAP is that once a record has gone into the
data base, it cannot be changed or deleted.  It can be marked as
not to be used any more, but it can't go away.  It can be marked
as having been superseded by a corrected version, but it can't be
changed.  So if you want to create an invoice in SAP, you really
really want to use the Builder pattern (at least in spirit).
Once the various tuples that constitute the Invoice have been
inserted in the data base, changing them is very far from being
normal operation.  For SAP, at least, I can say "put all those
things anywhere you like EXCEPT in the (persistent) Invoice."

And of course in the real world, if you are old enough you have
had the experience of interacting with an InvoiceBuilder.
You the customer, in the act of buying carpet, are sitting
on one side of the desk.  On the desk is the Invoice.  On the
other side of the desk is the InvoiceBuilder, otherwise known as
"a salesman", who gathers information from you, and fills in the
invoice.  You don't interact with the Invoice.  It just sits there.
Once the Invoice leaves the desk, the information on it normally
should not change.  If it is to change, a corrected duplicate is
made, the old one crossed out, and the new one stapled to it.
Doing this might even require the customer's signature on the new one.
The rest of the business only deals with complete Invoices.

Of course, it _all_ depends.  If you are whipping up a prototype
and speed of development (so you can get to answer some high-risk
question soon) is a priority, cut all the corners you think
appropriate.





From wojtek at power.com.pl  Wed Aug 13 07:06:18 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 09:06:18 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <4bb8dc2522b55e421f2446d58be93b2e.squirrel@chasm.otago.ac.nz>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl>
 <4bb8dc2522b55e421f2446d58be93b2e.squirrel@chasm.otago.ac.nz>
Message-ID: <53EB0E6A.9070202@power.com.pl>

On 13.08.2014 03:27, ok at cs.otago.ac.nz wrote:
> By the way, I deny that you would have a delirious menagerie
> of _Builder classes, as you seem to be implying.
So how exactly would you store InvoiceLine-wannabe, Customer-wannabe, 
and the like, objects inside InvoiceBuilder? OO always has the same 
answer: more patterns, more classes. This is not OO list, so hereby I 
declare not to continue this fork of this thread.

Regarding SAP, ABAP is in fact a nice DSL, but did he also tell you that 
all the custom procedure names must start from 'Z'?

(VAT) Invoice, is a good example, I wish it were used more often, in 
addition to the TODO list.

-- 
Kind regards from the other side of Earth,
Wojtek Narczy?ski

From rikvdkleij at gmail.com  Wed Aug 13 09:05:32 2014
From: rikvdkleij at gmail.com (Rik van der Kleij)
Date: Wed, 13 Aug 2014 02:05:32 -0700 (PDT)
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
 <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
Message-ID: <a734fc85-9f8a-4ac6-8334-2a53b7ce07b1@googlegroups.com>

Maybe you should port hplayground to purescript and virtual-dom :-)


On Wednesday, 13 August 2014 00:13:42 UTC+2, Alberto G. Corona wrote:
>
> I did the todo application, (see todomvc.com) to check if the concept was 
> expressive and robust enough to do it:
>
> https://github.com/agocorona/hplay-todo
>
>  I think that the model works and the haste compiler works very well too. 
> I don?t know any serious limitation.  "wcallback" generates spurious DOM 
> elements and so on, but that can be fixed. 
>
>
>
>
>
>
> 2014-08-12 23:42 GMT+02:00 Wojtek Narczy?ski <woj... at power.com.pl 
> <javascript:>>:
>
>> On 12.08.2014 23:27, Alberto G. Corona wrote:
>>
>>> Well, it is not a hack. It is the way hplayground works . normally it 
>>> rewrite the HTML DOM of the implicit divs that are below  the event source. 
>>> "at" permits to assign freely that location.
>>>
>>
>> Okay, I see.
>>
>> 3. Are you yourself aware of any serious limitations of your approach?
>>
>> -- 
>> Wojtek
>>
>
>
>
> -- 
> Alberto. 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/340f7316/attachment.html>

From j at functor.se  Wed Aug 13 09:28:49 2014
From: j at functor.se (Johan Glimming)
Date: Wed, 13 Aug 2014 11:28:49 +0200
Subject: [Haskell-cafe] Openings for brilliant Haskell devs for exciting
	project "as close to a space station as you can get" @
	Swedish spinoff, DSLs/safety-critical/embedded software, and more
Message-ID: <FABF104A-EB31-4C09-9DDF-7DDACC654CE9@functor.se>

Dear All,

I?d like to share this exciting job opportunity (formatted text below), as this forum might be right for the very skilled developers we are looking for here. The LinkedIn posting is on the following webpage, e.g. in case the email does not display correctly:

https://www.linkedin.com/today/post/article/20140812174919-547525-openings-for-brilliant-haskell-developer-with-e-g-an-exciting-project-as-close-to-a-space-station-as-you-can-get-swedish-spinoff-dsl-s-safety ?

Best wishes,
Johan Glimming

@ LinkedIn:  http://se.linkedin.com/in/glimming

?

Openings for brilliant Haskell devs for exciting project "as close to a space station as you can get" @ Swedish spinoff, DSLs/safety-critical/embedded software, and more

As we grow our business further we look for extraordinary Haskell developers to further strengthen our exceptionally skilled teams in our spinoff and startup Functor Group AB, Kista/Stockholm, Sweden, with subsidiaries.
www.functorgroup.com @functors +FunctorGroups

You would have an impressive background in computer science, with industrial experience and first-class academic education including certainly advanced functional programming. Compiler design skills are valued highly. Experience of static code analysis (tools and/or research) and safety-critical software and embedded software development are all relevant to this startup and spinoff.

You would be part of a team with extraordinary skills and work with other talented individuals which, for those with the right mindset, is extremely rewarding.

It's relevant with skill sets that include AFP, EDSLs, type systems, Martin-L?f type theory, dependent types, formal methods, standard-type static analysis tools (as we offer a new kind that adds dependent types to the abstract interpretation approach), experience from tools form e.g. Coverity, Klocwork, MathWorks,, Spec#, Coq, Agda, Epigram, Twelf or other such tools, LLVM, ANSI / ISO C, MISRA C, software testing, various programming languages and their implementation, domain-specific languages, DDD, language-based programming turned into our emerging method named language-driven development, logical frameworks, meta languages, operational semantics, logic, theorem provers. (Learn more atwww.functor.se.)
You should be able to contribute to very demanding, challenging, creative teamwork as it manifests itself in a pioneering high-tech spinoff.
This all means great responsibility, important contributions to be made, with multiple and varying roles in our highly dynamic work environment where you would be working with other exceptional talents and contribute with your passion for functional programming. You are assumed to share our enthusiasm for and commitment to the new constructive programming paradigm, and recognise the value and great importance of our research foundation, our core technology, being made available in the industry. You would share and nourish our vision for the future of the software industry with the new constructive programming paradigm based on type theory research and the next level of functional programming with EDSL integrated in programming as never done before.

But most important is of course your documented talent and experience in Haskell development at an industrial level as well as great teamwork skills and enthusiasm about relevant technologies, and being aligned with our mission (for which see www.functorgroup.com).


Several of our developers have higher academic degrees such as a PhD in computer science, logic or mathematics, including two of our Research Engineers, who are professors. (and two more in our Advisory Board, both with own spinoffs, plus an extensive network to leading researchers that we work closely with now and in the future).
Your experience may include software development in segments such as safety-critical software and embedded software, hardware modelling, advanced DSL implementation, compiler design and compiler technologies, GPU applications, implementing software testing tools and tools for formal methods.

We do not expect you to have all these listed skills, but we expect you to be exceptionally talented and contribute to the success and further growth of Functor Group and its subsidiaries. We are now in an extremely interesting but demanding phase as a spinoff eg with one extraordinarily high-profile customer. You will be part of that project and other very exciting customer projects where we deploy unmatched new technology that brings a new programming paradigm to the software industry, with customers internationally, and an exciting journey into a future where research progress is finally bring aligned with best-practices also in software engineering in a world where software drives innovation and much of growth, but where our technology opens up for much needed improvements in the way software is being developed, designed and tested.

Mail your application with resum? with references etc to jobs at functor.se. 

www.functorgroup.com 

Posted by Dr Johan Glimming at Functor Group AB and Functor AB

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/4d38bb64/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 105d24a.jpg
Type: image/jpg
Size: 38184 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/4d38bb64/attachment-0001.jpg>

From agocorona at gmail.com  Wed Aug 13 09:54:33 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 13 Aug 2014 11:54:33 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <a734fc85-9f8a-4ac6-8334-2a53b7ce07b1@googlegroups.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
 <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
 <a734fc85-9f8a-4ac6-8334-2a53b7ce07b1@googlegroups.com>
Message-ID: <CAArEJmZwonMHJ4d2Foz+fm_07hJRNkcUF4Wy1sO7CQXYe_77hQ@mail.gmail.com>

2014-08-13 11:05 GMT+02:00 Rik van der Kleij <rikvdkleij at gmail.com>:

> Maybe you should port hplayground to purescript and virtual-dom :-)
>
> why? for some special reason?

>
> On Wednesday, 13 August 2014 00:13:42 UTC+2, Alberto G. Corona wrote:
>
>> I did the todo application, (see todomvc.com) to check if the concept
>> was expressive and robust enough to do it:
>>
>> https://github.com/agocorona/hplay-todo
>>
>>  I think that the model works and the haste compiler works very well too.
>> I don?t know any serious limitation.  "wcallback" generates spurious DOM
>> elements and so on, but that can be fixed.
>>
>>
>>
>>
>>
>>
>> 2014-08-12 23:42 GMT+02:00 Wojtek Narczy?ski <woj... at power.com.pl>:
>>
>> On 12.08.2014 23:27, Alberto G. Corona wrote:
>>>
>>>> Well, it is not a hack. It is the way hplayground works . normally it
>>>> rewrite the HTML DOM of the implicit divs that are below  the event source.
>>>> "at" permits to assign freely that location.
>>>>
>>>
>>> Okay, I see.
>>>
>>> 3. Are you yourself aware of any serious limitations of your approach?
>>>
>>> --
>>> Wojtek
>>>
>>
>>
>>
>> --
>> Alberto.
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/7d18f9a3/attachment.html>

From rikvdkleij at gmail.com  Wed Aug 13 10:34:46 2014
From: rikvdkleij at gmail.com (Rik van der Kleij)
Date: Wed, 13 Aug 2014 03:34:46 -0700 (PDT)
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmZwonMHJ4d2Foz+fm_07hJRNkcUF4Wy1sO7CQXYe_77hQ@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
 <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
 <a734fc85-9f8a-4ac6-8334-2a53b7ce07b1@googlegroups.com>
 <CAArEJmZwonMHJ4d2Foz+fm_07hJRNkcUF4Wy1sO7CQXYe_77hQ@mail.gmail.com>
Message-ID: <32e5e8de-4aaa-474c-823e-f68e7755d85b@googlegroups.com>

Because it looks like virtual-dom is very well suited for how hplayground 
works. It's very efficient in rerendering the DOM tree when you have local 
changes. It's also very fast, see
http://elm-lang.org/blog/Blazing-Fast-Html.elm

Purescipt because it has a lot of speed in development (libraries) and 
generates in general leaner javascript. But I have no particular objections 
against Haste :-)

On Wednesday, 13 August 2014 11:55:04 UTC+2, Alberto G. Corona wrote:
>
> 2014-08-13 11:05 GMT+02:00 Rik van der Kleij <rikvd... at gmail.com 
> <javascript:>>:
>
>> Maybe you should port hplayground to purescript and virtual-dom :-)
>>
>> why? for some special reason? 
>
>>
>> On Wednesday, 13 August 2014 00:13:42 UTC+2, Alberto G. Corona wrote:
>>
>>> I did the todo application, (see todomvc.com) to check if the concept 
>>> was expressive and robust enough to do it:
>>>
>>> https://github.com/agocorona/hplay-todo
>>>
>>>  I think that the model works and the haste compiler works very well 
>>> too. I don?t know any serious limitation.  "wcallback" generates spurious 
>>> DOM elements and so on, but that can be fixed. 
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2014-08-12 23:42 GMT+02:00 Wojtek Narczy?ski <woj... at power.com.pl>:
>>>
>>> On 12.08.2014 23:27, Alberto G. Corona wrote:
>>>>
>>>>> Well, it is not a hack. It is the way hplayground works . normally it 
>>>>> rewrite the HTML DOM of the implicit divs that are below  the event source. 
>>>>> "at" permits to assign freely that location.
>>>>>
>>>>
>>>> Okay, I see.
>>>>
>>>> 3. Are you yourself aware of any serious limitations of your approach?
>>>>
>>>> -- 
>>>> Wojtek
>>>>
>>>
>>>
>>>
>>> -- 
>>> Alberto. 
>>>
>>
>
>
> -- 
> Alberto. 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/67874851/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Aug 13 10:37:58 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 13 Aug 2014 11:37:58 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53E9F06D.5090804@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl>
Message-ID: <20140813103758.GP1527@henry>

On Tue, Aug 12, 2014 at 12:46:05PM +0200, Wojtek Narczy?ski wrote:
> Continuing my VAT Invoice example, let us say a LineItem that does
> not have a product description (missing value), but it does have all
> the numeric fields filled in.  It is partly erroneous, but it can be
> included in calculation of the total. How would you handle it with
> Either [Error] Invoice style code?

What sort of functionality are you looking for exactly?  What's your
objection to (for example)

    data LineItemGeneral a = LineItem { price :: Price
                                      , quantity :: Quantity
                                      , description :: a }

    type LineItem = LineItemGeneral String
    type LineItemPossiblyIncomplete = LineItemGeneral (Maybe String)
    type LineItemWithoutDescription = LineItemGeneral ()

    totalValue :: LineItemGeneral a -> Value
    totalValue lineItem = price lineItem * quantity lineItem

`totalValue` works for all sorts of line items, whether they have a
description or not.

Tom

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Aug 13 10:40:20 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 13 Aug 2014 11:40:20 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA69B7.7050307@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CF2AC9A1-254D-45E1-AF22-835460EB5EFF@dc.uba.ar>
 <53EA69B7.7050307@power.com.pl>
Message-ID: <20140813104020.GQ1527@henry>

On Tue, Aug 12, 2014 at 09:23:35PM +0200, Wojciech Narczy?ski wrote:
> W dniu 2014-08-12 15:01, Daniel Gor?n pisze:
> >On 11 Aug 2014, at 23:16, Wojtek Narczy?ski <wojtek at power.com.pl> wrote:
> >
> >>If you declare Person class in Java, you automatically get a thingy that you can readily use in UI construction, because all the fields can temporarily be null, even the required ones. In Haskell you'd need two data types: the usual proper Haskell data type, and another which wraps every field in Maybe, facilitates editing, validation, etc. Perhaps it would be possible to generate one data type from the other, or generate both from a common specification.
> >At least this part you can achieve rather easily by parametrizing each field in your record by a functor. E.g.:
> >
> >data Person f
> >   = Person {
> >     firstName :: f String
> >   ,lastName :: f String
> >   ,birthDate :: f Date
> >   ,height :: f Int
> >   }
> >
> >Then you get:
> >
> >  - "Person Id" is a person with every field set in stone.
> >
> >  - "Person Maybe" is a person with missing information.
> >
> >  - Other functors can be easily defined (and then composed) to represent things such as Mandatory/Optional, Valid/Invalid, etc.
>
> I saw in the presentation submitted in another post that a similar
> thing has been done in Vinyl. But this won't work so well, because
> in the "rigid" type some fields are still supposed to remain wrapped
> in Maybe.

Then make the Person type completely freely polymorphic

    data Person f l b h = Person {
       firstName :: f
     , lastName :: l
     , birthDate :: b
     , height :: h
    }

I do this a lot, and with suitible type synonyms is really a nice way of
working (especially with lenses).

Tom

From agocorona at gmail.com  Wed Aug 13 11:01:09 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Wed, 13 Aug 2014 13:01:09 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <32e5e8de-4aaa-474c-823e-f68e7755d85b@googlegroups.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAArEJmbyuTTHqxmD6heFhq=s7bbj7byYOebnQ0i2FUjjV6f+Nw@mail.gmail.com>
 <CAArEJmZy1u4+upJWZ=bBySR=sd7wY0-ubPG3sbCehmH7V6LdRA@mail.gmail.com>
 <53EA689E.9080100@power.com.pl>
 <CAArEJmYRMgdU6cfGMxybZ7Xx1DM-bRf0LuEGG2oniWNr01ykcQ@mail.gmail.com>
 <CAArEJmb0xfCox_vDTvuRBvtczrjWFnL2iC3SjxRwbXZypQ7tow@mail.gmail.com>
 <53EA7E43.3010502@power.com.pl>
 <CAArEJmajFLwxoddEj2EYYCU_pVoh3i3B5UvgjGMHSa2Su0dTrw@mail.gmail.com>
 <53EA8A47.6070808@power.com.pl>
 <CAArEJmaoA-OBCOamCkE1G-6=8U-Hgk-4+yiy_3i48uF76buEOw@mail.gmail.com>
 <a734fc85-9f8a-4ac6-8334-2a53b7ce07b1@googlegroups.com>
 <CAArEJmZwonMHJ4d2Foz+fm_07hJRNkcUF4Wy1sO7CQXYe_77hQ@mail.gmail.com>
 <32e5e8de-4aaa-474c-823e-f68e7755d85b@googlegroups.com>
Message-ID: <CAArEJmbwLUdvimtJPxQ2C1z0A+KEU3ugReK5TnaPLbbU5=68Yg@mail.gmail.com>

Yep, but virtual-dom is more appropriate for declarative reactive
frameworks like elm. It need to know what parts of the DOM must be
refreshed because the whole elm expression is reevaluated when an event
happens. It need to detect the changes. Otherwise, it would have to repaint
the whole screen in each event.

Declarative reactive is like a giant event handler that all the events
execute. It may have some event/signal preprocessing  to mix events/signals
depending on timings by means of some special combinators, but at the end
it executes the whole declarative expression, which includes the
re-generation  of all the rendering.

hplayground execute just the part of the monad corresponding to the branch
in which the event happened. So it does not need to maintain the old and
the new version of the DOM in order to detect the parts to be updated. It
updates the affected branch of the DOM directly. So it must be faster (I
did not check it however).


2014-08-13 12:34 GMT+02:00 Rik van der Kleij <rikvdkleij at gmail.com>:

> Because it looks like virtual-dom is very well suited for how hplayground
> works. It's very efficient in rerendering the DOM tree when you have local
> changes. It's also very fast, see
> http://elm-lang.org/blog/Blazing-Fast-Html.elm
>
> Purescipt because it has a lot of speed in development (libraries) and
> generates in general leaner javascript. But I have no particular objections
> against Haste :-)
>
> On Wednesday, 13 August 2014 11:55:04 UTC+2, Alberto G. Corona wrote:
>>
>> 2014-08-13 11:05 GMT+02:00 Rik van der Kleij <rikvd... at gmail.com>:
>>
>> Maybe you should port hplayground to purescript and virtual-dom :-)
>>>
>>> why? for some special reason?
>>
>>>
>>> On Wednesday, 13 August 2014 00:13:42 UTC+2, Alberto G. Corona wrote:
>>>
>>>> I did the todo application, (see todomvc.com) to check if the concept
>>>> was expressive and robust enough to do it:
>>>>
>>>> https://github.com/agocorona/hplay-todo
>>>>
>>>>  I think that the model works and the haste compiler works very well
>>>> too. I don?t know any serious limitation.  "wcallback" generates spurious
>>>> DOM elements and so on, but that can be fixed.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2014-08-12 23:42 GMT+02:00 Wojtek Narczy?ski <woj... at power.com.pl>:
>>>>
>>>> On 12.08.2014 23:27, Alberto G. Corona wrote:
>>>>>
>>>>>> Well, it is not a hack. It is the way hplayground works . normally it
>>>>>> rewrite the HTML DOM of the implicit divs that are below  the event source.
>>>>>> "at" permits to assign freely that location.
>>>>>>
>>>>>
>>>>> Okay, I see.
>>>>>
>>>>> 3. Are you yourself aware of any serious limitations of your approach?
>>>>>
>>>>> --
>>>>> Wojtek
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alberto.
>>>>
>>>
>>
>>
>> --
>> Alberto.
>>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/8bc54c1c/attachment.html>

From hjgtuyl at chello.nl  Wed Aug 13 12:10:49 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Wed, 13 Aug 2014 14:10:49 +0200
Subject: [Haskell-cafe] Visualising Haskell function execution
In-Reply-To: <CADUbQ5i909x=FcSO61kmozTLNeodUwE+QauW9nu7cac3dtooag@mail.gmail.com>
References: <CAPtY9n+6onYBYb=pWP4NRmLq43zY6MGXQMuhmp2HfnUzhuOiyA@mail.gmail.com>
 <CADUbQ5i909x=FcSO61kmozTLNeodUwE+QauW9nu7cac3dtooag@mail.gmail.com>
Message-ID: <op.xki5gfcnpz0j5l@alquantor>

On Fri, 08 Aug 2014 17:52:38 +0200, Dominick Samperi <djsamperi at gmail.com>  
wrote:

> If I recall correctly the Leksah IDE shows GHC reduction step-by-step
> (using GHC debug info). Unfortunately, the last update was in 2012, so
> it appears
> that it has not been following the latest GHC releases.

Leksah still works, but it is not finished; it is only possible to step  
per (sub)expression, no stepping to the end of a function. The debugger  
has therefore a very limited use. I hope that a group of people will  
continue the development, an application like that is too big for one  
person.

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 apfelmus at quantentunnel.de  Wed Aug 13 13:42:59 2014
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Wed, 13 Aug 2014 15:42:59 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EA964A.3000404@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl>
Message-ID: <lsfq14$5b7$1@ger.gmane.org>

Wojtek Narczy?ski wrote:
> Heinrich Apfelmus wrote:
>> Wojtek Narczy?ski wrote:
>>>
>>> I would really like to see a complex web form (think Facebook, VAT 
>>> Invoice, Tax forms) done in FRP. The harsh reality is that FRP for 
>>> GUIs still has to prove that its utility reaches beyond the game of 
>>> Pong.
>>
>> Like this?
>>
>>   http://www.haskell.org/haskellwiki/Reactive-banana/Examples#crud
>>
>> It's still a toy model, but I think it captures the essential 
>> difficulties. A full blown tax form would just be more of the same.
>>
>>
> Is it live anywhere? I'd like to test it for HTML injection.

It's actually a wxHaskell applications, the screenshot is from a
temporary but now deprecated adaption to Threepenny-gui. So, the issue
of HTML injection does not arise. (It would not arise in a HTML context
either, because of strong typing.)

The key point about this CRUD example, which is not shown in the
screenshot, is that it has immediate feedback: values in the list box
change as you type. Editing the name on the right-hand side will change
the name in the list box, and changing the filter will immediately
update the available names in the list box.

> The #1 
> difficulty is validation. Is there any in this example? I can't see any. 
> This really does not qualify as a complex web form.
>
> You'll get _exponentially_ more of the same. See paper "Plato: A 
> Compiler for Interactive Web Forms", 
> http://www.cs.uic.edu/~hinrichs/papers/hinrichs2011plato.pdf

Validation is mainly a question of *how* to present feedback about
invalid data to the user -- for instance by making invalid data
impossible to enter, or by showing errors in red and retaining the last 
correct value, etc.

I would consider this as a narrow part of GUI programming. For me, GUI 
programming is about user interfaces and interaction design in general, 
including zoom, animation, games, and so on. FRP is a better tool at 
this than the traditional event-based style.

Of course, in the context of form validation, FRP would be a building 
block: It does not give any advice on which feedback to present to the 
user, but it does allow you to quickly implement whatever feedback you 
have chosen to present.


Still, even for the more narrow problem of forms and input validation, I 
don't see how you arrive at your claim that "Haskell is however not 
great for GUIs". This seems like a problem that can be solved with a 
traditional DSL approach, and I would be surprised if Haskell were 
unsuitable as a host language, contrary to what your claim seems to 
imply. Whether DSLs along these lines are already available is another 
question. Alberto mentioned one, another one would be [1].

  [1]: http://www.sandr.dds.nl/publications/FForms.pdf


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From wojtek at power.com.pl  Wed Aug 13 20:31:31 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 22:31:31 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140813103758.GP1527@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
Message-ID: <53EBCB23.9030306@power.com.pl>


On 13.08.2014 12:37, Tom Ellis wrote:
> On Tue, Aug 12, 2014 at 12:46:05PM +0200, Wojtek Narczy?ski wrote:
>> Continuing my VAT Invoice example, let us say a LineItem that does
>> not have a product description (missing value), but it does have all
>> the numeric fields filled in.  It is partly erroneous, but it can be
>> included in calculation of the total. How would you handle it with
>> Either [Error] Invoice style code?
> What sort of functionality are you looking for exactly?  What's your
> objection to (for example)
>
>      data LineItemGeneral a = LineItem { price :: Price
>                                        , quantity :: Quantity
>                                        , description :: a }
>
>      type LineItem = LineItemGeneral String
>      type LineItemPossiblyIncomplete = LineItemGeneral (Maybe String)
>      type LineItemWithoutDescription = LineItemGeneral ()
>
>      totalValue :: LineItemGeneral a -> Value
>      totalValue lineItem = price lineItem * quantity lineItem
>
> `totalValue` works for all sorts of line items, whether they have a
> description or not.
>
>
Let's say the user entered:

No, Name, Qty, Price
--------------------------------------------
1. [        ]   [99] [10]
2. [Water] [    ] [10]
3. [Juice]   [  1] [    ]

The GUI should display total of 990, and signal four errors: three 
missing values (ideally different color of the input fields), and the 
whole invoice incomplete. The Either [Error] Invoice type does not work, 
because can either display the errors or calculate total from a correct 
invoice, never both. And you can't even create LineItem for 2. and 3. 
Well, maybe you can with laziness, but how would total work then?

That's why I asked in my original post, whether I'd need two types, one 
for correct complete invoice, and another for the invoice "in statu 
nascendi". And how to obtain them, lazily, and I mean the person, not 
the language.

-- 
Wojtek

From steve at fenestra.com  Wed Aug 13 20:49:57 2014
From: steve at fenestra.com (Steve Schafer)
Date: Wed, 13 Aug 2014 16:49:57 -0400
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBCB23.9030306@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
Message-ID: <dijnu99g1f5e56avigrvnic0ac299k2nbn@4ax.com>

On Wed, 13 Aug 2014 22:31:31 +0200, Wojtek Narczy?ski
<wojtek at power.com.pl> wrote:

>Let's say the user entered:
>
>No, Name, Qty, Price
>--------------------------------------------
>1. [        ]   [99] [10]
>2. [Water] [    ] [10]
>3. [Juice]   [  1] [    ]
>
>The GUI should display total of 990

Why? Why are any of these erroneous line items included in the total? I
would argue that an incomplete or otherwise erroneous line item is not
part of the invoice.

I don't know of any (reasonable) online merchant that requires the user
to separately enter item, quantity and price. Typically, the user
interface is designed explicitly to prohibit an incomplete line item of
this sort.

-Steve Schafer

From wojtek at power.com.pl  Wed Aug 13 21:19:24 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 23:19:24 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <lsfq14$5b7$1@ger.gmane.org>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
Message-ID: <53EBD65C.6000501@power.com.pl>

On 13.08.2014 15:42, Heinrich Apfelmus wrote:
> Validation is mainly a question of *how* to present feedback about
> invalid data to the user -- for instance by making invalid data
> impossible to enter, or by showing errors in red and retaining the 
> last correct value, etc.

I don't even know how to capture validation rules in such a way that 
they were easy to use from the GUI layer. I suspect if they were 
captured well, whatever well might mean in this context, a functioning 
GUI could be autogenerated from those rules.

And I don't understand FRP code. I could however understand Eduardo's 
client side formlets almost immediately. Not now they work below, how to 
use them.

> Still, even for the more narrow problem of forms and input validation, 
> I don't see how you arrive at your claim that "Haskell is however not 
> great for GUIs". This seems like a problem that can be solved with a 
> traditional DSL approach, and I would be surprised if Haskell were 
> unsuitable as a host language, contrary to what your claim seems to 
> imply. Whether DSLs along these lines are already available is another 
> question. Alberto mentioned one, another one would be [1].
>

Oh, please. Haskell is great for parsing, because you can build a parser 
with e.g. parsec, attoparsec, uuparse, trifeca, in no time. Even I can 
do it. Haskell is great for concurrency, because it has lightweight 
threads, STM, and a fabulous book about it. Haskell is great for GUIs, 
because.... how about you finish this statement, I don't know how to.

-- 
Kind reagrds,
Wojtek Narczynski

From wojtek at power.com.pl  Wed Aug 13 21:27:10 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Wed, 13 Aug 2014 23:27:10 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <dijnu99g1f5e56avigrvnic0ac299k2nbn@4ax.com>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <dijnu99g1f5e56avigrvnic0ac299k2nbn@4ax.com>
Message-ID: <53EBD82E.9070905@power.com.pl>

On 13.08.2014 22:49, Steve Schafer wrote:
> On Wed, 13 Aug 2014 22:31:31 +0200, Wojtek Narczy?ski
> <wojtek at power.com.pl> wrote:
>
>> Let's say the user entered:
>>
>> No, Name, Qty, Price
>> --------------------------------------------
>> 1. [        ]   [99] [10]
>> 2. [Water] [    ] [10]
>> 3. [Juice]   [  1] [    ]
>>
>> The GUI should display total of 990
> Why? Why are any of these erroneous line items included in the total? I
> would argue that an incomplete or otherwise erroneous line item is not
> part of the invoice.
Say that the error is merely a warning, for example the user entered 'A' 
which is suspiciously short.
> I don't know of any (reasonable) online merchant that requires the user
> to separately enter item, quantity and price.
Yes, it is terrible. It's called "accounting".

From alex at lagoa.com  Wed Aug 13 21:28:23 2014
From: alex at lagoa.com (Alexander Vieth)
Date: Wed, 13 Aug 2014 17:28:23 -0400
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBD65C.6000501@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
 <53EBD65C.6000501@power.com.pl>
Message-ID: <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>

> Oh, please. Haskell is great for parsing, because you can build a parser with e.g. parsec, attoparsec, uuparse, trifeca, in no time. Even I can do it. Haskell is great for concurrency, because it has lightweight threads, STM, and a fabulous book about it. Haskell is great for GUIs, because.... how about you finish this statement, I don't know how to.

Before parsec, attoparsec, uuparse, et al were invented, was Haskell no good for parsing? When we speak of Haskell do we speak of the entire ecosystem, or just the language itself? I think Heinrich meant that Haskell, the language, is probably capable of carrying a great library for expressing GUI's, even if we haven't yet seen it implemented.

Alex

On 2014-08-13, at 5:19 PM, Wojtek Narczy?ski wrote:

> On 13.08.2014 15:42, Heinrich Apfelmus wrote:
>> Validation is mainly a question of *how* to present feedback about
>> invalid data to the user -- for instance by making invalid data
>> impossible to enter, or by showing errors in red and retaining the last correct value, etc.
> 
> I don't even know how to capture validation rules in such a way that they were easy to use from the GUI layer. I suspect if they were captured well, whatever well might mean in this context, a functioning GUI could be autogenerated from those rules.
> 
> And I don't understand FRP code. I could however understand Eduardo's client side formlets almost immediately. Not now they work below, how to use them.
> 
>> Still, even for the more narrow problem of forms and input validation, I don't see how you arrive at your claim that "Haskell is however not great for GUIs". This seems like a problem that can be solved with a traditional DSL approach, and I would be surprised if Haskell were unsuitable as a host language, contrary to what your claim seems to imply. Whether DSLs along these lines are already available is another question. Alberto mentioned one, another one would be [1].
>> 
> 
> Oh, please. Haskell is great for parsing, because you can build a parser with e.g. parsec, attoparsec, uuparse, trifeca, in no time. Even I can do it. Haskell is great for concurrency, because it has lightweight threads, STM, and a fabulous book about it. Haskell is great for GUIs, because.... how about you finish this statement, I don't know how to.
> 
> -- 
> Kind reagrds,
> Wojtek Narczynski
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From kc1956 at gmail.com  Wed Aug 13 21:39:01 2014
From: kc1956 at gmail.com (KC)
Date: Wed, 13 Aug 2014 14:39:01 -0700
Subject: [Haskell-cafe] Does the lambda calculus have provisions for I/O?
 State can be done with free variables.
Message-ID: <CAMLKXynJhDV-WA-5Yb1=vVHoy5mwL+TZODXMKN182Ch5+3VuQg@mail.gmail.com>

Hi:

Does the lambda calculus have provisions for I/O?
State can be done with free variables.

-- 

--

Sent from an expensive device which will be obsolete in a few months! :D
Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/2c535f3e/attachment.html>

From wojtek at power.com.pl  Wed Aug 13 23:19:19 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 01:19:19 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
 <53EBD65C.6000501@power.com.pl>
 <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>
Message-ID: <53EBF277.2050400@power.com.pl>

On 13.08.2014 23:28, Alexander Vieth wrote:
>> Oh, please. Haskell is great for parsing, because you can build a parser with e.g. parsec, attoparsec, uuparse, trifeca, in no time. Even I can do it. Haskell is great for concurrency, because it has lightweight threads, STM, and a fabulous book about it. Haskell is great for GUIs, because.... how about you finish this statement, I don't know how to.
> Before parsec, attoparsec, uuparse, et al were invented, was Haskell no good for parsing? When we speak of Haskell do we speak of the entire ecosystem, or just the language itself?

It is clear what I meant.

> I think Heinrich meant that Haskell, the language, is probably capable of carrying a great library for expressing GUI's, even if we haven't yet seen it implemented.
>
>

Haskell, the language, is great for GUIs, because... "(it) is probably 
capable of carrying a great library for expressing GUI's, even if we 
haven't yet seen it implemented." This is too much, I need to sleep it off.



From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Aug 13 23:21:56 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 00:21:56 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBCB23.9030306@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
Message-ID: <20140813232155.GB25954@henry>

On Wed, Aug 13, 2014 at 10:31:31PM +0200, Wojtek Narczy?ski wrote:
> On 13.08.2014 12:37, Tom Ellis wrote:
> >On Tue, Aug 12, 2014 at 12:46:05PM +0200, Wojtek Narczy?ski wrote:
> >>Continuing my VAT Invoice example, let us say a LineItem that does
> >>not have a product description (missing value), but it does have all
> >>the numeric fields filled in.  It is partly erroneous, but it can be
> >>included in calculation of the total. How would you handle it with
> >>Either [Error] Invoice style code?
> >What sort of functionality are you looking for exactly?  What's your
> >objection to (for example)
> >
> >     data LineItemGeneral a = LineItem { price :: Price
> >                                       , quantity :: Quantity
> >                                       , description :: a }
> >
> >     type LineItem = LineItemGeneral String
> >     type LineItemPossiblyIncomplete = LineItemGeneral (Maybe String)
> >     type LineItemWithoutDescription = LineItemGeneral ()
> >
> >     totalValue :: LineItemGeneral a -> Value
> >     totalValue lineItem = price lineItem * quantity lineItem
> >
> >`totalValue` works for all sorts of line items, whether they have a
> >description or not.
>
> Let's say the user entered:
> 
> No, Name, Qty, Price
> --------------------------------------------
> 1. [        ]   [99] [10]
> 2. [Water] [    ] [10]
> 3. [Juice]   [  1] [    ]
> 
> The GUI should display total of 990, and signal four errors: three
> missing values (ideally different color of the input fields), and
> the whole invoice incomplete. The Either [Error] Invoice type does
> not work, because can either display the errors or calculate total
> from a correct invoice, never both. And you can't even create
> LineItem for 2. and 3. Well, maybe you can with laziness, but how
> would total work then?
> 
> That's why I asked in my original post, whether I'd need two types,
> one for correct complete invoice, and another for the invoice "in
> statu nascendi". And how to obtain them, lazily, and I mean the
> person, not the language.

Perhaps I don't grasp exactly what you're getting at, but this seems easy. 
Please let me know where my proposed solution fails to provide what you
need.  

I do see that you originally said "In Haskell you'd need two data types: the
usual proper Haskell data type, and another which wraps every field in
Maybe, facilitates editing, validation, etc.".  You don't actually *need*
the version without the Maybe, but you can provide it if you want some
additional type safety.  If you'd like to see an example of making that
nice and easy with minimal boilerplate please ask.


    import Control.Applicative
    import Data.Maybe
    import Control.Arrow
    
    type Quantity = Double
    type Price = Double
    type Value = Double
    
    data LineItem = LineItem { name :: Maybe String
                             , quantity :: Maybe Quantity
                             , price :: Maybe Price }
    
    data Field = NameField | QuantityField | PriceField
               deriving Show
    
    data Error = Error { item :: Int
                       , missing :: Field }
               deriving Show
    
    value :: LineItem -> Maybe Value
    value l = (*) <$> price l <*> quantity l
    
    totalValue :: [LineItem] -> Value
    totalValue = sum . map (fromMaybe 0 . value)
    
    missingFields :: LineItem -> [Field]
    missingFields l = n ++ q ++ p
      where n = if name l == Nothing then [NameField] else []
            q = if quantity l == Nothing then [QuantityField] else []
            p = if price l == Nothing then [PriceField] else []
    
    errors :: [LineItem] -> [Error]
    errors = concatMap (\(i, es) -> map (Error i) es)   
             . zip [1..]
             . map missingFields    
    
    guiResponse :: [LineItem] -> (Value, [Error])
    guiResponse = totalValue &&& errors
    
    exampleData :: [LineItem]
    exampleData = [ LineItem Nothing        (Just 99) (Just 10)
                  , LineItem (Just "Water") Nothing   (Just 10)
                  , LineItem (Just "Juice") (Just 1)  Nothing ]
                  
    -- *Main> guiResponse exampleData 
    -- (990.0, [ Error {item = 1, missing = NameField}
    --         , Error {item = 2, missing = QuantityField}
    --         , Error {item = 3, missing = PriceField}])

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Aug 13 23:23:12 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 00:23:12 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBF277.2050400@power.com.pl>
References: <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
 <53EBD65C.6000501@power.com.pl>
 <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>
 <53EBF277.2050400@power.com.pl>
Message-ID: <20140813232311.GC25954@henry>

On Thu, Aug 14, 2014 at 01:19:19AM +0200, Wojtek Narczy?ski wrote:
> On 13.08.2014 23:28, Alexander Vieth wrote:
> >>Oh, please. Haskell is great for parsing, because you can build a parser
> >> with e.g.  parsec, attoparsec, uuparse, trifeca, in no time.  Even I
> >> can do it.  Haskell is great for concurrency, because it has
> >> lightweight threads, STM, and a fabulous book about it.  Haskell is
> >> great for GUIs, because....  how about you finish this statement, I
> >> don't know how to.
>
> >Before parsec, attoparsec, uuparse, et al were invented, was Haskell no
> > good for parsing?  When we speak of Haskell do we speak of the entire
> > ecosystem, or just the language itself?
> 
> It is clear what I meant.
> 
> >I think Heinrich meant that Haskell, the language, is probably capable of
> > carrying a great library for expressing GUI's, even if we haven't yet
> > seen it implemented.
> 
> Haskell, the language, is great for GUIs, because... "(it) is
> probably capable of carrying a great library for expressing GUI's,
> even if we haven't yet seen it implemented." This is too much, I
> need to sleep it off.

Perhaps you could give an example of a language that is "great for GUIs" and
a great functional snippet of GUI code in that language.  Otherwise we're
just discussing in the abstract which tends not to be very helpful.

Tom

From ianmllgn at gmail.com  Thu Aug 14 00:02:23 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Wed, 13 Aug 2014 17:02:23 -0700
Subject: [Haskell-cafe] Closed Type Family Simplification
Message-ID: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>

When a closed type family has only one instance it seems like it should
never fail to simplify. Yet this doesn't appear to be the case. When I
defined (in GHC 7.8.3) the closed type family
type family (:.:) f g a where (:.:) f g a = f (g a)
I get errors such as
'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))'
(where Object is a Constraint family), indicating that f (g a) is not being
substituted for (:.:) f g a as desired. Any idea why this happens?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/e4541636/attachment.html>

From auke at tulcod.com  Thu Aug 14 00:19:11 2014
From: auke at tulcod.com (Auke Booij)
Date: Thu, 14 Aug 2014 02:19:11 +0200
Subject: [Haskell-cafe] ANNOUNCE: hayland 0.1.0.0
Message-ID: <CAP6YhLLV5LG4cx_Qd_bu=96HYV05ZjhBuVtfR36EPmsxi=aMmg@mail.gmail.com>

I just pushed the first release of the Haskell bindings to Wayland
I've been working on to Hackage.


SHAMELESS SPAM
-----
I'm looking for a PhD position in (mathematical) type theory
(preferably in Europe). Contact me for my (interesting!) background.


What is Wayland?
-----
For those of you who have been living under a rock, X11 is probably
going to be ditched soon (porting work for GNOME, KDE, and E is
already well underway), and the graphics stack reworked, in favor of
"wayland". There will no longer be a monolithic server between the
compositor (aka window manager) and the window clients. In the new
design, the compositor *is* the central server.

The new architecture allows for proper isolation of clients (a HUGE
security improvement over X11), as well as major cleanups of code
(enabling embedded use).


Why bind to C code?
-----
In theory, wayland should only be a protocol specification (which
happens to have a reference implementation) which could be implemented
in Haskell. However, the current state of the matter is that for EGL
implementation reasons, one is forced to bind to this reference
implementation. (More precisely, the EGL libraries need to be able to
configure wayland - and such code would have to be written for every
wayland implementation.)

So in practice, one can't write a pure Haskell implementation, and
that's why I made bindings for the C library.


Where's the code?
-----
https://github.com/tulcod/haskell-wayland


Wait, why are you even binding to Wayland?
-----
Not sure, but it's pretty foundational stuff so I'm sure it'll be of
use to someone, somewhere. Maybe someone wants to write a window
manager for the new ecosystem (I'm looking at you XMonad)?


Wow, I've never seen a module expose this many symbols
-----
Yes, if anyone has ideas on how to reorganize and/or clean up the
symbols exposed by the various part of the library, I am most
interested.

The problem here is that I'm generating a lot of code using template
haskell, and TH does not give you control over which symbols you want
to expose and how. I could write this list to a haskell source file at
configure time instead (which might be useful for other reasons as
well), but ideally I would like to split up the library into the
various "interfaces" wayland offers - but these interfaces are unknown
at dev time time, and I don't think there is remotely any mechanism to
generate /modules/ at compile time.

I'm interested to hear what you guys think about controlling the
symbol exposure of TH-generated code.


TemplateHaskell /and/ GeneralizedNewtypeDeriving? Are you /trying/ to
derive bottom?
-----
Well I sacrificed some Safety in favor of exposing nice Haskelly
types. Feedback is welcome.


Final note
-----
By the way, I also wrote bindings to xkbcommon a while ago, although
they need some attention. Anyway, my point is that with hayland and
xkbcommon in place (both in a semi-usable state), there should be
plenty of groundwork ready for you to get started with Wayland on
Haskell.

(xkbcommon is the de facto standard library to work with keyboard
layouts in wayland. It translates keyboard events ("which key did you
press") into Unicode symbols ("what letter should appear on the
screen"), using the right keyboard layout.)

From jwlato at gmail.com  Thu Aug 14 00:21:28 2014
From: jwlato at gmail.com (John Lato)
Date: Wed, 13 Aug 2014 17:21:28 -0700
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140813232155.GB25954@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
Message-ID: <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>

On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Wed, Aug 13, 2014 at 10:31:31PM +0200, Wojtek Narczy?ski wrote:
> > On 13.08.2014 12:37, Tom Ellis wrote:
> > >On Tue, Aug 12, 2014 at 12:46:05PM +0200, Wojtek Narczy?ski wrote:
> > >>Continuing my VAT Invoice example, let us say a LineItem that does
> > >>not have a product description (missing value), but it does have all
> > >>the numeric fields filled in.  It is partly erroneous, but it can be
> > >>included in calculation of the total. How would you handle it with
> > >>Either [Error] Invoice style code?
> > >What sort of functionality are you looking for exactly?  What's your
> > >objection to (for example)
> > >
> > >     data LineItemGeneral a = LineItem { price :: Price
> > >                                       , quantity :: Quantity
> > >                                       , description :: a }
> > >
> > >     type LineItem = LineItemGeneral String
> > >     type LineItemPossiblyIncomplete = LineItemGeneral (Maybe String)
> > >     type LineItemWithoutDescription = LineItemGeneral ()
> > >
> > >     totalValue :: LineItemGeneral a -> Value
> > >     totalValue lineItem = price lineItem * quantity lineItem
> > >
> > >`totalValue` works for all sorts of line items, whether they have a
> > >description or not.
> >
> > Let's say the user entered:
> >
> > No, Name, Qty, Price
> > --------------------------------------------
> > 1. [        ]   [99] [10]
> > 2. [Water] [    ] [10]
> > 3. [Juice]   [  1] [    ]
> >
> > The GUI should display total of 990, and signal four errors: three
> > missing values (ideally different color of the input fields), and
> > the whole invoice incomplete. The Either [Error] Invoice type does
> > not work, because can either display the errors or calculate total
> > from a correct invoice, never both. And you can't even create
> > LineItem for 2. and 3. Well, maybe you can with laziness, but how
> > would total work then?
> >
> > That's why I asked in my original post, whether I'd need two types,
> > one for correct complete invoice, and another for the invoice "in
> > statu nascendi". And how to obtain them, lazily, and I mean the
> > person, not the language.
>
> Perhaps I don't grasp exactly what you're getting at, but this seems easy.
> Please let me know where my proposed solution fails to provide what you
> need.
>
> I do see that you originally said "In Haskell you'd need two data types:
> the
> usual proper Haskell data type, and another which wraps every field in
> Maybe, facilitates editing, validation, etc.".  You don't actually *need*
> the version without the Maybe, but you can provide it if you want some
> additional type safety.  If you'd like to see an example of making that
> nice and easy with minimal boilerplate please ask.
>
>
>     import Control.Applicative
>     import Data.Maybe
>     import Control.Arrow
>
>     type Quantity = Double
>     type Price = Double
>     type Value = Double
>
>     data LineItem = LineItem { name :: Maybe String
>                              , quantity :: Maybe Quantity
>                              , price :: Maybe Price }
>


Rather than this definition, what about something like:

    data LineItemF f = LineItem
        { name :: f String
        , quantity :: f Quantity
        , price :: f Price }

    type LineItemBuilder = LineItemF (Writer Error)
    type LineItem = LineItemF Identity

    newLineItemBuilder :: LineItemBuilder
    newLineItemBuilder = LineItemF
        {"Missing" <$ tell (Error 1 NameField)
        ,0 <$ tell (Error 2 QuantityField)
        ,0 <$ tell (Error 3 PriceField)}

    setName :: LineItemBuilder -> String -> LineItemBuilder
    setName li newName = if validName newName
        then li { name = pure newName }
        else li -- either leave the original, or add the new name and tell
another error,
                  -- depending on use case

    -- quantity,price can be set similarly

    buildLineItem :: LineItemBuilder -> Either [Error] LineItem
    buildLineItem LineItemF{name, quantity,price} = case runWriter builder
of
         (built,[]) -> Right built
         (_, errs) -> Left errs
      where
        builder = LineItemF <$> (pure <$> name)
                                     <*> (pure <$> quantity)
                                     <*> (pure <$> price)

Now you have one type that represents a LineItem, and you can determine the
state of the LineItem by which functor is used.  You'll probably be able to
get some code re-use for any functions that don't need to know if a
particular LineItem is valid or not, but there's still a type-level
distinction between validated and unvalidated LineItems.  And if you're
using lens, you can access the component fields with "name . _Wrapped" (or
maybe _Unwrapped, depends on which version of lens you're using).

If you're taking arbitrary strings as user input, and they haven't been
parsed as numbers yet (or otherwise validated), you can even handle that
case by using an appropriate functor, such as "Constant String".  Then you
could have a function like

    validate :: (String -> Either ValidationError a) -> Constant String a
-> Either ValidationError a

that takes a parser and parses/validates the field.

John L.


>
>     data Field = NameField | QuantityField | PriceField
>                deriving Show
>
>     data Error = Error { item :: Int
>                        , missing :: Field }
>                deriving Show
>
>     value :: LineItem -> Maybe Value
>     value l = (*) <$> price l <*> quantity l
>
>     totalValue :: [LineItem] -> Value
>     totalValue = sum . map (fromMaybe 0 . value)
>
>     missingFields :: LineItem -> [Field]
>     missingFields l = n ++ q ++ p
>       where n = if name l == Nothing then [NameField] else []
>             q = if quantity l == Nothing then [QuantityField] else []
>             p = if price l == Nothing then [PriceField] else []
>
>     errors :: [LineItem] -> [Error]
>     errors = concatMap (\(i, es) -> map (Error i) es)
>              . zip [1..]
>              . map missingFields
>
>     guiResponse :: [LineItem] -> (Value, [Error])
>     guiResponse = totalValue &&& errors
>
>     exampleData :: [LineItem]
>     exampleData = [ LineItem Nothing        (Just 99) (Just 10)
>                   , LineItem (Just "Water") Nothing   (Just 10)
>                   , LineItem (Just "Juice") (Just 1)  Nothing ]
>
>     -- *Main> guiResponse exampleData
>     -- (990.0, [ Error {item = 1, missing = NameField}
>     --         , Error {item = 2, missing = QuantityField}
>     --         , Error {item = 3, missing = PriceField}])
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/ab6e441d/attachment.html>

From ok at cs.otago.ac.nz  Thu Aug 14 01:22:06 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Thu, 14 Aug 2014 13:22:06 +1200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBCB23.9030306@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
Message-ID: <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>


> Let's say the user entered:
>
> No, Name, Qty, Price
> --------------------------------------------
> 1. [        ]  [99] [10]
> 2. [Water   ]  [  ] [10]
> 3. [Juice   ]  [ 1] [  ]
>
> The GUI should display total of 990,

Why?  Let's be clear about this: given that
information, the total is unknown and unknowable,
and even if lines 1 and 2 were intended to be the
same line, the existence of line 3 means that 990
is almost surely LESS than the correct total,
whatever that might be.

Supermarkets here don't let you create invoice lines
by reference (giving a possibly garbled name) but
only by ostension ("I want to buy THIS").  This is
why all those bar codes and thingies exist.
Libraries here do something similar with books:
you show the machine "I want to borrow THIS book"
and a guaranteed valid line is created.

A GUI clearly *could* be designed to allow badly
messed up entries like that, but it is at least
questionable whether it *should*.

A possible data point:  students here are very much
used to the instant feedback provided by syntax colouring
editors, and few of them would willingly program without
such tools.  (I'm annoyed by and slowed by this nonsense, but
tastes vary.)  This is evidence that at least some people
strongly prefer instant feedback; by the time they get to
the end of a form they know that each and every field is
at least plausible taken by itself.



 and signal four errors: three
> missing values (ideally different color of the input fields), and the
> whole invoice incomplete. The Either [Error] Invoice type does not work,
> because can either display the errors or calculate total from a correct
> invoice, never both. And you can't even create LineItem for 2. and 3.
> Well, maybe you can with laziness, but how would total work then?
>
> That's why I asked in my original post, whether I'd need two types, one
> for correct complete invoice, and another for the invoice "in statu
> nascendi". And how to obtain them, lazily, and I mean the person, not
> the language.
>
> --
> Wojtek
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



From eir at cis.upenn.edu  Thu Aug 14 01:54:29 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Aug 2014 21:54:29 -0400
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
Message-ID: <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>

Your operating assumption sounds right. Do you have a complete, minimal example showing the error? If not, I recommend using -fprint-explicit-kinds to see if kinds are getting in your way at all.

Richard

On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianmllgn at gmail.com> wrote:

> When a closed type family has only one instance it seems like it should never fail to simplify. Yet this doesn't appear to be the case. When I defined (in GHC 7.8.3) the closed type family
> type family (:.:) f g a where (:.:) f g a = f (g a)
> I get errors such as
> 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))'
> (where Object is a Constraint family), indicating that f (g a) is not being substituted for (:.:) f g a as desired. Any idea why this happens?
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From ianmllgn at gmail.com  Thu Aug 14 02:42:54 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Wed, 13 Aug 2014 19:42:54 -0700 (PDT)
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
Message-ID: <d0553f2a-df21-4fe4-b4a9-cbcadf6cf476@googlegroups.com>

Here is a small example which shows the problem

{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE AllowAmbiguousTypes #-}

module TypeFamilyTest where

import GHC.Prim

type family A ? * ? Constraint

type family C f g a where C f g a = f (g a)

a ? A (f (g a)) ? ()
a = ()

b ? A (C f g a) ? ()
b = a


On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>
> Your operating assumption sounds right. Do you have a complete, minimal 
> example showing the error? If not, I recommend using -fprint-explicit-kinds 
> to see if kinds are getting in your way at all. 
>
> Richard 
>
> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com <javascript:>> 
> wrote: 
>
> > When a closed type family has only one instance it seems like it should 
> never fail to simplify. Yet this doesn't appear to be the case. When I 
> defined (in GHC 7.8.3) the closed type family 
> > type family (:.:) f g a where (:.:) f g a = f (g a) 
> > I get errors such as 
> > 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))' 
> > (where Object is a Constraint family), indicating that f (g a) is not 
> being substituted for (:.:) f g a as desired. Any idea why this happens? 
> > _______________________________________________ 
> > Haskell-Cafe mailing list 
> > Haskel... at haskell.org <javascript:> 
> > http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/576b1e5d/attachment.html>

From ianmllgn at gmail.com  Thu Aug 14 02:54:41 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Wed, 13 Aug 2014 19:54:41 -0700 (PDT)
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
Message-ID: <1895c8e1-d238-4cf6-bee8-53915a0d6db2@googlegroups.com>

Actually, that example is not quite right. Let me try to come up with 
another one.

On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>
> Your operating assumption sounds right. Do you have a complete, minimal 
> example showing the error? If not, I recommend using -fprint-explicit-kinds 
> to see if kinds are getting in your way at all. 
>
> Richard 
>
> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com <javascript:>> 
> wrote: 
>
> > When a closed type family has only one instance it seems like it should 
> never fail to simplify. Yet this doesn't appear to be the case. When I 
> defined (in GHC 7.8.3) the closed type family 
> > type family (:.:) f g a where (:.:) f g a = f (g a) 
> > I get errors such as 
> > 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))' 
> > (where Object is a Constraint family), indicating that f (g a) is not 
> being substituted for (:.:) f g a as desired. Any idea why this happens? 
> > _______________________________________________ 
> > Haskell-Cafe mailing list 
> > Haskel... at haskell.org <javascript:> 
> > http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/ea4f9820/attachment.html>

From ianmllgn at gmail.com  Thu Aug 14 03:39:08 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Wed, 13 Aug 2014 20:39:08 -0700 (PDT)
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
Message-ID: <aeb25380-28f0-460f-842f-ae3ed6d01dde@googlegroups.com>

I suspect the problem happens because I am trying to use a partially 
applied type family with a type constructor. However, in trying to 
replicate the problem I ran into another strange error message with the 
following program (using tagged and constraints as I was trying to keep it 
as close to the original program as possible)

{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeOperators #-}

module TypeFamilyTest where

import GHC.Prim
import Data.Constraint
import Data.Tagged
import Data.Proxy

type family A :: * -> Constraint
type family B f g a where B f g a = f (g a)
newtype C f = C (forall a. Tagged a (A a :- A (f a)))

t :: forall f g a. C f -> C g -> C (B f g)
t (C x) (C y) = C z where
    z :: forall a. Tagged a (A a :- A (f (g a)))
    z = Tagged (trans (proxy x (Proxy :: Proxy (g a))) (proxy y (Proxy :: 
Proxy a)))

This fails with the error message

TypeFamilyTest.hs:21:19:
    Couldn't match type ?a1? with ?g a1?
      ?a1? is a rigid type variable bound by
           a type expected by the context: Tagged a1 (A a1 :- A (f a1))
           at TypeFamilyTest.hs:21:17
    Expected type: Tagged a1 (A a1 :- A (f a1))
      Actual type: Tagged a1 (A a1 :- A (f (g a1)))
    Relevant bindings include
      z :: forall a. Tagged a (A a :- A (f (g a)))
        (bound at TypeFamilyTest.hs:23:5)
      y :: forall a. Tagged a (A a :- A (g a))
        (bound at TypeFamilyTest.hs:21:12)
      t :: C f -> C g -> C (B f g) (bound at TypeFamilyTest.hs:21:1)
    In the first argument of ?C?, namely ?z?
    In the expression: C z

for some reason C (B f g) expects Tagged a1 (A a1 :- A (f a1)) instead of 
Tagged a1 (A a1 :- A (f (g a1)))?

On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>
> Your operating assumption sounds right. Do you have a complete, minimal 
> example showing the error? If not, I recommend using -fprint-explicit-kinds 
> to see if kinds are getting in your way at all. 
>
> Richard 
>
> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com <javascript:>> 
> wrote: 
>
> > When a closed type family has only one instance it seems like it should 
> never fail to simplify. Yet this doesn't appear to be the case. When I 
> defined (in GHC 7.8.3) the closed type family 
> > type family (:.:) f g a where (:.:) f g a = f (g a) 
> > I get errors such as 
> > 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))' 
> > (where Object is a Constraint family), indicating that f (g a) is not 
> being substituted for (:.:) f g a as desired. Any idea why this happens? 
> > _______________________________________________ 
> > Haskell-Cafe mailing list 
> > Haskel... at haskell.org <javascript:> 
> > http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/6f52223f/attachment-0001.html>

From ianmllgn at gmail.com  Thu Aug 14 03:48:32 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Wed, 13 Aug 2014 20:48:32 -0700 (PDT)
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <aeb25380-28f0-460f-842f-ae3ed6d01dde@googlegroups.com>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
 <aeb25380-28f0-460f-842f-ae3ed6d01dde@googlegroups.com>
Message-ID: <771da3b9-861f-40db-8487-82e0bc1d5bff@googlegroups.com>

This is enough to demonstrate this error:

{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE RankNTypes #-}

module TypeFamilyTest where

type family B f g a where B f g a = f (g a)
newtype C f a = C (f a)
t :: (forall a. a -> f a) -> (forall a. a -> g a) -> a -> C (B f g) a
t f g a = C (f (g a))

Is it not possible to use type families in this way?

On Wednesday, August 13, 2014 8:39:09 PM UTC-7, Ian Milligan wrote:
>
> I suspect the problem happens because I am trying to use a partially 
> applied type family with a type constructor. However, in trying to 
> replicate the problem I ran into another strange error message with the 
> following program (using tagged and constraints as I was trying to keep it 
> as close to the original program as possible)
>
> {-# LANGUAGE TypeFamilies #-}
> {-# LANGUAGE ConstraintKinds #-}
> {-# LANGUAGE RankNTypes #-}
> {-# LANGUAGE ScopedTypeVariables #-}
> {-# LANGUAGE TypeOperators #-}
>
> module TypeFamilyTest where
>
> import GHC.Prim
> import Data.Constraint
> import Data.Tagged
> import Data.Proxy
>
> type family A :: * -> Constraint
> type family B f g a where B f g a = f (g a)
> newtype C f = C (forall a. Tagged a (A a :- A (f a)))
>
> t :: forall f g a. C f -> C g -> C (B f g)
> t (C x) (C y) = C z where
>     z :: forall a. Tagged a (A a :- A (f (g a)))
>     z = Tagged (trans (proxy x (Proxy :: Proxy (g a))) (proxy y (Proxy :: 
> Proxy a)))
>
> This fails with the error message
>
> TypeFamilyTest.hs:21:19:
>     Couldn't match type ?a1? with ?g a1?
>       ?a1? is a rigid type variable bound by
>            a type expected by the context: Tagged a1 (A a1 :- A (f a1))
>            at TypeFamilyTest.hs:21:17
>     Expected type: Tagged a1 (A a1 :- A (f a1))
>       Actual type: Tagged a1 (A a1 :- A (f (g a1)))
>     Relevant bindings include
>       z :: forall a. Tagged a (A a :- A (f (g a)))
>         (bound at TypeFamilyTest.hs:23:5)
>       y :: forall a. Tagged a (A a :- A (g a))
>         (bound at TypeFamilyTest.hs:21:12)
>       t :: C f -> C g -> C (B f g) (bound at TypeFamilyTest.hs:21:1)
>     In the first argument of ?C?, namely ?z?
>     In the expression: C z
>
> for some reason C (B f g) expects Tagged a1 (A a1 :- A (f a1)) instead of 
> Tagged a1 (A a1 :- A (f (g a1)))?
>
> On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>>
>> Your operating assumption sounds right. Do you have a complete, minimal 
>> example showing the error? If not, I recommend using -fprint-explicit-kinds 
>> to see if kinds are getting in your way at all. 
>>
>> Richard 
>>
>> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com> wrote: 
>>
>> > When a closed type family has only one instance it seems like it should 
>> never fail to simplify. Yet this doesn't appear to be the case. When I 
>> defined (in GHC 7.8.3) the closed type family 
>> > type family (:.:) f g a where (:.:) f g a = f (g a) 
>> > I get errors such as 
>> > 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))' 
>> > (where Object is a Constraint family), indicating that f (g a) is not 
>> being substituted for (:.:) f g a as desired. Any idea why this happens? 
>> > _______________________________________________ 
>> > Haskell-Cafe mailing list 
>> > Haskel... at haskell.org 
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe 
>>
>> _______________________________________________ 
>> Haskell-Cafe mailing list 
>> Haskel... at haskell.org 
>> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140813/fe7b90ef/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Aug 14 07:19:02 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 08:19:02 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
Message-ID: <20140814071901.GE25954@henry>

On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
> On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
> >     data LineItem = LineItem { name :: Maybe String
> >                              , quantity :: Maybe Quantity
> >                              , price :: Maybe Price }
> 
> Rather than this definition, what about something like:
> 
>     data LineItemF f = LineItem
>         { name :: f String
>         , quantity :: f Quantity
>         , price :: f Price }

It seems Wojtek already objected to this approach, though perhaps that
objection could be overcome

    http://www.haskell.org/pipermail/haskell-cafe/2014-August/115528.html

From jwlato at gmail.com  Thu Aug 14 08:35:36 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 14 Aug 2014 01:35:36 -0700
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140814071901.GE25954@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry>
Message-ID: <CAJ727GgAc4pgy-oW0+kDZadLCzvC4fcSRfxjr8gVTU1GNzbyiA@mail.gmail.com>

I would suggest  { someMaybeField :: f (Maybe Value) }, or perhaps newtype
MaybeValue = MV (Maybe Value).


On Thu, Aug 14, 2014 at 12:19 AM, Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:

> On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
> > On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
> > >     data LineItem = LineItem { name :: Maybe String
> > >                              , quantity :: Maybe Quantity
> > >                              , price :: Maybe Price }
> >
> > Rather than this definition, what about something like:
> >
> >     data LineItemF f = LineItem
> >         { name :: f String
> >         , quantity :: f Quantity
> >         , price :: f Price }
>
> It seems Wojtek already objected to this approach, though perhaps that
> objection could be overcome
>
>     http://www.haskell.org/pipermail/haskell-cafe/2014-August/115528.html
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/2e3e2850/attachment.html>

From chriswarbo at googlemail.com  Thu Aug 14 08:36:39 2014
From: chriswarbo at googlemail.com (Chris Warburton)
Date: Thu, 14 Aug 2014 09:36:39 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBD82E.9070905@power.com.pl> ("Wojtek =?utf-8?Q?Narczy?=
 =?utf-8?Q?=C5=84ski=22's?= message of
 "Wed, 13 Aug 2014 23:27:10 +0200")
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <dijnu99g1f5e56avigrvnic0ac299k2nbn@4ax.com>
 <53EBD82E.9070905@power.com.pl>
Message-ID: <86oavn5uy0.fsf@gmail.com>

Wojtek Narczy?ski <wojtek at power.com.pl> writes:

> On 13.08.2014 22:49, Steve Schafer wrote:
>> Why? Why are any of these erroneous line items included in the total? I
>> would argue that an incomplete or otherwise erroneous line item is not
>> part of the invoice.
> Say that the error is merely a warning, for example the user entered
> A' which is suspiciously short.

The goalposts have moved again, although this time it's trivial:

checkForWarnings :: Invoice -> [Warning]

What counts as a warning, how they affect the workflow and how they're
presented are business decisions.

Cheers,
Chris

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Aug 14 08:39:35 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 09:39:35 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAJ727GgAc4pgy-oW0+kDZadLCzvC4fcSRfxjr8gVTU1GNzbyiA@mail.gmail.com>
References: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry>
 <CAJ727GgAc4pgy-oW0+kDZadLCzvC4fcSRfxjr8gVTU1GNzbyiA@mail.gmail.com>
Message-ID: <20140814083935.GG25954@henry>

On Thu, Aug 14, 2014 at 01:35:36AM -0700, John Lato wrote:
> I would suggest  { someMaybeField :: f (Maybe Value) }, or perhaps newtype
> MaybeValue = MV (Maybe Value).

That seems like a perfectly good solution to me.  The only drawback is that
you cannot validate fields individually.

Tom

From wojtek at power.com.pl  Thu Aug 14 08:42:41 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 10:42:41 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
Message-ID: <53EC7681.1090305@power.com.pl>

On 14.08.2014 03:22, ok at cs.otago.ac.nz wrote:
>> Let's say the user entered:
>>
>> No, Name, Qty, Price
>> --------------------------------------------
>> 1. [        ]  [99] [10]
>> 2. [Water   ]  [  ] [10]
>> 3. [Juice   ]  [ 1] [  ]
>>
>> The GUI should display total of 990,
> Why?  Let's be clear about this: given that
> information, the total is unknown and unknowable,
> and even if lines 1 and 2 were intended to be the
> same line, the existence of line 3 means that 990
> is almost surely LESS than the correct total,
> whatever that might be.

Because this is what you would get in the most familiar software for 
accountants, and the most widespread functional language in the world: a 
spreadsheet. Or simply because this has been specified this way and the 
developer is supposed to implement it.

> Supermarkets here don't let you create invoice lines
> by reference (giving a possibly garbled name) but
> only by ostension ("I want to buy THIS").  This is
> why all those bar codes and thingies exist.
> Libraries here do something similar with books:
> you show the machine "I want to borrow THIS book"
> and a guaranteed valid line is created.

Imagine you are a freelance programmer and you are in the process of 
invoicing your customer.

> A possible data point:  students here are very much
> used to the instant feedback provided by syntax colouring
> editors, and few of them would willingly program without
> such tools.  (I'm annoyed by and slowed by this nonsense, but
> tastes vary.)
Heh, I also like syntax colouring editors, vim specifically. Recently I 
saw SublimeText, and I also liked it very much, I almost switched from 
vim. I keep promising to myself that I would learn Emacs. I don't like 
Eclipse, because it is too slow.

>    This is evidence that at least some people
> strongly prefer instant feedback; by the time they get to
> the end of a form they know that each and every field is
> at least plausible taken by itself.
>
>
So in the end you admit that my "design" (scratch, rather) might be what 
young people might like?

-- 
Kind regards,
Wojtek Narczynski

From wojtek at power.com.pl  Thu Aug 14 08:48:34 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 10:48:34 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140813232155.GB25954@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
Message-ID: <53EC77E2.9050400@power.com.pl>

On 14.08.2014 01:21, Tom Ellis wrote:
>
> Perhaps I don't grasp exactly what you're getting at, but this seems easy.
> Please let me know where my proposed solution fails to provide what you
> need.
>
> I do see that you originally said "In Haskell you'd need two data types: the
> usual proper Haskell data type, and another which wraps every field in
> Maybe, facilitates editing, validation, etc.".  You don't actually *need*
> the version without the Maybe, but you can provide it if you want some
> additional type safety.

Yes! This is what I mean.

But there is much more to validation, than just missing values. For text 
fields you have lengths, regexps. For numeric fields you have ranges, 
steps. Then come rules that are inter-fleld: if this field is "Yes", 
that field must be filled, if the user chooses "No" a field should be 
hidden, if the user changes his mind, the value entered should be 
preserved (not validation, but related). Then come rules that are 
inter-record: if this field is "ExportInvoice", all VAT fields in the 
LineItem must be zero.

The difficulty lies in abundance, ubiquity and complexity of the 
validation rules.

Empty fields are just an innocent example. The code you provided solves 
it well, but this is just a tip of an iceberg.

And we still haven't even touched the subject of assisting the user to 
fix the inconsistencies.

Therefore, quite frankly, I was hoping for radical new ideas how to 
tackle this, when I was starting this thread. DSLs, logic, Attribute 
Grammars, something like that.

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Aug 14 08:59:23 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 09:59:23 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EC77E2.9050400@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <53EC77E2.9050400@power.com.pl>
Message-ID: <20140814085922.GH25954@henry>

On Thu, Aug 14, 2014 at 10:48:34AM +0200, Wojtek Narczy?ski wrote:
> On 14.08.2014 01:21, Tom Ellis wrote:
> >Perhaps I don't grasp exactly what you're getting at, but this seems easy.
> >Please let me know where my proposed solution fails to provide what you
> >need.
> >
> >I do see that you originally said "In Haskell you'd need two data types: the
> >usual proper Haskell data type, and another which wraps every field in
> >Maybe, facilitates editing, validation, etc.".  You don't actually *need*
> >the version without the Maybe, but you can provide it if you want some
> >additional type safety.
> 
> Yes! This is what I mean.
> 
> But there is much more to validation, than just missing values.
[...]
> 
> The difficulty lies in abundance, ubiquity and complexity of the
> validation rules.
> 
> Empty fields are just an innocent example. The code you provided
> solves it well, but this is just a tip of an iceberg.
> 
> And we still haven't even touched the subject of assisting the user
> to fix the inconsistencies.
> 
> Therefore, quite frankly, I was hoping for radical new ideas how to
> tackle this, when I was starting this thread. DSLs, logic, Attribute
> Grammars, something like that.

Is there a language that gets this right?  If so we can try replicating its
functionality in Haskell.

Tom

From wojtek at power.com.pl  Thu Aug 14 09:06:05 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 11:06:05 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140814085922.GH25954@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <53EC77E2.9050400@power.com.pl> <20140814085922.GH25954@henry>
Message-ID: <53EC7BFD.8050802@power.com.pl>


On 14.08.2014 10:59, Tom Ellis wrote:
>
> Is there a language that gets this right?  If so we can try replicating its
> functionality in Haskell.
>
>
No language I know of.

From hesselink at gmail.com  Thu Aug 14 09:17:07 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 14 Aug 2014 11:17:07 +0200
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <771da3b9-861f-40db-8487-82e0bc1d5bff@googlegroups.com>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
 <aeb25380-28f0-460f-842f-ae3ed6d01dde@googlegroups.com>
 <771da3b9-861f-40db-8487-82e0bc1d5bff@googlegroups.com>
Message-ID: <CAPeieQEdAHnaGSCormZ_3YqRsE29ueU-w3zOrdOZVsyZ+_-BzA@mail.gmail.com>

I think partially applied type synonyms (and type families) are
supposed to be disallowed, but I recently found out that since GHC
7.8, this is not the case anymore, but you get very weird other type
errors instead. I filed a bug [0], perhaps yours is a similar issue.

Erik

[0] https://ghc.haskell.org/trac/ghc/ticket/9433#ticket

On Thu, Aug 14, 2014 at 5:48 AM, Ian Milligan <ianmllgn at gmail.com> wrote:
> This is enough to demonstrate this error:
>
> {-# LANGUAGE TypeFamilies #-}
> {-# LANGUAGE RankNTypes #-}
>
> module TypeFamilyTest where
>
>
> type family B f g a where B f g a = f (g a)
> newtype C f a = C (f a)
> t :: (forall a. a -> f a) -> (forall a. a -> g a) -> a -> C (B f g) a
> t f g a = C (f (g a))
>
> Is it not possible to use type families in this way?
>
>
> On Wednesday, August 13, 2014 8:39:09 PM UTC-7, Ian Milligan wrote:
>>
>> I suspect the problem happens because I am trying to use a partially
>> applied type family with a type constructor. However, in trying to replicate
>> the problem I ran into another strange error message with the following
>> program (using tagged and constraints as I was trying to keep it as close to
>> the original program as possible)
>>
>> {-# LANGUAGE TypeFamilies #-}
>> {-# LANGUAGE ConstraintKinds #-}
>> {-# LANGUAGE RankNTypes #-}
>> {-# LANGUAGE ScopedTypeVariables #-}
>> {-# LANGUAGE TypeOperators #-}
>>
>> module TypeFamilyTest where
>>
>> import GHC.Prim
>> import Data.Constraint
>> import Data.Tagged
>> import Data.Proxy
>>
>> type family A :: * -> Constraint
>> type family B f g a where B f g a = f (g a)
>> newtype C f = C (forall a. Tagged a (A a :- A (f a)))
>>
>> t :: forall f g a. C f -> C g -> C (B f g)
>> t (C x) (C y) = C z where
>>     z :: forall a. Tagged a (A a :- A (f (g a)))
>>     z = Tagged (trans (proxy x (Proxy :: Proxy (g a))) (proxy y (Proxy ::
>> Proxy a)))
>>
>> This fails with the error message
>>
>> TypeFamilyTest.hs:21:19:
>>     Couldn't match type ?a1? with ?g a1?
>>       ?a1? is a rigid type variable bound by
>>            a type expected by the context: Tagged a1 (A a1 :- A (f a1))
>>            at TypeFamilyTest.hs:21:17
>>     Expected type: Tagged a1 (A a1 :- A (f a1))
>>       Actual type: Tagged a1 (A a1 :- A (f (g a1)))
>>     Relevant bindings include
>>       z :: forall a. Tagged a (A a :- A (f (g a)))
>>         (bound at TypeFamilyTest.hs:23:5)
>>       y :: forall a. Tagged a (A a :- A (g a))
>>         (bound at TypeFamilyTest.hs:21:12)
>>       t :: C f -> C g -> C (B f g) (bound at TypeFamilyTest.hs:21:1)
>>     In the first argument of ?C?, namely ?z?
>>     In the expression: C z
>>
>> for some reason C (B f g) expects Tagged a1 (A a1 :- A (f a1)) instead of
>> Tagged a1 (A a1 :- A (f (g a1)))?
>>
>> On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>>>
>>> Your operating assumption sounds right. Do you have a complete, minimal
>>> example showing the error? If not, I recommend using -fprint-explicit-kinds
>>> to see if kinds are getting in your way at all.
>>>
>>> Richard
>>>
>>> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com> wrote:
>>>
>>> > When a closed type family has only one instance it seems like it should
>>> > never fail to simplify. Yet this doesn't appear to be the case. When I
>>> > defined (in GHC 7.8.3) the closed type family
>>> > type family (:.:) f g a where (:.:) f g a = f (g a)
>>> > I get errors such as
>>> > 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))'
>>> > (where Object is a Constraint family), indicating that f (g a) is not
>>> > being substituted for (:.:) f g a as desired. Any idea why this happens?
>>> > _______________________________________________
>>> > Haskell-Cafe mailing list
>>> > Haskel... at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskel... at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From wojtek at power.com.pl  Thu Aug 14 09:28:53 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 11:28:53 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140814071901.GE25954@henry>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry>
Message-ID: <53EC8155.2050808@power.com.pl>


On 14.08.2014 09:19, Tom Ellis wrote:
> On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
>> On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
>>>      data LineItem = LineItem { name :: Maybe String
>>>                               , quantity :: Maybe Quantity
>>>                               , price :: Maybe Price }
>> Rather than this definition, what about something like:
>>
>>      data LineItemF f = LineItem
>>          { name :: f String
>>          , quantity :: f Quantity
>>          , price :: f Price }
> It seems Wojtek already objected to this approach, though perhaps that
> objection could be overcome
>
>
Hmm, perhaps like this

LineItemFi = LineItemFi
    { name :: StringFi
    , quantity :: QuantityFi
    , price :: PriceFi }


data LineItemUi f = LineItemUi
     { name :: StringUi
     , quantity :: QuantityUi
     , price :: PriceUi }

I mean 1:1 correspondence between leaf UI types that can be missing, 
validate lengths, etc. and final types that go to the backend. Maybe it 
would be possible to use type classes / families to have common 
arithmietics for calculating with both kinds of types. This does require 
TH or Generics, but it's fine.


-- 
Wojtek

From chriswarbo at googlemail.com  Thu Aug 14 09:37:35 2014
From: chriswarbo at googlemail.com (Chris Warburton)
Date: Thu, 14 Aug 2014 10:37:35 +0100
Subject: [Haskell-cafe] Does the lambda calculus have provisions for
	I/O? State can be done with free variables.
In-Reply-To: <CAMLKXynJhDV-WA-5Yb1=vVHoy5mwL+TZODXMKN182Ch5+3VuQg@mail.gmail.com>
 (KC's message of "Wed, 13 Aug 2014 14:39:01 -0700")
References: <CAMLKXynJhDV-WA-5Yb1=vVHoy5mwL+TZODXMKN182Ch5+3VuQg@mail.gmail.com>
Message-ID: <86k36b5s4g.fsf@gmail.com>

KC <kc1956 at gmail.com> writes:

> Hi:
>
> Does the lambda calculus have provisions for I/O?
> State can be done with free variables.

Lambda Calculus can't do IO "internally"; we can't mutate variables,
whether or not they're free.

However, we can use LC to construct programs in some "external"
language, which *does* support IO. We can interface the two by using
free variables to represent the "external" functions.

This is the same way Haskell implements IO: pure Haskell functions are
used to construct a "main" value out of "external" (/"primitive"/
"built-in"/ "foreign") functions. We can regard "main" as a program for
an imperative language (the Haskell run-time system).

We can do the same thing in Lambda Calculus (which is like Haskell
without the type-checking and syntactic sugar).

Cheers,
Chris

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Aug 14 09:41:01 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 14 Aug 2014 10:41:01 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EC8155.2050808@power.com.pl>
References: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry> <53EC8155.2050808@power.com.pl>
Message-ID: <20140814094101.GI25954@henry>

On Thu, Aug 14, 2014 at 11:28:53AM +0200, Wojtek Narczy?ski wrote:
> On 14.08.2014 09:19, Tom Ellis wrote:
> >On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
> >>On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
> >>>     data LineItem = LineItem { name :: Maybe String
> >>>                              , quantity :: Maybe Quantity
> >>>                              , price :: Maybe Price }
> >>Rather than this definition, what about something like:
> >>
> >>     data LineItemF f = LineItem
> >>         { name :: f String
> >>         , quantity :: f Quantity
> >>         , price :: f Price }
> >It seems Wojtek already objected to this approach, though perhaps that
> >objection could be overcome
>
> Hmm, perhaps like this
> 
> LineItemFi = LineItemFi
>    { name :: StringFi
>    , quantity :: QuantityFi
>    , price :: PriceFi }
> 
> 
> data LineItemUi f = LineItemUi
>     { name :: StringUi
>     , quantity :: QuantityUi
>     , price :: PriceUi }

You didn't use f there.

From eir at cis.upenn.edu  Thu Aug 14 11:42:42 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 14 Aug 2014 07:42:42 -0400
Subject: [Haskell-cafe] Closed Type Family Simplification
In-Reply-To: <CAPeieQEdAHnaGSCormZ_3YqRsE29ueU-w3zOrdOZVsyZ+_-BzA@mail.gmail.com>
References: <CAMAD-2z4HK9kR7UzsR4UjyORY=KKRo7LeB7Ofa_uxb-yTuMbWA@mail.gmail.com>
 <AC2BB3BC-A64D-40F4-A694-F7561D43CBB0@cis.upenn.edu>
 <aeb25380-28f0-460f-842f-ae3ed6d01dde@googlegroups.com>
 <771da3b9-861f-40db-8487-82e0bc1d5bff@googlegroups.com>
 <CAPeieQEdAHnaGSCormZ_3YqRsE29ueU-w3zOrdOZVsyZ+_-BzA@mail.gmail.com>
Message-ID: <07477DA3-815D-4616-A9AE-A596140465EF@cis.upenn.edu>

Erik's analysis agrees with mine: type families can never be partially applied, and the fact that Ian's latest example is accepted  as a syntactically correct program is a straightforward bug in GHC. If you try that code on GHC 7.8.2, it will fail.

Type families can *never* be partially applied. (Data families are another story, though...)

Richard

On Aug 14, 2014, at 5:17 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> I think partially applied type synonyms (and type families) are
> supposed to be disallowed, but I recently found out that since GHC
> 7.8, this is not the case anymore, but you get very weird other type
> errors instead. I filed a bug [0], perhaps yours is a similar issue.
> 
> Erik
> 
> [0] https://ghc.haskell.org/trac/ghc/ticket/9433#ticket
> 
> On Thu, Aug 14, 2014 at 5:48 AM, Ian Milligan <ianmllgn at gmail.com> wrote:
>> This is enough to demonstrate this error:
>> 
>> {-# LANGUAGE TypeFamilies #-}
>> {-# LANGUAGE RankNTypes #-}
>> 
>> module TypeFamilyTest where
>> 
>> 
>> type family B f g a where B f g a = f (g a)
>> newtype C f a = C (f a)
>> t :: (forall a. a -> f a) -> (forall a. a -> g a) -> a -> C (B f g) a
>> t f g a = C (f (g a))
>> 
>> Is it not possible to use type families in this way?
>> 
>> 
>> On Wednesday, August 13, 2014 8:39:09 PM UTC-7, Ian Milligan wrote:
>>> 
>>> I suspect the problem happens because I am trying to use a partially
>>> applied type family with a type constructor. However, in trying to replicate
>>> the problem I ran into another strange error message with the following
>>> program (using tagged and constraints as I was trying to keep it as close to
>>> the original program as possible)
>>> 
>>> {-# LANGUAGE TypeFamilies #-}
>>> {-# LANGUAGE ConstraintKinds #-}
>>> {-# LANGUAGE RankNTypes #-}
>>> {-# LANGUAGE ScopedTypeVariables #-}
>>> {-# LANGUAGE TypeOperators #-}
>>> 
>>> module TypeFamilyTest where
>>> 
>>> import GHC.Prim
>>> import Data.Constraint
>>> import Data.Tagged
>>> import Data.Proxy
>>> 
>>> type family A :: * -> Constraint
>>> type family B f g a where B f g a = f (g a)
>>> newtype C f = C (forall a. Tagged a (A a :- A (f a)))
>>> 
>>> t :: forall f g a. C f -> C g -> C (B f g)
>>> t (C x) (C y) = C z where
>>>    z :: forall a. Tagged a (A a :- A (f (g a)))
>>>    z = Tagged (trans (proxy x (Proxy :: Proxy (g a))) (proxy y (Proxy ::
>>> Proxy a)))
>>> 
>>> This fails with the error message
>>> 
>>> TypeFamilyTest.hs:21:19:
>>>    Couldn't match type ?a1? with ?g a1?
>>>      ?a1? is a rigid type variable bound by
>>>           a type expected by the context: Tagged a1 (A a1 :- A (f a1))
>>>           at TypeFamilyTest.hs:21:17
>>>    Expected type: Tagged a1 (A a1 :- A (f a1))
>>>      Actual type: Tagged a1 (A a1 :- A (f (g a1)))
>>>    Relevant bindings include
>>>      z :: forall a. Tagged a (A a :- A (f (g a)))
>>>        (bound at TypeFamilyTest.hs:23:5)
>>>      y :: forall a. Tagged a (A a :- A (g a))
>>>        (bound at TypeFamilyTest.hs:21:12)
>>>      t :: C f -> C g -> C (B f g) (bound at TypeFamilyTest.hs:21:1)
>>>    In the first argument of ?C?, namely ?z?
>>>    In the expression: C z
>>> 
>>> for some reason C (B f g) expects Tagged a1 (A a1 :- A (f a1)) instead of
>>> Tagged a1 (A a1 :- A (f (g a1)))?
>>> 
>>> On Wednesday, August 13, 2014 6:54:45 PM UTC-7, Richard Eisenberg wrote:
>>>> 
>>>> Your operating assumption sounds right. Do you have a complete, minimal
>>>> example showing the error? If not, I recommend using -fprint-explicit-kinds
>>>> to see if kinds are getting in your way at all.
>>>> 
>>>> Richard
>>>> 
>>>> On Aug 13, 2014, at 8:02 PM, Ian Milligan <ianm... at gmail.com> wrote:
>>>> 
>>>>> When a closed type family has only one instance it seems like it should
>>>>> never fail to simplify. Yet this doesn't appear to be the case. When I
>>>>> defined (in GHC 7.8.3) the closed type family
>>>>> type family (:.:) f g a where (:.:) f g a = f (g a)
>>>>> I get errors such as
>>>>> 'Could not deduce (Object c3 ((:.:) f g a) ~ Object c3 (f (g a)))'
>>>>> (where Object is a Constraint family), indicating that f (g a) is not
>>>>> being substituted for (:.:) f g a as desired. Any idea why this happens?
>>>>> _______________________________________________
>>>>> Haskell-Cafe mailing list
>>>>> Haskel... at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>> 
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskel... at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 


From agocorona at gmail.com  Thu Aug 14 12:06:17 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Thu, 14 Aug 2014 14:06:17 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <20140814094101.GI25954@henry>
References: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry> <53EC8155.2050808@power.com.pl>
 <20140814094101.GI25954@henry>
Message-ID: <CAArEJmY9RDsNZQenxTOz52v8aXGSmUPknjtKyTPBexO9fzDJOg@mail.gmail.com>

Formlets ever had cascade validation:

data Item= Item{ name ::String, quantity, price :: Int}

Item <$>
       <*> inputString `validate` nonEmpty
       <*> inputInt
       <*> inputInt
 `validate` ( \item -> do
      if theUniverseIsSpanding then do
           if name item == "carrots" && price=="10" then
                       fail "we don?t like 10 cent carrots  in an expanding
universe"
           else if.....


2014-08-14 11:41 GMT+02:00 Tom Ellis <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>:

> On Thu, Aug 14, 2014 at 11:28:53AM +0200, Wojtek Narczy?ski wrote:
> > On 14.08.2014 09:19, Tom Ellis wrote:
> > >On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
> > >>On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
> > >>>     data LineItem = LineItem { name :: Maybe String
> > >>>                              , quantity :: Maybe Quantity
> > >>>                              , price :: Maybe Price }
> > >>Rather than this definition, what about something like:
> > >>
> > >>     data LineItemF f = LineItem
> > >>         { name :: f String
> > >>         , quantity :: f Quantity
> > >>         , price :: f Price }
> > >It seems Wojtek already objected to this approach, though perhaps that
> > >objection could be overcome
> >
> > Hmm, perhaps like this
> >
> > LineItemFi = LineItemFi
> >    { name :: StringFi
> >    , quantity :: QuantityFi
> >    , price :: PriceFi }
> >
> >
> > data LineItemUi f = LineItemUi
> >     { name :: StringUi
> >     , quantity :: QuantityUi
> >     , price :: PriceUi }
>
> You didn't use f there.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/870d6e3d/attachment.html>

From wojtek at power.com.pl  Thu Aug 14 12:19:41 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 14:19:41 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmY9RDsNZQenxTOz52v8aXGSmUPknjtKyTPBexO9fzDJOg@mail.gmail.com>
References: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry> <53EC8155.2050808@power.com.pl>
 <20140814094101.GI25954@henry>
 <CAArEJmY9RDsNZQenxTOz52v8aXGSmUPknjtKyTPBexO9fzDJOg@mail.gmail.com>
Message-ID: <53ECA95D.1060805@power.com.pl>


On 14.08.2014 14:06, Alberto G. Corona wrote:
> Formlets ever had cascade validation:
>
>


If you put validation into the UI, you are unable to reuse it.


-- 
Wojtek

From ivan.perez at keera.co.uk  Thu Aug 14 12:45:04 2014
From: ivan.perez at keera.co.uk (Ivan Perez)
Date: Thu, 14 Aug 2014 14:45:04 +0200
Subject: [Haskell-cafe] Haskell SDL2 FRP games working on Android
Message-ID: <53ECAF50.5070308@keera.co.uk>

Hi Caf?

Answering recent questions posted on this list regarding FRP, I would 
like to announce that we have a working Android game written in Haskell, 
using SDL2 and Yampa.

A short article describing the implications that this could have, 
together the libraries and backend we used, is here:
http://keera.co.uk/blog/2014/08/13/most-inspiring-green-screen-you-will-ever-see/

Changes made to existing libraries will be published as we move towards 
releasing the game on Google Play, and so will examples of Android 
programs written in Haskell.

All the best

Ivan

-- 
Facebook: https://www.facebook.com/keerastudios
Twitter: https://twitter.com/KeeraStudios
Web: http://www.keera.co.uk


From ok at cs.otago.ac.nz  Thu Aug 14 14:44:09 2014
From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz)
Date: Fri, 15 Aug 2014 02:44:09 +1200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EC7681.1090305@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
 <53EC7681.1090305@power.com.pl>
Message-ID: <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>

> On 14.08.2014 03:22, ok at cs.otago.ac.nz wrote:
>>> Let's say the user entered:
>>>
>>> No, Name, Qty, Price
>>> --------------------------------------------
>>> 1. [        ]  [99] [10]
>>> 2. [Water   ]  [  ] [10]
>>> 3. [Juice   ]  [ 1] [  ]
>>>
>>> The GUI should display total of 990,
>> Why?  Let's be clear about this: given that
>> information, the total is unknown and unknowable,
>> and even if lines 1 and 2 were intended to be the
>> same line, the existence of line 3 means that 990
>> is almost surely LESS than the correct total,
>> whatever that might be.
>
> Because this is what you would get in the most familiar software for
> accountants, and the most widespread functional language in the world: a
> spreadsheet. Or simply because this has been specified this way and the
> developer is supposed to implement it.

You have taught me something, and I am grateful for the
lesson, and APPALLED at the contents of the lesson.
I don't use spreadsheets, so I was unaware of this gross
and horrifying bug in them.  There is no excuse for a
spreadsheet quietly taking a never-assigned cell as zero,
but indeed it does.  WHAT THE HELL WERE THESE PEOPLE SMOKING?

It may be familiar, it may be popular, but the answer
is beyond any reasonable question simply WRONG.

As for "the developer is supposed to implement it",
next week I'll be giving my annual ethics lecture and
I'll be pointing out to students that the codes of practice
of the various professional societies all agree that your
duty goes beyond simply doing what you are told.
If you are told to write consumer software that gets its
sums wrong, you should not do it.

However, in this context, all that matters is that you
actually have TWO senses of "valid".
Data may be valid-for-sums, where missing data are defined
(wrongly, but that's your spec.) to be zero,
without actually being honest-to-goodness-valid.

The question remains whether this valid-for-sums processing
is a property of *invoices* or a property of *forms*, and I
claim that it's a property of invoice *forms* but not a
property of invoices.

That's one way to distinguish between valid-for-spreadsheet-sums
and honest-to-goodness-valid.  There are others.

Panko's paper, "What we know about spreadsheet errors"
http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm
has some scary numbers.  It contains these sentences:

    In 2003, the author spoke independently with
    experienced spreadsheet auditors in two different
    companies in the United Kingdom, where certain
    spreadsheets must be audited by law.
    Each audited about three dozen spreadsheets per year.
    Both said that they had NEVER seen a major spreadsheet
    that was free of errors
    Both also indicated that about five percent of the
    spreadsheets they audited have very serious errors
    that would have had major ramifications had they
    not been caught.

(The emphasis on NEVER is mine.)  I guess now we know one
more reason why spreadsheet errors are ubiquitous: the
interface is broken by design.

> Imagine you are a freelance programmer and you are in the process of
> invoicing your customer.

I have no idea what is customary, but I for d--n sure would not
use a spreadsheet to do it!  (This being a Haskell mailing list,
I would investigate the abilities of hLedger.)

>>    This is evidence that at least some people
>> strongly prefer instant feedback; by the time they get to
>> the end of a form they know that each and every field is
>> at least plausible taken by itself.
>>
>>
> So in the end you admit that my "design" (scratch, rather) might be what
> young people might like?

On the contrary.  You are specifying a design that lets invalid data
enter into computations.  I'm saying they would like a design that
stops invalid data as early as possible.  This is close in spirit
to the Foo/FooBuilder distinction, where a Foo is never allowed to
be in an invalid state.



From wojtek at power.com.pl  Thu Aug 14 15:11:02 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 17:11:02 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
 <53EC7681.1090305@power.com.pl>
 <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
Message-ID: <53ECD186.9070304@power.com.pl>

On 14.08.2014 16:44, ok at cs.otago.ac.nz wrote:
> It may be familiar, it may be popular, but the answer
> is beyond any reasonable question simply WRONG.

The exactly advantage of a purpose built app over a spreadsheet is that 
it would not let you save the invoice in this state. Indeed, perhaps it 
is a good idea to tell the users that this sum is not their final value. 
For example display a marijuana leaf next to it. Although, I would 
rather use color for that.

> (The emphasis on NEVER is mine.)  I guess now we know one
> more reason why spreadsheet errors are ubiquitous: the
> interface is broken by design.

I like spreadsheets, but they are not an answer to every need.

>
> I have no idea what is customary, but I for d--n sure would not
> use a spreadsheet to do it!  (This being a Haskell mailing list,
> I would investigate the abilities of hLedger.)

Sorry, hledger is a double entry accounting system, it does not issue 
invoices.

>> So in the end you admit that my "design" (scratch, rather) might be what
>> young people might like?
> On the contrary. You are specifying a design that lets invalid data
> enter into computations. I'm saying they would like a design that
> stops invalid data as early as possible.  This is close in spirit
> to the Foo/FooBuilder distinction, where a Foo is never allowed to
> be in an invalid state.
>
>
Pardon me, but are you "young people"?

From raphaelsimeon at gmail.com  Thu Aug 14 17:22:34 2014
From: raphaelsimeon at gmail.com (=?UTF-8?Q?Rapha=C3=ABl_Mongeau?=)
Date: Thu, 14 Aug 2014 13:22:34 -0400
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53ECD186.9070304@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
 <53EC7681.1090305@power.com.pl>
 <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
 <53ECD186.9070304@power.com.pl>
Message-ID: <CAMTQk-EXbqOehuxp6V94Zf9EXRdHTkWbFFVSF7kz06za3rDeig@mail.gmail.com>

Would't this be a good solution to the partial null fields probleme?

--The field name and the value
type Field = (String,String)

--The form informations we get from the client
type FormResult = [Filed]

--An error message to send to teh client
type FormError = String

data Person = Person {
    firstName :: String
   ,lastName :: String
   ,birthDate :: Date
   ,height :: Int
   }

type PersonParseResult = Either FormError Person

--When receiving data froom the client you call this function and return
the error to the client or continue normaly
getPersonneFromForm :: FormResult -> PersonParseResult

--You could go furter and do this:
class FromForm a where
    fromForm :: FormResult -> Either FormError a

instance FromForm Person where
    fromForm a = getPersonneFromForm a

--And then you could do this:
thisFunctionGetAForm :: FormResult -> HTTPResponse
thisFunctionGetAForm f =
    case (fromForm f) :: PersonParseResult of
        Left  a -> toHTTPResponse "The form is invalid"
        Right a -> toHTTPResponse "Ok, we got you"



2014-08-14 11:11 GMT-04:00 Wojtek Narczy?ski <wojtek at power.com.pl>:

> On 14.08.2014 16:44, ok at cs.otago.ac.nz wrote:
>
>> It may be familiar, it may be popular, but the answer
>> is beyond any reasonable question simply WRONG.
>>
>
> The exactly advantage of a purpose built app over a spreadsheet is that it
> would not let you save the invoice in this state. Indeed, perhaps it is a
> good idea to tell the users that this sum is not their final value. For
> example display a marijuana leaf next to it. Although, I would rather use
> color for that.
>
>
>  (The emphasis on NEVER is mine.)  I guess now we know one
>> more reason why spreadsheet errors are ubiquitous: the
>> interface is broken by design.
>>
>
> I like spreadsheets, but they are not an answer to every need.
>
>
>
>> I have no idea what is customary, but I for d--n sure would not
>> use a spreadsheet to do it!  (This being a Haskell mailing list,
>> I would investigate the abilities of hLedger.)
>>
>
> Sorry, hledger is a double entry accounting system, it does not issue
> invoices.
>
>
>  So in the end you admit that my "design" (scratch, rather) might be what
>>> young people might like?
>>>
>> On the contrary. You are specifying a design that lets invalid data
>> enter into computations. I'm saying they would like a design that
>> stops invalid data as early as possible.  This is close in spirit
>> to the Foo/FooBuilder distinction, where a Foo is never allowed to
>> be in an invalid state.
>>
>>
>>  Pardon me, but are you "young people"?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Viva Cila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/874f6b57/attachment.html>

From rustompmody at gmail.com  Thu Aug 14 17:29:59 2014
From: rustompmody at gmail.com (Rustom Mody)
Date: Thu, 14 Aug 2014 22:59:59 +0530
Subject: [Haskell-cafe] haskell (and beyond) in education
Message-ID: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>

I am collecting some data on FP used to introduce programming
ie as a first course:
http://blog.languager.org/2014/08/universities-starting-functional.html

Naturally the haskell link is the first:
http://www.haskell.org/haskellwiki/Haskell_in_education

I was just wondering if there are more extremal cases of this:
eg Are there any univs using Idris/Agda to *introduce*
programming/math/proofs etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/256f398b/attachment.html>

From tikhon at jelv.is  Thu Aug 14 17:43:44 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Thu, 14 Aug 2014 10:43:44 -0700
Subject: [Haskell-cafe] haskell (and beyond) in education
In-Reply-To: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
References: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
Message-ID: <CAJN5CVJnwFe25Q01MbHqujx0KfbWZKeViz5y7A4ODRURzAu9=Q@mail.gmail.com>

I asked a question on Quora about which universities use functional
programming in an intro CS course, and got a small list of replies. At the
very least, this could give you a place to start.

https://www.quora.com/Which-universities-teach-their-first-CS-course-in-a-functional-programming-language?share=1


On Thu, Aug 14, 2014 at 10:29 AM, Rustom Mody <rustompmody at gmail.com> wrote:

> I am collecting some data on FP used to introduce programming
> ie as a first course:
> http://blog.languager.org/2014/08/universities-starting-functional.html
>
> Naturally the haskell link is the first:
> http://www.haskell.org/haskellwiki/Haskell_in_education
>
> I was just wondering if there are more extremal cases of this:
> eg Are there any univs using Idris/Agda to *introduce*
> programming/math/proofs etc
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/42f78ceb/attachment.html>

From egarrulo at gmail.com  Thu Aug 14 18:00:32 2014
From: egarrulo at gmail.com (egarrulo)
Date: Thu, 14 Aug 2014 20:00:32 +0200
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
Message-ID: <53ECF940.8030501@gmail.com>

Hello guys,

I cannot install the Haskell Platform 2014.2.0.0 on my GNU/Linux system:

     $ ./platform.sh \
     >      --prefix=/opt/haskell-platform/haskell-platform-2014.2.0.0 \
     >      ../ghc-7.8.3/ghc-7.8.3-i386-unknown-linux.tar.bz2
     Warning: The following packages are likely to be broken by the
     reinstalls:
     haskell-platform-2013.2.0.0
     Use --force-reinstalls if you want to install anyway.
     === pre-requisite packages for hptool are not installed
         run the following:
         cd hptool ; cabal install --only-dependencies

However, the dependencies for *hptool* are already installed:

     $ cd hptool ; cabal install --only-dependencies
     Resolving dependencies...
     All the requested packages are already installed:
     Use --reinstall if you want to reinstall anyway.

The existing Haskell system:
  - GHC 7.6.3
  - Haskell Platform 2013.2.0.0
  - cabal-install 1.16.0.2 (using Cabal library  1.16.0)

Any help?  Thank you.

From allbery.b at gmail.com  Thu Aug 14 18:10:17 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 14 Aug 2014 14:10:17 -0400
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <53ECF940.8030501@gmail.com>
References: <53ECF940.8030501@gmail.com>
Message-ID: <CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>

On Thu, Aug 14, 2014 at 2:00 PM, egarrulo <egarrulo at gmail.com> wrote:

> I cannot install the Haskell Platform 2014.2.0.0 on my GNU/Linux system:
>
>     $ ./platform.sh \
>     >      --prefix=/opt/haskell-platform/haskell-platform-2014.2.0.0 \
>     >      ../ghc-7.8.3/ghc-7.8.3-i386-unknown-linux.tar.bz2
>     Warning: The following packages are likely to be broken by the
>     reinstalls:
>     haskell-platform-2013.2.0.0
>     Use --force-reinstalls if you want to install anyway.
>     === pre-requisite packages for hptool are not installed
>

You can't have two versions of the Platform installed into the same ghc;
ghc will become extremely confused. This is essentially a ghc shortcoming
that the Platform can't work around.

The hptool issue is likely that you have an older version installed than
the new Platform requires, and the newer one is not compatible with the
older Platform. Again, installing a separate ghc for the new Platform
should resolve this.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/5d9a9e38/attachment.html>

From wojtek at power.com.pl  Thu Aug 14 18:25:23 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Thu, 14 Aug 2014 20:25:23 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAMTQk-EXbqOehuxp6V94Zf9EXRdHTkWbFFVSF7kz06za3rDeig@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>	<fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>	<53E9C868.9090406@power.com.pl>	<864mxi6on0.fsf@gmail.com>	<53E9F06D.5090804@power.com.pl>	<20140813103758.GP1527@henry>	<53EBCB23.9030306@power.com.pl>	<517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>	<53EC7681.1090305@power.com.pl>	<1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>	<53ECD186.9070304@power.com.pl>
 <CAMTQk-EXbqOehuxp6V94Zf9EXRdHTkWbFFVSF7kz06za3rDeig@mail.gmail.com>
Message-ID: <53ECFF13.3010807@power.com.pl>

W dniu 2014-08-14 19:22, Rapha?l Mongeau pisze:
> Would't this be a good solution to the partial null fields probleme?

It is a solution to the null problem alone. But it is not a holistic way 
to create good GUIs. For example id doesn't touch the following 
problems: checking input for legal characters, text field lengths, 
numeric ranges, inter-field dependencies, inter-record dependencies, 
undo, saving partially filled forms to finish filling them in later, and 
probably many more.

Also, I'm after something in the spirit of Alberto's hplayground. For 
the web UI to be appealing nowadays, it has to work on the client.

http://mflowdemo.herokuapp.com/noscript/wiki/browserwidgets
https://github.com/agocorona/hplayground

-- 
Wojtek


From benjamin.foppa at gmail.com  Thu Aug 14 18:33:14 2014
From: benjamin.foppa at gmail.com (Ben Foppa)
Date: Thu, 14 Aug 2014 14:33:14 -0400
Subject: [Haskell-cafe] maintainer needed: extensible-effects
Message-ID: <CADu1bNTtKskNF_LPgn5vrFk9ORRBfvFWkVHnJxySL4y6DUb91w@mail.gmail.com>

Hey cafe, is there anybody interested in taking over maintainership of the
extensible-effects package? I'm rather busy and not keeping a good eye on
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/36106b74/attachment.html>

From nicola.gigante at gmail.com  Thu Aug 14 18:42:07 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 14 Aug 2014 20:42:07 +0200
Subject: [Haskell-cafe] haskell (and beyond) in education
In-Reply-To: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
References: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
Message-ID: <699BB899-516D-4D4A-9D8F-4B78C1998DB1@gmail.com>

Il giorno 14/ago/2014, alle ore 19:29, Rustom Mody <rustompmody at gmail.com> ha scritto:
> 
> I am collecting some data on FP used to introduce programming
> ie as a first course: http://blog.languager.org/2014/08/universities-starting-functional.html
> 
> Naturally the haskell link is the first: 
> http://www.haskell.org/haskellwiki/Haskell_in_education
> 
> I was just wondering if there are more extremal cases of this:
> eg Are there any univs using Idris/Agda to *introduce* programming/math/proofs etc
>  

The first programming course at the little University of Udine (Italy) uses Scheme. It is very effective for students with no background on programming and illuminating for who had previous exposure to imperative languages at high school (like me, at the time).

The functional programming course at the third year continues with Haskell. 

Greetings,
Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/ac0e5aa0/attachment.html>

From egarrulo at gmail.com  Thu Aug 14 18:48:52 2014
From: egarrulo at gmail.com (egarrulo)
Date: Thu, 14 Aug 2014 20:48:52 +0200
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>
References: <53ECF940.8030501@gmail.com>
 <CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>
Message-ID: <CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>

2014-08-14 20:10 GMT+02:00, Brandon Allbery <allbery.b at gmail.com>:
> You can't have two versions of the Platform installed into the same ghc;
> ghc will become extremely confused. This is essentially a ghc shortcoming
> that the Platform can't work around.

However, the README says:

  The machine doing the build needs to have a working Haskell setup: Usually,
  GHC (7.4 or later), Cabal (1.16 or later), and haddock and HsColour must be on
  the $PATH.

This is what I am trying to do: I have a working installation of the
old GHC plus the old Platform, and I am using it to build the new
Platform.  Otherwise, where am I supposed to get Cabal?  AFAIK, Cabal
comes with the Platform. Am I missing anything?

>
> The hptool issue is likely that you have an older version installed than
> the new Platform requires, and the newer one is not compatible with the
> older Platform.

Is `hptool' an executable?  If so, then there is no `hptool' in the path.

> Again, installing a separate ghc for the new Platform
> should resolve this.

I have a working installation of the new GHC, but `platform.sh'
requires a tarball, and Cabal.

Thanks for your help.

From allbery.b at gmail.com  Thu Aug 14 19:35:58 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 14 Aug 2014 15:35:58 -0400
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>
References: <53ECF940.8030501@gmail.com>
 <CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>
 <CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>
Message-ID: <CAKFCL4Xd5E9osd-qOcNkjvaW__Zy+w1Tn_J9RFx8yZrLnDWvtg@mail.gmail.com>

On Thu, Aug 14, 2014 at 2:48 PM, egarrulo <egarrulo at gmail.com> wrote:

> However, the README says:
>
>   The machine doing the build needs to have a working Haskell setup:
> Usually,
>   GHC (7.4 or later), Cabal (1.16 or later), and haddock and HsColour must
> be on
>   the $PATH.
>
> This is what I am trying to do: I have a working installation of the
> old GHC plus the old Platform, and I am using it to build the new
> Platform.  Otherwise, where am I supposed to get Cabal?  AFAIK, Cabal
> comes with the Platform. Am I missing anything?
>

You need to install a base ghc from haskell.org/ghc, minus the Platform.
HsColour from the old installation can be used as is, since it is a program
and not (used as) a library here. Cabal refers to the Cabal library, which
is part of ghc, *not* cabal-install which is the "cabal" command and which
is part of the Platform. (The library predates cabal-install by the better
part of a decade, hence the unfortunate naming.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/06fa2a44/attachment.html>

From mantkiew at gsd.uwaterloo.ca  Thu Aug 14 20:04:28 2014
From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz)
Date: Thu, 14 Aug 2014 16:04:28 -0400
Subject: [Haskell-cafe] haskell (and beyond) in education
In-Reply-To: <699BB899-516D-4D4A-9D8F-4B78C1998DB1@gmail.com>
References: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
 <699BB899-516D-4D4A-9D8F-4B78C1998DB1@gmail.com>
Message-ID: <CAGW9QSw13hSez1FBMJYEDJPQ7JBeW_-Jwi1TVpH-F-8s_7Uudg@mail.gmail.com>

Hi,

CS 115: Introduction to Computer Science 1 @ University of Waterloo, Canada
is using DrRacket.

https://www.student.cs.uwaterloo.ca/~cs115/DrRHelp

Unfortunately, this is not the case in the Software Engineering program.

Best,
-- 
Michal Antkiewicz, M.Sc., Ph.D
Research Engineer
Network for the Engineering of Complex Software-Intensive Systems (NECSIS)

University of Waterloo
http://gsd.uwaterloo.ca/mantkiew
mantkiew at gsd.uwaterloo.ca


On Thu, Aug 14, 2014 at 2:42 PM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Il giorno 14/ago/2014, alle ore 19:29, Rustom Mody <rustompmody at gmail.com>
> ha scritto:
>
> I am collecting some data on FP used to introduce programming
> ie as a first course:
> http://blog.languager.org/2014/08/universities-starting-functional.html
>
> Naturally the haskell link is the first:
> http://www.haskell.org/haskellwiki/Haskell_in_education
>
> I was just wondering if there are more extremal cases of this:
> eg Are there any univs using Idris/Agda to *introduce*
> programming/math/proofs etc
>
>
>
> The first programming course at the little University of Udine (Italy)
> uses Scheme. It is very effective for students with no background on
> programming and illuminating for who had previous exposure to imperative
> languages at high school (like me, at the time).
>
> The functional programming course at the third year continues with
> Haskell.
>
> Greetings,
> Nicola
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


<mantkiew at gsd.uwaterloo.ca>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/fbefd67d/attachment.html>

From felipe.lessa at gmail.com  Thu Aug 14 20:25:39 2014
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Thu, 14 Aug 2014 17:25:39 -0300
Subject: [Haskell-cafe] How to improve the zipwith's performance
In-Reply-To: <CAGjcJLcT0FAmNxFLbdaZZfMFg5aEL1rZDPEWOpRxvsKJsau3ew@mail.gmail.com>
References: <CAGjcJLcT0FAmNxFLbdaZZfMFg5aEL1rZDPEWOpRxvsKJsau3ew@mail.gmail.com>
Message-ID: <53ED1B43.9060409@gmail.com>

Hey, Jun Zhang!

It would be nice if you provided a full runnable example so that someone
may tinker with it testing different approaches.

As it stands, I don't have any suggestions of how you could extract more
performance.

Cheers!

-- 
Felipe.

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

From ynasser at oanda.com  Thu Aug 14 20:37:02 2014
From: ynasser at oanda.com (Yomna Nasser)
Date: Thu, 14 Aug 2014 16:37:02 -0400
Subject: [Haskell-cafe] haskell (and beyond) in education
In-Reply-To: <CAGW9QSw13hSez1FBMJYEDJPQ7JBeW_-Jwi1TVpH-F-8s_7Uudg@mail.gmail.com>
References: <CAJ+Teof5KVNGyxRHvVrx_Mb-H-GN_phohnm-pNMP9gvZCK-UCw@mail.gmail.com>
 <699BB899-516D-4D4A-9D8F-4B78C1998DB1@gmail.com>
 <CAGW9QSw13hSez1FBMJYEDJPQ7JBeW_-Jwi1TVpH-F-8s_7Uudg@mail.gmail.com>
Message-ID: <CACgCy3AUa-+NEAHTfeHoiATFOK+tJNUke11kEqnRmWbB87rZpQ@mail.gmail.com>

All the introductory computer science courses at the University of Waterloo
(CS 115/116, 135/136, 145/146) within the faculty of mathematics are taught
in Racket.

There's a fairly extensive list of schools that use Scheme here:
http://www.eimacs.com/schemers.htm (click on "Schools using scheme").


On Thu, Aug 14, 2014 at 4:04 PM, Michal Antkiewicz <
mantkiew at gsd.uwaterloo.ca> wrote:

> Hi,
>
> CS 115: Introduction to Computer Science 1 @ University of Waterloo,
> Canada is using DrRacket.
>
> https://www.student.cs.uwaterloo.ca/~cs115/DrRHelp
>
> Unfortunately, this is not the case in the Software Engineering program.
>
> Best,
> --
> Michal Antkiewicz, M.Sc., Ph.D
> Research Engineer
> Network for the Engineering of Complex Software-Intensive Systems (NECSIS)
>
> University of Waterloo
> http://gsd.uwaterloo.ca/mantkiew
> mantkiew at gsd.uwaterloo.ca
>
>
> On Thu, Aug 14, 2014 at 2:42 PM, Nicola Gigante <nicola.gigante at gmail.com>
> wrote:
>
>> Il giorno 14/ago/2014, alle ore 19:29, Rustom Mody <rustompmody at gmail.com>
>> ha scritto:
>>
>> I am collecting some data on FP used to introduce programming
>> ie as a first course:
>> http://blog.languager.org/2014/08/universities-starting-functional.html
>>
>> Naturally the haskell link is the first:
>> http://www.haskell.org/haskellwiki/Haskell_in_education
>>
>> I was just wondering if there are more extremal cases of this:
>> eg Are there any univs using Idris/Agda to *introduce*
>> programming/math/proofs etc
>>
>>
>>
>> The first programming course at the little University of Udine (Italy)
>> uses Scheme. It is very effective for students with no background on
>> programming and illuminating for who had previous exposure to imperative
>> languages at high school (like me, at the time).
>>
>> The functional programming course at the third year continues with
>> Haskell.
>>
>> Greetings,
>> Nicola
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
>
> <mantkiew at gsd.uwaterloo.ca>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/84f8995b/attachment.html>

From egarrulo at gmail.com  Thu Aug 14 21:33:03 2014
From: egarrulo at gmail.com (egarrulo)
Date: Thu, 14 Aug 2014 23:33:03 +0200
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <CAKFCL4Xd5E9osd-qOcNkjvaW__Zy+w1Tn_J9RFx8yZrLnDWvtg@mail.gmail.com>
References: <53ECF940.8030501@gmail.com>	<CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>	<CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>
 <CAKFCL4Xd5E9osd-qOcNkjvaW__Zy+w1Tn_J9RFx8yZrLnDWvtg@mail.gmail.com>
Message-ID: <53ED2B0F.8020809@gmail.com>

On 14/08/14 21:35, Brandon Allbery wrote:
> You need to install a base ghc from haskell.org/ghc
> <http://haskell.org/ghc>, minus the Platform. HsColour from the old
> installation can be used as is, since it is a program and not (used as)
> a library here. Cabal refers to the Cabal library, which is part of ghc,
> *not* cabal-install which is the "cabal" command and which is part of
> the Platform. (The library predates cabal-install by the better part of
> a decade, hence the unfortunate naming.)

But `platform.sh' needs the `cabal' command:

   $ ./platform.sh \
   >    --prefix=/opt/haskell-platform/haskell-platform-2014.2.0.0 \
   >    ../ghc-7.8.3/ghc-7.8.3-i386-unknown-linux.tar.bz2
   ./platform.sh: 24: cabal: not found
   ***
   *** Building hptool
   ***
   ./platform.sh: 29: cabal: not found

Thanks.

From allbery.b at gmail.com  Thu Aug 14 21:41:28 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 14 Aug 2014 17:41:28 -0400
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <53ED2B0F.8020809@gmail.com>
References: <53ECF940.8030501@gmail.com>
 <CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>
 <CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>
 <CAKFCL4Xd5E9osd-qOcNkjvaW__Zy+w1Tn_J9RFx8yZrLnDWvtg@mail.gmail.com>
 <53ED2B0F.8020809@gmail.com>
Message-ID: <CAKFCL4UktMxuHr+yGvAcVK4hwMsxbNS0aJ_4xj1b60h2M+m_+g@mail.gmail.com>

On Thu, Aug 14, 2014 at 5:33 PM, egarrulo <egarrulo at gmail.com> wrote:

> $ ./platform.sh \
>   >    --prefix=/opt/haskell-platform/haskell-platform-2014.2.0.0 \
>   >    ../ghc-7.8.3/ghc-7.8.3-i386-unknown-linux.tar.bz2
>   ./platform.sh: 24: cabal: not found
>

That strikes me as slightly off, I'd expect it to install an appropriate
one from the bootstrap. If not, you'll need
http://www.haskell.org/cabal/release/cabal-install-1.20.0.3/cabal-install-1.20.0.3.tar.gz
and use the bootstrap install method (bootstrap.sh from the install
package). The complication here is that it might pull in dependencies that
differ from the Platform, which is why I would expect the Platform install
script to do this itself so it can manage the dependencies appropriately.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/3886890f/attachment-0001.html>

From egarrulo at gmail.com  Thu Aug 14 22:00:07 2014
From: egarrulo at gmail.com (egarrulo)
Date: Fri, 15 Aug 2014 00:00:07 +0200
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <CAKFCL4UktMxuHr+yGvAcVK4hwMsxbNS0aJ_4xj1b60h2M+m_+g@mail.gmail.com>
References: <53ECF940.8030501@gmail.com>	<CAKFCL4WvmLGdmXk+Ora=g2My7VB3mGKSDYOqJsh4bwQ2HVqT+A@mail.gmail.com>	<CANbFods=fKNOetBPJQsR0TwrcU8cEmFyLQ5Pr12KRoX9L1DmDQ@mail.gmail.com>	<CAKFCL4Xd5E9osd-qOcNkjvaW__Zy+w1Tn_J9RFx8yZrLnDWvtg@mail.gmail.com>	<53ED2B0F.8020809@gmail.com>
 <CAKFCL4UktMxuHr+yGvAcVK4hwMsxbNS0aJ_4xj1b60h2M+m_+g@mail.gmail.com>
Message-ID: <53ED3167.9090702@gmail.com>

On 14/08/14 23:41, Brandon Allbery wrote:
>        ./platform.sh: 24: cabal: not found
>
>
> That strikes me as slightly off, I'd expect it to install an appropriate
> one from the bootstrap. If not, you'll need
> http://www.haskell.org/cabal/release/cabal-install-1.20.0.3/cabal-install-1.20.0.3.tar.gz
> and use the bootstrap install method (bootstrap.sh from the install
> package). The complication here is that it might pull in dependencies
> that differ from the Platform, which is why I would expect the Platform
> install script to do this itself so it can manage the dependencies
> appropriately.

`cabal' is the first program that `platform.sh' calls[1].  If the
installation script does not work and I am not doing anything wrong
, then I would rather file a bug report.

Thanks for your help.

[1] https://github.com/haskell/haskell-platform/blob/2014.2.0.0/platform.sh


From hjgtuyl at chello.nl  Thu Aug 14 22:43:34 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Fri, 15 Aug 2014 00:43:34 +0200
Subject: [Haskell-cafe] HaskellWiki page about SDL
Message-ID: <op.xklte001pz0j5l@alquantor>


L.S.,

Does the problem with SDL on OS X, as mentioned on the HaskellWiki page  
about SDL[0], still exist? This text is quite old and I would like to  
remove it.

Regards,
Henk-Jan van Tuyl


[0] https://www.haskell.org/haskellwiki/SDL#Haskell-SDL_with_Mac_OS_X



-- 
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 jwlato at gmail.com  Fri Aug 15 00:00:40 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 14 Aug 2014 17:00:40 -0700
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CAArEJmY9RDsNZQenxTOz52v8aXGSmUPknjtKyTPBexO9fzDJOg@mail.gmail.com>
References: <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl> <20140813232155.GB25954@henry>
 <CAJ727Gg92rE9QO7ibV6Wt7dVF-_n6G0TV7J58Uu71MzA02Ww-A@mail.gmail.com>
 <20140814071901.GE25954@henry> <53EC8155.2050808@power.com.pl>
 <20140814094101.GI25954@henry>
 <CAArEJmY9RDsNZQenxTOz52v8aXGSmUPknjtKyTPBexO9fzDJOg@mail.gmail.com>
Message-ID: <CAJ727GiDnLGMKz2+o8VbR+aGaKW95eZArerDBpax_3JUxA2kRA@mail.gmail.com>

This is starting to look promising.  I think what would be really
interesting would be to abstract out the validation logic so that it could
be presented in a more declarative fashion, something like

    itemPrice *> \item inputPrice ->
        if inputPrice > 0 then return inputPrice
            else fail ("invalid item price for item " ++ show
(item,inputPrice))

    itemTotal *> \item _ -> do
        price <- need $ itemPrice item
        qty <- need $ itemQty item
        return $ price * qty

    itemizedVat *> \item _ -> do
        vatExempt <- need $ vatStatus . client . invoice $ item
        if vatExempt then return 0 else do
            total <- need $ itemTotal item
            rate <- need $ vatRate item
            return $ calcVatForValue total rate

    total *> \invoice _ -> do
        itemTotals <- forM (items invoice) $ \item -> (,) <$> need
(itemTotal item) <*> need (itemizedVat item)
        let (itemVals,vatVals) = unzip itemTotals
            subTotal = sum itemVals
            vatTotal = sum vatVals
        return $ Total { subTotal, vatTotal, fullTotal = subTotal+vatTotal }

Inspired by the shake build system.  Off the top of my head, so there's no
system I know of that implements something like this.  But it might be a
nice way to declare complex validation rules, perhaps?  Error handling
could be handled by individual rules, so we know if there's a valid
itemPrice and itemQty, the itemTotal is valid too.

It might be tricky to implement this exactly as-is, I'm using "itemTotal"
as both a tag to specify a rule match and also a field name.  And typing
some of the input/output stuff might be non-trivial.  Seems like something
that could benefit from a specialized DSL.

John L.

On Thu, Aug 14, 2014 at 5:06 AM, Alberto G. Corona <agocorona at gmail.com>
wrote:

> Formlets ever had cascade validation:
>
> data Item= Item{ name ::String, quantity, price :: Int}
>
> Item <$>
>        <*> inputString `validate` nonEmpty
>        <*> inputInt
>        <*> inputInt
>  `validate` ( \item -> do
>       if theUniverseIsSpanding then do
>            if name item == "carrots" && price=="10" then
>                        fail "we don?t like 10 cent carrots  in an
> expanding universe"
>            else if.....
>
>
> 2014-08-14 11:41 GMT+02:00 Tom Ellis <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>:
>
> On Thu, Aug 14, 2014 at 11:28:53AM +0200, Wojtek Narczy?ski wrote:
>> > On 14.08.2014 09:19, Tom Ellis wrote:
>> > >On Wed, Aug 13, 2014 at 05:21:28PM -0700, John Lato wrote:
>> > >>On Wed, Aug 13, 2014 at 4:21 PM, Tom Ellis
>> > >>>     data LineItem = LineItem { name :: Maybe String
>> > >>>                              , quantity :: Maybe Quantity
>> > >>>                              , price :: Maybe Price }
>> > >>Rather than this definition, what about something like:
>> > >>
>> > >>     data LineItemF f = LineItem
>> > >>         { name :: f String
>> > >>         , quantity :: f Quantity
>> > >>         , price :: f Price }
>> > >It seems Wojtek already objected to this approach, though perhaps that
>> > >objection could be overcome
>> >
>> > Hmm, perhaps like this
>> >
>> > LineItemFi = LineItemFi
>> >    { name :: StringFi
>> >    , quantity :: QuantityFi
>> >    , price :: PriceFi }
>> >
>> >
>> > data LineItemUi f = LineItemUi
>> >     { name :: StringUi
>> >     , quantity :: QuantityUi
>> >     , price :: PriceUi }
>>
>> You didn't use f there.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Alberto.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/9bc08b90/attachment.html>

From zhangjun.julian at gmail.com  Fri Aug 15 02:07:29 2014
From: zhangjun.julian at gmail.com (julian)
Date: Fri, 15 Aug 2014 10:07:29 +0800
Subject: [Haskell-cafe] How to improve the zipwith's performance
In-Reply-To: <53ED1B43.9060409@gmail.com>
References: <CAGjcJLcT0FAmNxFLbdaZZfMFg5aEL1rZDPEWOpRxvsKJsau3ew@mail.gmail.com>
 <53ED1B43.9060409@gmail.com>
Message-ID: <D0F9830F-CBE7-471A-9955-7B0B7F9782F7@gmail.com>

Dear 

The runnable code is blow

import Data.Clustering.Hierarchical
import qualified Data.Vector.Primitive as DV
import System.Random
import Control.Monad


main = do
    vectorList <- genTestdata
    let cluster = dendrogram SingleLinkage vectorList getVectorDistance  
    putStrLn $ show cluster

genZero x 
    | x<5 = x
    |otherwise = 0

genVector::IO (DV.Vector Int)
genVector = do
    listRandom <- mapM (\x -> randomRIO (1,30) ) [1..20]
    let intOut = DV.fromList $ map genZero listRandom
    return intOut

genTestdata = do 
    r <- sequence  $ map (\x -> liftM (\y -> (x,y)) genVector) [1..1000]
    return r

getExp2 v1 v2 = d*d
    where
        d = v1 - v2

getExp v1 v2
    | v1 == v2 = 0
    | otherwise = getExp2 v1 v2

tfoldl  d = DV.foldl1' (+) d

changeDataType:: Int -> Double
changeDataType d = fromIntegral d

getVectorDistance::(a,DV.Vector Int)->(a, DV.Vector Int )->Double
getVectorDistance v1 v2 = fromIntegral $ tfoldl dat
    where
        l1 = snd v1
        l2 = snd v2
        dat = DV.zipWith getExp l1 l2

???? iPhone

> ? 2014?8?15????4:25?Felipe Lessa <felipe.lessa at gmail.com> ???
> 
> Hey, Jun Zhang!
> 
> It would be nice if you provided a full runnable example so that someone
> may tinker with it testing different approaches.
> 
> As it stands, I don't have any suggestions of how you could extract more
> performance.
> 
> Cheers!
> 
> -- 
> Felipe.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From travis.cardwell at extellisys.com  Fri Aug 15 04:09:16 2014
From: travis.cardwell at extellisys.com (Travis Cardwell)
Date: Fri, 15 Aug 2014 13:09:16 +0900
Subject: [Haskell-cafe] Cannot install the Haskell Platform on GNU/Linux
 (possible Cabal issue)
In-Reply-To: <53ECF940.8030501@gmail.com>
References: <53ECF940.8030501@gmail.com>
Message-ID: <53ED87EC.7030107@extellisys.com>

On 2014?08?15? 03:00, egarrulo wrote:
> I cannot install the Haskell Platform 2014.2.0.0 on my GNU/Linux system:
<SNIP>
> Any help?  Thank you.

With the new Haskell Platform release, my development environment is even
further from standard, but here is how I do it:

http://www.extellisys.com/articles/haskell-on-debian-wheezy

Cheers,

Travis

From apfelmus at quantentunnel.de  Fri Aug 15 11:27:40 2014
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Fri, 15 Aug 2014 13:27:40 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <53EBF277.2050400@power.com.pl>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
 <53EBD65C.6000501@power.com.pl>
 <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>
 <53EBF277.2050400@power.com.pl>
Message-ID: <lskqrb$sa9$1@ger.gmane.org>

Wojtek Narczy?ski wrote:
> Alexander Vieth wrote:
> 
>> I think Heinrich meant that Haskell, the language, is probably capable 
>> of carrying a great library for expressing GUI's, even if we haven't 
>> yet seen it implemented.
> 
> Haskell, the language, is great for GUIs, because... "(it) is probably 
> capable of carrying a great library for expressing GUI's, even if we 
> haven't yet seen it implemented." This is too much, I need to sleep it off.

That's indeed what I wanted to say, Alexander.

Wojtek, precise wording is important to us. We make no claim that 
"Haskell is great for GUIs", only that it is probably capable of 
carrying a great library for expressing GUIs. This distinction is 
important because it gives advice on how to solve the problem -- is 
there some inherent defect in the language and its semantics that makes 
it difficult, or is the problem more on of manpower?

Similar for the term "GUI". Apparently, you are interested in a narrow 
aspect of GUI programming -- input forms and validation. Which is 
totally fine, but not nearly as broad as GUI programming in general. The 
latter benefits immensely from FRP, but FRP is orthogonal to the 
question of validation.

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From alois.cochard at gmail.com  Fri Aug 15 11:56:59 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Fri, 15 Aug 2014 12:56:59 +0100
Subject: [Haskell-cafe] Using `jack` on Windows, sounds realistic?
Message-ID: <CAJHA+wrYkAKDKZ-m56OsxYFQcv4WLx=u9d4WDytRB3Qu7jvtqA@mail.gmail.com>

Hi all,

I've been recently used the great `jack` library from Henning Thielemann
(cc'ed) on my linux computer.

It work like a charm, but I was wondering about Windows support?

As I see Jack run on windows, I'm hoping I might be able to build my
haskell application that use `jack` on windows as well, is that realistic?
anyone have tried already?

Thanks in advance

Note: I plan to have an other backend using 'portaudio', which would allow
me to be cross-platform anyway... but using Jack bring ASIO support, which
is really need for my use case (real time synthesizer).

-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140815/0e03f8a3/attachment.html>

From schlepptop at henning-thielemann.de  Fri Aug 15 12:24:04 2014
From: schlepptop at henning-thielemann.de (Henning Thielemann)
Date: Fri, 15 Aug 2014 14:24:04 +0200
Subject: [Haskell-cafe] Using `jack` on Windows, sounds realistic?
In-Reply-To: <CAJHA+wrYkAKDKZ-m56OsxYFQcv4WLx=u9d4WDytRB3Qu7jvtqA@mail.gmail.com>
References: <CAJHA+wrYkAKDKZ-m56OsxYFQcv4WLx=u9d4WDytRB3Qu7jvtqA@mail.gmail.com>
Message-ID: <53EDFBE4.3070003@henning-thielemann.de>

Am 15.08.2014 um 13:56 schrieb Alois Cochard:

> I've been recently used the great `jack` library from Henning Thielemann
> (cc'ed) on my linux computer.
>
> It work like a charm, but I was wondering about Windows support?
>
> As I see Jack run on windows, I'm hoping I might be able to build my
> haskell application that use `jack` on windows as well, is that
> realistic? anyone have tried already?

I am using the pkgconfig feature from Cabal and hoped that this would 
make the package portable. It sounds like you tried to install the 
Haskell JACK bindings on Windows and it failed? Can you describe how it 
failed? If I can adapt the package to make it work on Windows, I'd be 
happy to do it.


Btw. 1: you can also discuss such issues at:
    http://lurk.org/groups/haskell-art/

 > Note: I plan to have an other backend using 'portaudio', which would
 > allow me to be cross-platform anyway... but using Jack bring ASIO
 > support, which is really need for my use case (real time synthesizer).

Btw. 2: I have already built a realtime synthesizer with JACK backend:
    http://hackage.haskell.org/package/synthesizer-llvm
    http://www.youtube.com/watch?v=0EQCgi5qa3E
       (You can only hear it, but you see the live-sequencer.)


From alois.cochard at gmail.com  Fri Aug 15 12:50:00 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Fri, 15 Aug 2014 13:50:00 +0100
Subject: [Haskell-cafe] Using `jack` on Windows, sounds realistic?
In-Reply-To: <53EDFBE4.3070003@henning-thielemann.de>
References: <CAJHA+wrYkAKDKZ-m56OsxYFQcv4WLx=u9d4WDytRB3Qu7jvtqA@mail.gmail.com>
 <53EDFBE4.3070003@henning-thielemann.de>
Message-ID: <CAJHA+wp2r3cpUyVQJF-kzQet3b99yy3dwOzkvDGjWFyxmp=PCw@mail.gmail.com>

Hi Henning,

Thanks for your quick answer (and your awesome libraries by the way)!

I'm afraid I didn't make myself clear:
I have *not* tried yet to install and use the binding on windows.

I was wondering if that was a reasonable thing to hope for, as most of my
friends run windows and I wanted them to try my synth :-)

It's good to hear the package was built with that in mind! I'll probably
setup a virtual machine in near future and give it a try... I'll surely let
you if I run into issues.

BTW1: Oh nice, I just registered to that list!
BTW2: Synthezire is a wonderful project thanks for that! I actually read
some of the code already, but as I'm really begining in the domain I
prefered to start from scratch (to understand well how things fit
together), I'll probably try to reuse part of your code later, that's a
very impressive work you have done here!

Cheers

Alois


On 15 August 2014 13:24, Henning Thielemann <
schlepptop at henning-thielemann.de> wrote:

> Am 15.08.2014 um 13:56 schrieb Alois Cochard:
>
>
>  I've been recently used the great `jack` library from Henning Thielemann
>> (cc'ed) on my linux computer.
>>
>> It work like a charm, but I was wondering about Windows support?
>>
>> As I see Jack run on windows, I'm hoping I might be able to build my
>> haskell application that use `jack` on windows as well, is that
>> realistic? anyone have tried already?
>>
>
> I am using the pkgconfig feature from Cabal and hoped that this would make
> the package portable. It sounds like you tried to install the Haskell JACK
> bindings on Windows and it failed? Can you describe how it failed? If I can
> adapt the package to make it work on Windows, I'd be happy to do it.
>
>
> Btw. 1: you can also discuss such issues at:
>    http://lurk.org/groups/haskell-art/
>
>
> > Note: I plan to have an other backend using 'portaudio', which would
> > allow me to be cross-platform anyway... but using Jack bring ASIO
> > support, which is really need for my use case (real time synthesizer).
>
> Btw. 2: I have already built a realtime synthesizer with JACK backend:
>    http://hackage.haskell.org/package/synthesizer-llvm
>    http://www.youtube.com/watch?v=0EQCgi5qa3E
>       (You can only hear it, but you see the live-sequencer.)
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140815/c3864db2/attachment.html>

From stephen.t.west at barclays.com  Fri Aug 15 13:38:27 2014
From: stephen.t.west at barclays.com (stephen.t.west at barclays.com)
Date: Fri, 15 Aug 2014 14:38:27 +0100
Subject: [Haskell-cafe] Functional Programming Job Opportunities
Message-ID: <8CA1B4D0843EE14DA7D5B6D622FBB478084A6D03BE@LDNPCMMGMB05.INTRANET.BARCAPINT.COM>

The Risk & Analytics team at Barclays currently has opportunities for functional programmers with experience of investment banking technology and quantitative analytics.



If you're interested, please contact me (stephen dot t dot west at barclays dot com).



Regards,

Stephen.




_______________________________________________

This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer.

For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.

_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140815/4b88bf9d/attachment.html>

From fis at etc-network.de  Fri Aug 15 13:58:56 2014
From: fis at etc-network.de (Matthias Fischmann)
Date: Fri, 15 Aug 2014 15:58:56 +0200
Subject: [Haskell-cafe] ANNOUNCE: BOB Conference 2015 Berlin
Message-ID: <20140815135856.GB26098@lig>


                         BOB Conference 2015
                               Berlin
                             23.1.2015
                       http://bobkonf.de/2015/
                       CALL FOR CONTRIBUTIONS
               English: http://bobkonf.de/2015/cfp.html
                German: http://bobkonf.de/2015/cfp.html
                    Deadline: September 30, 2014


You drive advanced software engineering methods, implement ambitious
architectures and are open to cutting-edge innovation? Attend this
conference, meet people that share your goals, and get to know the
best software tools and technologies available today. We strive to
offer you a day full of new experiences and impressions that you can
use to immediately improve your daily life as a software developer.

If you share our vision and want to contribute, submit a proposal for
a talk or tutorial!

We are looking for talks about best-of-breed software technology,
e.g.:

- functional programming
- reactive programming
- micro-service architectures
- persistent data structures and databases
- everything really that isn?t mainstream, but you think should be.

Presenters should provide the audience with information that is
practically useful for software developers.  This could take the form
of e.g.:

- experience reports
- introductory talks on technical background
- demos and how-tos

We accept proposals for presentations of 45 minutes (40 minutes talk
+ 5 minutes questions), as well as 90 minute tutorials for beginners.
The language of presentation should be either English or German.

- questions to bobkonf at active minus group dot de
- proposal deadline: September 30, 2014
- notification: October 15, 2014
- program: October 2014, 2014

For more info, visit http://bobkonf.de/2015/

Looking forward to your submissions, and to seeing you there!


cheers,
matthias

From tanielsen at gmail.com  Fri Aug 15 14:17:08 2014
From: tanielsen at gmail.com (Tom Nielsen)
Date: Fri, 15 Aug 2014 15:17:08 +0100
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
 <53EC7681.1090305@power.com.pl>
 <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
Message-ID: <CADDFi2VkifGOZR2-skRHvC8WwnSz0PCDTk=TXZ7Wd7NVUnSOiA@mail.gmail.com>

> There is no excuse for a
> spreadsheet quietly taking a never-assigned cell as zero,
> but indeed it does.

May I contribute to this interesting discussion the observation:

1
<BLANK>
3
=PRODUCT(A1:A3)

gives 3 (in Gnumeric).

So for the PRODUCT function, blanks are treated as 1.

Furthermore, you may be interested in priorknowledge's techcrunch talk in
which they promised to "disrupt blanks":
http://techcrunch.com/2012/09/11/prior-knowledge-a-predictive-database-for-developers/

Tom


On Thu, Aug 14, 2014 at 3:44 PM, <ok at cs.otago.ac.nz> wrote:

> > On 14.08.2014 03:22, ok at cs.otago.ac.nz wrote:
> >>> Let's say the user entered:
> >>>
> >>> No, Name, Qty, Price
> >>> --------------------------------------------
> >>> 1. [        ]  [99] [10]
> >>> 2. [Water   ]  [  ] [10]
> >>> 3. [Juice   ]  [ 1] [  ]
> >>>
> >>> The GUI should display total of 990,
> >> Why?  Let's be clear about this: given that
> >> information, the total is unknown and unknowable,
> >> and even if lines 1 and 2 were intended to be the
> >> same line, the existence of line 3 means that 990
> >> is almost surely LESS than the correct total,
> >> whatever that might be.
> >
> > Because this is what you would get in the most familiar software for
> > accountants, and the most widespread functional language in the world: a
> > spreadsheet. Or simply because this has been specified this way and the
> > developer is supposed to implement it.
>
> You have taught me something, and I am grateful for the
> lesson, and APPALLED at the contents of the lesson.
> I don't use spreadsheets, so I was unaware of this gross
> and horrifying bug in them.  There is no excuse for a
> spreadsheet quietly taking a never-assigned cell as zero,
> but indeed it does.  WHAT THE HELL WERE THESE PEOPLE SMOKING?
>
> It may be familiar, it may be popular, but the answer
> is beyond any reasonable question simply WRONG.
>
> As for "the developer is supposed to implement it",
> next week I'll be giving my annual ethics lecture and
> I'll be pointing out to students that the codes of practice
> of the various professional societies all agree that your
> duty goes beyond simply doing what you are told.
> If you are told to write consumer software that gets its
> sums wrong, you should not do it.
>
> However, in this context, all that matters is that you
> actually have TWO senses of "valid".
> Data may be valid-for-sums, where missing data are defined
> (wrongly, but that's your spec.) to be zero,
> without actually being honest-to-goodness-valid.
>
> The question remains whether this valid-for-sums processing
> is a property of *invoices* or a property of *forms*, and I
> claim that it's a property of invoice *forms* but not a
> property of invoices.
>
> That's one way to distinguish between valid-for-spreadsheet-sums
> and honest-to-goodness-valid.  There are others.
>
> Panko's paper, "What we know about spreadsheet errors"
> http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm
> has some scary numbers.  It contains these sentences:
>
>     In 2003, the author spoke independently with
>     experienced spreadsheet auditors in two different
>     companies in the United Kingdom, where certain
>     spreadsheets must be audited by law.
>     Each audited about three dozen spreadsheets per year.
>     Both said that they had NEVER seen a major spreadsheet
>     that was free of errors
>     Both also indicated that about five percent of the
>     spreadsheets they audited have very serious errors
>     that would have had major ramifications had they
>     not been caught.
>
> (The emphasis on NEVER is mine.)  I guess now we know one
> more reason why spreadsheet errors are ubiquitous: the
> interface is broken by design.
>
> > Imagine you are a freelance programmer and you are in the process of
> > invoicing your customer.
>
> I have no idea what is customary, but I for d--n sure would not
> use a spreadsheet to do it!  (This being a Haskell mailing list,
> I would investigate the abilities of hLedger.)
>
> >>    This is evidence that at least some people
> >> strongly prefer instant feedback; by the time they get to
> >> the end of a form they know that each and every field is
> >> at least plausible taken by itself.
> >>
> >>
> > So in the end you admit that my "design" (scratch, rather) might be what
> > young people might like?
>
> On the contrary.  You are specifying a design that lets invalid data
> enter into computations.  I'm saying they would like a design that
> stops invalid data as early as possible.  This is close in spirit
> to the Foo/FooBuilder distinction, where a Foo is never allowed to
> be in an invalid state.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140815/15263e10/attachment.html>

From marat61 at gmail.com  Fri Aug 15 19:33:35 2014
From: marat61 at gmail.com (=?UTF-8?B?0JfQsNC60LjRgNC+0LIg0JzQsNGA0LDRgg==?=)
Date: Fri, 15 Aug 2014 23:33:35 +0400
Subject: [Haskell-cafe] local mins
Message-ID: <CANmdbhcGDBe9+tajzfLGze0BaGHctqYaXiLJS3CkpFCG-LZ8zg@mail.gmail.com>

Some time ago we have a discussion and now I am ready to present my
algorithm for counting local mins. It is liniar for imperative case
and in functially too (I hope). I spent hours of debugging on it...

-- | Main entry point to the application.
module Main where

str = [5, 6, 7, 1, 0, 5, 3]

norm :: ([a],[a]) -> ([a],[a])
norm (x,[]) = (take l1 x, take l2 $ reverse x) where l1 = length x `div` 2
    l2 = length x - l1
norm ([],x) = (take l2 $ reverse x, take l1 x) where l1 = length x `div` 2
    l2 = length x - l1
norm x = x

insert :: (Ord a, Show a) => [a] -> Int -> ([(a, Int)],[(a, Int)]) ->
([(a, Int)],[(a, Int)])
insert [] _ x = x
insert x p ([],[]) = ([(head x, p)],[])
insert x p (y,[]) = insert x p (norm (y,[]))
insert x p (ys,z:zs) = if head x >= fst z then (ys,(head x, p):z:zs)
else insert x p (ys,zs)

delete :: (Ord a, Show a) => Int -> Int -> ([(a, Int)],[(a, Int)]) ->
([(a, Int)],[(a, Int)])
False = undefined
delete p r ([],x) = delete p r (norm ([],x))
delete p r (x:xs,y) = if p > (snd x + r) then (xs,y) else (x:xs,y)

getmin :: (Ord a, Show a) => ([(a, Int)],[(a, Int)]) -> a
getmin ([],[]) = error "Getmin error"
getmin ([],x) = getmin (norm ([],x))
getmin (x:xs,y) = fst x

pass :: (Ord a, Show a) => [a] -> [a]
pass [] = []
pass (x:xs) = xs

minn :: Ord a => [a] -> [a] -> [a]
minn x y = []

lmini :: (Ord a, Show a) => Int -> Int -> ([(a, Int)],[(a, Int)]) ->
[a] -> [a] -> [a]
lmini _ _ _ [] _ = []
lmini p r deq c l = if p < r then lmini (p+1) r (insert l p deq) c (pass l)
    else getmin deqn : lmini (p+1) r deqn (pass c) (pass l)
 where deqn = if p < (r*2) then insert l p deq
   else insert l p (delete (p-1) r deq)
lmin :: (Ord a, Show a) => Int -> [a] -> [a]
lmin r x = lmini 0 r ([],[]) x x

main :: IO ()
main = do
    putStrLn "Min for list"
    putStrLn $ show str

-- 
Regards, Marat.
? ????????? ?????.

From hjgtuyl at chello.nl  Fri Aug 15 22:41:51 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Sat, 16 Aug 2014 00:41:51 +0200
Subject: [Haskell-cafe] HaskellWiki page about SDL
In-Reply-To: <7F26D720-0E2C-4194-B2CB-3022F782C694@icloud.com>
References: <op.xklte001pz0j5l@alquantor>
 <7F26D720-0E2C-4194-B2CB-3022F782C694@icloud.com>
Message-ID: <op.xknnz5n9pz0j5l@alquantor>


FYI

On Fri, 15 Aug 2014 01:26:09 +0200, Irene Knapp <irene.knapp at icloud.com>  
wrote:

> For some reason, although I?m subscribed to the mailing list, I?m not  
> allowed to send stuff to it (not that I?ve ever wanted to before).   
> Sorry for the private reply!  Feel free to forward it to the list if you  
> wish.
>
> I haven?t tried in a while, but the problem is that on OS X, the SDL  
> library defines its own main() which invokes the user-provided main(),  
> and the C header file does #define main _SDL_main to make this ?work? as  
> long as an FFI isn?t involved.
>
> I checked the SDL Mercurial repo, and it still does this:
>
> http://hg.libsdl.org/SDL/file/74356aed1fa2/include/SDL_main.h  
> <http://hg.libsdl.org/SDL/file/74356aed1fa2/include/SDL_main.h>
>
> So yes, the problem still exists.  There is no easy workaround, either;  
> for Haskell code to run as a library rather than an executable requires  
> a special wrapper in C to initialize the runtime.
>
> Irene
>
>> On Aug 14, 2014, at 3:43 PM, Henk-Jan van Tuyl <hjgtuyl at chello.nl>  
>> wrote:
>>
>>
>> L.S.,
>>
>> Does the problem with SDL on OS X, as mentioned on the HaskellWiki page  
>> about SDL[0], still exist? This text is quite old and I would like to  
>> remove it.
>>
>> Regards,
>> Henk-Jan van Tuyl
>>
>>
>> [0] https://www.haskell.org/haskellwiki/SDL#Haskell-SDL_with_Mac_OS_X


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 masakazu.minamiyama at gmail.com  Sat Aug 16 07:41:04 2014
From: masakazu.minamiyama at gmail.com (=?UTF-8?B?5YyX5Y6f55yf5LiA?=)
Date: Sat, 16 Aug 2014 16:41:04 +0900
Subject: [Haskell-cafe] GHC panic!
Message-ID: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>

I am asking for help I am Haskeller of Japan I'm using GHC7.6.3 GHC has
caused the panic
https://gist.github.com/minamiyama1994/6697c3fb9c345da6715f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/007571e6/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Sat Aug 16 13:11:46 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 16 Aug 2014 14:11:46 +0100
Subject: [Haskell-cafe] GHC panic!
In-Reply-To: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
References: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
Message-ID: <53EF5892.7060405@fuuzetsu.co.uk>

On 08/16/2014 08:41 AM, ???? wrote:
> I am asking for help I am Haskeller of Japan I'm using GHC7.6.3 GHC has
> caused the panic
> https://gist.github.com/minamiyama1994/6697c3fb9c345da6715f
> 
> 

It works for me with GHC 7.8.3:

{-
[nix-shell:/tmp]$ ghc M.hs -o M



[1 of 1] Compiling Main             ( M.hs, M.o )

==================== Grand total simplifier statistics ====================
Total ticks:     30

9 PreInlineUnconditionally
  4 tpl_B1
  4 tpl_B2
  1 ds_db1Z
4 UnfoldingDone 4 GHC.Base.$
17 BetaReduction
  4 a_12
  4 b_13
  4 tpl_B1
  4 tpl_B2
  1 ds_db1Z
2 SimplifierDone 2


Linking M ...
-}


For anyone interested, the dependencies are twitter-conduit, conduit, lens.


-- 
Mateusz K.

From ben at smart-cactus.org  Sat Aug 16 13:52:37 2014
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 16 Aug 2014 09:52:37 -0400
Subject: [Haskell-cafe] GHC panic!
In-Reply-To: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
References: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
Message-ID: <87bnrk1qze.fsf@gmail.com>

???? <masakazu.minamiyama at gmail.com> writes:

> I am asking for help I am Haskeller of Japan I'm using GHC7.6.3 GHC has
> caused the panic
> https://gist.github.com/minamiyama1994/6697c3fb9c345da6715f

I can reproduce the issue on my end with 7.6.3.  Setting
-fsimpl-tick-factor=10000 allows the build to proceed. This is a bit odd
as I don't see anything in your code that should give the simplifier too
much grief, but I could be missing something.  Unless you intend on
releasing the code I would probably add a 'Ghc-Options:
-fsimpl-tick-factor=1000' to your Cabal file for now.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/c86efe9c/attachment.sig>

From ben at smart-cactus.org  Sat Aug 16 14:09:57 2014
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 16 Aug 2014 10:09:57 -0400
Subject: [Haskell-cafe] GHC panic!
In-Reply-To: <87bnrk1qze.fsf@gmail.com>
References: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
 <87bnrk1qze.fsf@gmail.com>
Message-ID: <877g281q6i.fsf@gmail.com>


CCing Michael in case this is something Conduit related that he
recognizes.

Ben Gamari <ben at smart-cactus.org> writes:

> ???? <masakazu.minamiyama at gmail.com> writes:
>
>> I am asking for help I am Haskeller of Japan I'm using GHC7.6.3 GHC has
>> caused the panic
>> https://gist.github.com/minamiyama1994/6697c3fb9c345da6715f
>
> I can reproduce the issue on my end with 7.6.3.  Setting
> -fsimpl-tick-factor=10000 allows the build to proceed. This is a bit odd
> as I don't see anything in your code that should give the simplifier too
> much grief, but I could be missing something.  Unless you intend on
> releasing the code I would probably add a 'Ghc-Options:
> -fsimpl-tick-factor=1000' to your Cabal file for now.
>
That being said, the Core here does look a bit concerning with blocks of
this nature being replicated 255 times (with both tick factors of 1000
and 2000),

    a2_rzJz
    a2_rzJz =
      \ @ a_X7Iy eta_X7IA _ _ eta3_B1 -> (# eta3_B1, eta_X7IA #)
    
    lvl24_rzJA
    lvl24_rzJA =
      IOError (Nothing) NoSuchThing getEnv3 getEnv2 (Nothing) lvl18_rzJs
    
    lvl25_rzJB
    lvl25_rzJB =
      \ @ a_a90p @ b_a90q m_a90r k_a90s r_X93X ->
        let {
          ds_X956
          ds_X956 = (m_a90r `cast` ...) r_X93X } in
        (\ r1_X95b s_X8Wq ->
           case (((ds_X956 `cast` ...) r1_X95b) `cast` ...) s_X8Wq
           of _ { (# ipv_X8SU, ipv1_X8SW #) ->
           ((((((k_a90s ipv1_X8SW) `cast` ...) r_X93X) `cast` ...) r1_X95b)
            `cast` ...)
             ipv_X8SU
           })
        `cast` ...

With associated case matches in `main`

I suppose it's posssible that this is intended, although the code does
seem quite bloated for such a simple program. Full Core here[1].

Cheers,

- Ben


[1] http://mw0.mooo.com/~ben/Main.core
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/a32aa64b/attachment.sig>

From wojtek at power.com.pl  Sat Aug 16 19:53:58 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Sat, 16 Aug 2014 21:53:58 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <CADDFi2VkifGOZR2-skRHvC8WwnSz0PCDTk=TXZ7Wd7NVUnSOiA@mail.gmail.com>
References: <53E940BF.5040500@power.com.pl>
 <fdddebd36638a465c1eac482c0be80d4.squirrel@chasm.otago.ac.nz>
 <53E9C868.9090406@power.com.pl> <864mxi6on0.fsf@gmail.com>
 <53E9F06D.5090804@power.com.pl> <20140813103758.GP1527@henry>
 <53EBCB23.9030306@power.com.pl>
 <517f6df0024a309993f9b0afed14daab.squirrel@chasm.otago.ac.nz>
 <53EC7681.1090305@power.com.pl>
 <1aa34c1208689edf12f99dde212e7bfd.squirrel@chasm.otago.ac.nz>
 <CADDFi2VkifGOZR2-skRHvC8WwnSz0PCDTk=TXZ7Wd7NVUnSOiA@mail.gmail.com>
Message-ID: <53EFB6D6.5030309@power.com.pl>

On 15.08.2014 16:17, Tom Nielsen wrote:
> > There is no excuse for a
> > spreadsheet quietly taking a never-assigned cell as zero,
> > but indeed it does.
>
> May I contribute to this interesting discussion the observation:
>
> 1
> <BLANK>
> 3
> =PRODUCT(A1:A3)
>
> gives 3 (in Gnumeric).
>
> So for the PRODUCT function, blanks are treated as 1.
>
>

At the same time
= A1 * A2 * A3
gives 0 (in OpenOffice).

This is a bit too much, even for me.

From semen at trygub.com  Sat Aug 16 21:05:30 2014
From: semen at trygub.com (Semen Trygubenko / =?utf-8?B?0KHQtdC80LXQvSDQotGA0LjQs9GD0LHQtdC9?= =?utf-8?B?0LrQvg==?=)
Date: Sat, 16 Aug 2014 22:05:30 +0100
Subject: [Haskell-cafe] tree insert and laziness
Message-ID: <20140816210530.GA83416@inanna.trygub.com>

Dear Haskell-Cafe,

I'm presently reviewing a translation of the following paragraph
(taken from LUaH, chapter 8):

http://learnyouahaskell.com/making-our-own-types-and-typeclasses

"In languages like C, we'd do this by modifying the pointers
and values inside the tree. In Haskell, we can't really modify our tree,
so we have to make a new sub-tree each time we decide to go left
or right and in the end the insertion function returns a completely new tree,
because Haskell doesn't really have a concept of pointer, just values.
Hence, the type for our insertion function is going
to be something like a -> Tree a - > Tree a. It takes an element and a tree
and returns a new tree that has that element inside.
This might seem like it's inefficient but laziness takes care of that
problem."

If it is really the laziness that makes this approach efficient?
If it isn't, what did the author want to say in the last sentence?

Thank you,
Semen


-- 
????? ?????????? http://trygub.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/7e1c66b7/attachment.sig>

From wojtek at power.com.pl  Sat Aug 16 21:51:48 2014
From: wojtek at power.com.pl (=?UTF-8?B?V29qdGVrIE5hcmN6ecWEc2tp?=)
Date: Sat, 16 Aug 2014 23:51:48 +0200
Subject: [Haskell-cafe] The Good, the Bad and the GUI
In-Reply-To: <lskqrb$sa9$1@ger.gmane.org>
References: <53E940BF.5040500@power.com.pl>
 <CAKFCL4XYEyvmXT+P+HBAbR7iGFTWnVKixwuoZ71t-LHaGYFuSQ@mail.gmail.com>
 <CAArEJmYmm7y83yt3Y7rwxsF=cdSeb9arXM-znxNN-Da-0QP4wA@mail.gmail.com>
 <53E94A68.1070303@power.com.pl>
 <CAJN5CV+41RuL-1ghhnX0JifX3K3iKCHHY3B=T83xw+LKkZpnjA@mail.gmail.com>
 <CAArEJmaAiWz7L2S59DbTVUkHPTu2XHoj1xVBHPBRWvTugc1fjw@mail.gmail.com>
 <53E9F480.6050304@power.com.pl> <lse27v$f90$1@ger.gmane.org>
 <53EA964A.3000404@power.com.pl> <lsfq14$5b7$1@ger.gmane.org>
 <53EBD65C.6000501@power.com.pl>
 <B38471AB-4EF5-4C1F-9144-79DE6BF7D919@lagoa.com>
 <53EBF277.2050400@power.com.pl> <lskqrb$sa9$1@ger.gmane.org>
Message-ID: <53EFD274.5090900@power.com.pl>

On 15.08.2014 13:27, Heinrich Apfelmus wrote:
> Wojtek, precise wording is important to us. We make no claim that 
> "Haskell is great for GUIs", only that it is probably capable of 
> carrying a great library for expressing GUIs. This distinction is 
> important because it gives advice on how to solve the problem -- is 
> there some inherent defect in the language and its semantics that 
> makes it difficult, or is the problem more on of manpower?
>
GUIs are hard, in any language.
-----------------------------------------------------------
http://www.emarcus.org/papers/gpce2009-marcus.pdf
http://www.cs.uic.edu/~hinrichs/papers/hinrichs2011plato.pdf

I am looking for solutions on a Haskell list, because I think chances of 
finding them here are higher than elsewhere.

So let me ask again, any ideas on how would you write down rules for: 
text field lengths or numeric field ranges, in such a library, for a start?

> Similar for the term "GUI". Apparently, you are interested in a narrow 
> aspect of GUI programming -- input forms and validation. Which is 
> totally fine, but not nearly as broad as GUI programming in general.
>
You are totally right here. I should have said I meant Web UIs, mostly 
interactive forms.

-- 
Wojtek

From vigalchin at gmail.com  Sun Aug 17 00:16:21 2014
From: vigalchin at gmail.com (Vasili I. Galchin)
Date: Sat, 16 Aug 2014 19:16:21 -0500
Subject: [Haskell-cafe] HsUnix.h on Ubuntu Linux
Message-ID: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>

1) I forgot how to get this include file

2) where does it go under /usr/include ???

From ivan.miljenovic at gmail.com  Sun Aug 17 00:18:11 2014
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sun, 17 Aug 2014 10:18:11 +1000
Subject: [Haskell-cafe] HsUnix.h on Ubuntu Linux
In-Reply-To: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>
References: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>
Message-ID: <CA+u6gby9D+39sB49VdxGRC+J_hBqS-nohAXpRhSsky7kjip_BA@mail.gmail.com>

Looks like it's part of either the unix or unix-compat Haskell
packages, so just install those?

On 17 August 2014 10:16, Vasili I. Galchin <vigalchin at gmail.com> wrote:
> 1) I forgot how to get this include file
>
> 2) where does it go under /usr/include ???
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



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

From allbery.b at gmail.com  Sun Aug 17 00:18:47 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 16 Aug 2014 20:18:47 -0400
Subject: [Haskell-cafe] HsUnix.h on Ubuntu Linux
In-Reply-To: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>
References: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>
Message-ID: <CAKFCL4VBCdUvqb1VkC2aAMrufsLHn7opRbSsopZCSHKCFx-N=w@mail.gmail.com>

On Sat, Aug 16, 2014 at 8:16 PM, Vasili I. Galchin <vigalchin at gmail.com>
wrote:

> 1) I forgot how to get this include file
> 2) where does it go under /usr/include ???
>

If something is looking for that then your Haskell "unix" package is
severely broken and should be reinstalled.

(It does not belong in /usr/include at all; it's part of the "unix" package
internals.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/00a3e144/attachment.html>

From allbery.b at gmail.com  Sun Aug 17 00:21:31 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 16 Aug 2014 20:21:31 -0400
Subject: [Haskell-cafe] HsUnix.h on Ubuntu Linux
In-Reply-To: <CAKFCL4VBCdUvqb1VkC2aAMrufsLHn7opRbSsopZCSHKCFx-N=w@mail.gmail.com>
References: <CA+0XtC9vTcgLr7KbzCCToMNATyuviiTG0s9s0tbsCufCyzbyUA@mail.gmail.com>
 <CAKFCL4VBCdUvqb1VkC2aAMrufsLHn7opRbSsopZCSHKCFx-N=w@mail.gmail.com>
Message-ID: <CAKFCL4UEzLohSec2Hp_WXBOa8JQ6UVOu89qGytmxOk7iBGQLeA@mail.gmail.com>

On Sat, Aug 16, 2014 at 8:18 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> If something is looking for that then your Haskell "unix" package is
> severely broken and should be reinstalled.
>

Alternately you are on a Linux which does separate runtime and dev packages
even for Haskell packages which are arguably dev only, and you need to
install something like libghc-unix-dev.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140816/f3f25e83/attachment.html>

From masakazu.minamiyama at gmail.com  Sun Aug 17 07:09:31 2014
From: masakazu.minamiyama at gmail.com (=?UTF-8?B?5YyX5Y6f55yf5LiA?=)
Date: Sun, 17 Aug 2014 16:09:31 +0900
Subject: [Haskell-cafe] GHC panic!
In-Reply-To: <87bnrk1qze.fsf@gmail.com>
References: <CAJQyKd29Vi9oYF1QoPPnBp6V93nnVMJbHaEG3WFhLb8qAiDFSQ@mail.gmail.com>
 <87bnrk1qze.fsf@gmail.com>
Message-ID: <CAJQyKd2oJgh-ZrO8EdYzBU_iX5dZdhXyL1xPLp1bmQd54n1zaA@mail.gmail.com>

Thank you.
I do `-fsimpl-tick-factor=1024` and it is ok.
Thank you very much everyone.


2014-08-16 22:52 GMT+09:00 Ben Gamari <ben at smart-cactus.org>:

> ???? <masakazu.minamiyama at gmail.com> writes:
>
> > I am asking for help I am Haskeller of Japan I'm using GHC7.6.3 GHC has
> > caused the panic
> > https://gist.github.com/minamiyama1994/6697c3fb9c345da6715f
>
> I can reproduce the issue on my end with 7.6.3.  Setting
> -fsimpl-tick-factor=10000 allows the build to proceed. This is a bit odd
> as I don't see anything in your code that should give the simplifier too
> much grief, but I could be missing something.  Unless you intend on
> releasing the code I would probably add a 'Ghc-Options:
> -fsimpl-tick-factor=1000' to your Cabal file for now.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140817/b060118b/attachment.html>

From nicola.gigante at gmail.com  Sun Aug 17 07:52:27 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Sun, 17 Aug 2014 09:52:27 +0200
Subject: [Haskell-cafe] tree insert and laziness
In-Reply-To: <20140816210530.GA83416@inanna.trygub.com>
References: <20140816210530.GA83416@inanna.trygub.com>
Message-ID: <5FD2AEEE-740B-439B-B3DE-308AF48F0CD1@gmail.com>


Il giorno 16/ago/2014, alle ore 23:05, Semen Trygubenko / ????? ?????????? <semen at trygub.com> ha scritto:

> Dear Haskell-Cafe,
> 
> I'm presently reviewing a translation of the following paragraph
> (taken from LUaH, chapter 8):
> 
> http://learnyouahaskell.com/making-our-own-types-and-typeclasses
> 
> "In languages like C, we'd do this by modifying the pointers
> and values inside the tree. In Haskell, we can't really modify our tree,
> so we have to make a new sub-tree each time we decide to go left
> or right and in the end the insertion function returns a completely new tree,
> because Haskell doesn't really have a concept of pointer, just values.
> Hence, the type for our insertion function is going
> to be something like a -> Tree a - > Tree a. It takes an element and a tree
> and returns a new tree that has that element inside.
> This might seem like it's inefficient but laziness takes care of that
> problem."
> 
> If it is really the laziness that makes this approach efficient?
> If it isn't, what did the author want to say in the last sentence?
> 

I think he wants to say that, unlike what would happen in a strict language,
the function is not going to really copy the entire tree only to insert
a new value, because the evaluation of the function is lazy, thus it
will evaluate only some nodes of the new trees, only when needed.

It is somewhat misleading, I agree, because actually we should also
take into consideration the fact that unmodified nodes gets shared
between the two trees so we're really copying only the nodes
along the path from the root to the inserted node.

Aside, are you translating it in Russian? Is it as a job, or there's
a community effort of translation of that book in other languages?

> Thank you,
> Semen

Bye,
Nicola

From daniel.trstenjak at gmail.com  Sun Aug 17 07:58:41 2014
From: daniel.trstenjak at gmail.com (Daniel Trstenjak)
Date: Sun, 17 Aug 2014 09:58:41 +0200
Subject: [Haskell-cafe] tree insert and laziness
In-Reply-To: <20140816210530.GA83416@inanna.trygub.com>
References: <20140816210530.GA83416@inanna.trygub.com>
Message-ID: <6BA1E4BB-FE1E-4F6B-A90B-80D4FE8B44DF@gmail.com>

Hi Semen,

> If it is really the laziness that makes this approach efficient?

I don't think so, it's about the concrete implementation of immutable
data structures, that most of the data structure can be shared if only
one of it's elements gets changed.

Greetings,
Daniel



From semen at trygub.com  Sun Aug 17 10:09:06 2014
From: semen at trygub.com (Semen Trygubenko / =?utf-8?B?0KHQtdC80LXQvSDQotGA0LjQs9GD0LHQtdC9?= =?utf-8?B?0LrQvg==?=)
Date: Sun, 17 Aug 2014 11:09:06 +0100
Subject: [Haskell-cafe] tree insert and laziness
In-Reply-To: <5FD2AEEE-740B-439B-B3DE-308AF48F0CD1@gmail.com>
References: <20140816210530.GA83416@inanna.trygub.com>
 <5FD2AEEE-740B-439B-B3DE-308AF48F0CD1@gmail.com>
Message-ID: <20140817100906.GA19563@inanna.trygub.com>

Hi Nicola,

On Sun, Aug 17, 2014 at 09:52:27AM +0200, Nicola Gigante wrote:
> 
> Il giorno 16/ago/2014, alle ore 23:05, Semen Trygubenko / ????? ?????????? <semen at trygub.com> ha scritto:
> 
> > Dear Haskell-Cafe,
> > 
> > I'm presently reviewing a translation of the following paragraph
> > (taken from LUaH, chapter 8):
> > 
> > http://learnyouahaskell.com/making-our-own-types-and-typeclasses
> > 
> > "In languages like C, we'd do this by modifying the pointers
> > and values inside the tree. In Haskell, we can't really modify our tree,
> > so we have to make a new sub-tree each time we decide to go left
> > or right and in the end the insertion function returns a completely new tree,
> > because Haskell doesn't really have a concept of pointer, just values.
> > Hence, the type for our insertion function is going
> > to be something like a -> Tree a - > Tree a. It takes an element and a tree
> > and returns a new tree that has that element inside.
> > This might seem like it's inefficient but laziness takes care of that
> > problem."
> > 
> > I was wondering
> > if it is really the laziness that makes this approach efficient?
> > If it isn't, what did the author want to say in the last sentence?
> > 
> 
> I think he wants to say that, unlike what would happen in a strict language,
> the function is not going to really copy the entire tree only to insert
> a new value, because the evaluation of the function is lazy, thus it
> will evaluate only some nodes of the new trees, only when needed.
> 
> It is somewhat misleading, I agree, because actually we should also
> take into consideration the fact that unmodified nodes gets shared
> between the two trees so we're really copying only the nodes
> along the path from the root to the inserted node.

Given the context (the paragraph above, minus the final sentence)
I suspect the author wants to say that the approach that involves creation of "a whole new
tree" might seem inefficient (e.g., for someone coming from the imperative school),
but in actuality it isn't, because of the way functional
data structures are implemented ? since they are immutable (and there is
sharing going on under the hood) this operation is actually a cheap one.
I just wanted to confirm this with Haskell-Cafe (the response of 
Daniel Trstenjak)?

Thanks for your help,
S.


> Aside, are you translating it in Russian? Is it as a job, or there's
> a community effort of translation of that book in other languages?

PS I am reviewing a Ukrainian translation, not as a job.



-- 
????? ?????????? http://trygub.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140817/925059f9/attachment.sig>

From dons00 at gmail.com  Sun Aug 17 12:02:22 2014
From: dons00 at gmail.com (Don Stewart)
Date: Sun, 17 Aug 2014 20:02:22 +0800
Subject: [Haskell-cafe] Haskell developer roles at Standard Chartered
Message-ID: <CAFd+Dr3o-GjQenvcgDohSOpT39moKHbFdrA95LKUHnj+Pg+M=A@mail.gmail.com>

Hi Cafe,

The Strats team at Standard Chartered is hiring expert typed FP
developers for Haskell dev roles in London.

This is a "front office" finance role - meaning you will work directly
with traders building software to automate and improve their
efficiency. The role is very development focused, and you will use
Haskell for almost all tasks: data analysis, DSLs, market data
publishing, databases, web services, desktop GUIs, large parallel
tasks, quantitative models, solvers, everything. There may be a small
amount of C++ or F# on occasion. This is a fast paced role - code you
write today will be deployed within hours to hundreds of users and has
to work.

You will join an expert team in London, and significant, demonstrable
experience in typed FP (Haskell, OCaml, F# etc) is strongly preferred.
We have more than 2 million lines of Haskell, and our own compiler. In
this context we look for skill and taste in typed API design to
capture and abstract over complex, messy systems.

Experience writing typed APIs to external systems such as databases,
web services, pub/sub platforms is very desirable. We like working
code, so if you have Hackage or github libraries, we want to see them.
We also like StackOverflow answers, blog posts, academic papers, or
other arenas where you can show broad FP ability.

The role requires physical presence on the trading floor in London.
Remote work isn't an option. Ideally you have some project and client
management skills -- you will talk to users, understand their
problems, and then implement and deliver what they really need. No
financial background is required.

If this sounds exciting to you, please send CVs to dons00 at gmail.com

From lonetiger at gmail.com  Sun Aug 17 12:05:50 2014
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Sun, 17 Aug 2014 12:05:50 +0000
Subject: [Haskell-cafe] =?utf-8?q?Issues_with_Marshalling_arrays_of_user_d?=
	=?utf-8?q?efined_types?=
Message-ID: <d0f05b86d5f8418f900bf430bbe08750@gmail.com>

Hi All,


I?ve been scratching my head for weeks trying to figure out what goes wrong with the code pasted below.


It?s compiled to a shared library (dll) on windows. I know the Storable instance is correct because calls to testFooA works, but calls to testFooListA get an invalid pointer back.


Lists of Ints do work fine, so it seems that newArray is also working. In GHCi it can dereference the pointer. And this used to work before in earlier GHC 7.0 and later 6.6 builds.


Using WinDBG and gflags I see that the pointer is indeed invalid, but that the *valid* data is there in the heap.


The example code can be found at http://lpaste.net/6148884045213204480


Anyone have an idea what I?m doing wrong?


Kind Regards,

Tamar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140817/b21efea9/attachment.html>

From noonslists at gmail.com  Sun Aug 17 12:17:16 2014
From: noonslists at gmail.com (Noon Silk)
Date: Sun, 17 Aug 2014 22:17:16 +1000
Subject: [Haskell-cafe] Haskell developer roles at Standard Chartered
In-Reply-To: <CAFd+Dr3o-GjQenvcgDohSOpT39moKHbFdrA95LKUHnj+Pg+M=A@mail.gmail.com>
References: <CAFd+Dr3o-GjQenvcgDohSOpT39moKHbFdrA95LKUHnj+Pg+M=A@mail.gmail.com>
Message-ID: <CADt_azae2HUWs=ibWcQUhsgvRi7vkzweYn6ks=FJE_o1rnAz5Q@mail.gmail.com>

> We have [...] our own compiler [...]

Why?


On Sun, Aug 17, 2014 at 10:02 PM, Don Stewart <dons00 at gmail.com> wrote:

> Hi Cafe,
>
> The Strats team at Standard Chartered is hiring expert typed FP
> developers for Haskell dev roles in London.
>
> This is a "front office" finance role - meaning you will work directly
> with traders building software to automate and improve their
> efficiency. The role is very development focused, and you will use
> Haskell for almost all tasks: data analysis, DSLs, market data
> publishing, databases, web services, desktop GUIs, large parallel
> tasks, quantitative models, solvers, everything. There may be a small
> amount of C++ or F# on occasion. This is a fast paced role - code you
> write today will be deployed within hours to hundreds of users and has
> to work.
>
> You will join an expert team in London, and significant, demonstrable
> experience in typed FP (Haskell, OCaml, F# etc) is strongly preferred.
> We have more than 2 million lines of Haskell, and our own compiler. In
> this context we look for skill and taste in typed API design to
> capture and abstract over complex, messy systems.
>
> Experience writing typed APIs to external systems such as databases,
> web services, pub/sub platforms is very desirable. We like working
> code, so if you have Hackage or github libraries, we want to see them.
> We also like StackOverflow answers, blog posts, academic papers, or
> other arenas where you can show broad FP ability.
>
> The role requires physical presence on the trading floor in London.
> Remote work isn't an option. Ideally you have some project and client
> management skills -- you will talk to users, understand their
> problems, and then implement and deliver what they really need. No
> financial background is required.
>
> If this sounds exciting to you, please send CVs to dons00 at gmail.com
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Noon Silk, ?

https://sites.google.com/site/noonsilk/

"Every morning when I wake up, I experience an exquisite joy ? the joy
of being this signature."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140817/8629b765/attachment.html>

From dons00 at gmail.com  Sun Aug 17 12:28:55 2014
From: dons00 at gmail.com (Don Stewart)
Date: Sun, 17 Aug 2014 20:28:55 +0800
Subject: [Haskell-cafe] Haskell developer roles at Standard Chartered
In-Reply-To: <CADt_azae2HUWs=ibWcQUhsgvRi7vkzweYn6ks=FJE_o1rnAz5Q@mail.gmail.com>
References: <CAFd+Dr3o-GjQenvcgDohSOpT39moKHbFdrA95LKUHnj+Pg+M=A@mail.gmail.com>
 <CADt_azae2HUWs=ibWcQUhsgvRi7vkzweYn6ks=FJE_o1rnAz5Q@mail.gmail.com>
Message-ID: <CAFd+Dr0zCCG41Hvtu35CRsejjK2BoSYra1POjEO8hDt0=WjLxg@mail.gmail.com>

Interoperability with Excel and C++ mostly, and for mobile code to
compute grids (all closures, objects etc can be serialized).

-- Don

On Sun, Aug 17, 2014 at 8:17 PM, Noon Silk <noonslists at gmail.com> wrote:
>> We have [...] our own compiler [...]
>
> Why?
>
>
> On Sun, Aug 17, 2014 at 10:02 PM, Don Stewart <dons00 at gmail.com> wrote:
>>
>> Hi Cafe,
>>
>> The Strats team at Standard Chartered is hiring expert typed FP
>> developers for Haskell dev roles in London.
>>
>> This is a "front office" finance role - meaning you will work directly
>> with traders building software to automate and improve their
>> efficiency. The role is very development focused, and you will use
>> Haskell for almost all tasks: data analysis, DSLs, market data
>> publishing, databases, web services, desktop GUIs, large parallel
>> tasks, quantitative models, solvers, everything. There may be a small
>> amount of C++ or F# on occasion. This is a fast paced role - code you
>> write today will be deployed within hours to hundreds of users and has
>> to work.
>>
>> You will join an expert team in London, and significant, demonstrable
>> experience in typed FP (Haskell, OCaml, F# etc) is strongly preferred.
>> We have more than 2 million lines of Haskell, and our own compiler. In
>> this context we look for skill and taste in typed API design to
>> capture and abstract over complex, messy systems.
>>
>> Experience writing typed APIs to external systems such as databases,
>> web services, pub/sub platforms is very desirable. We like working
>> code, so if you have Hackage or github libraries, we want to see them.
>> We also like StackOverflow answers, blog posts, academic papers, or
>> other arenas where you can show broad FP ability.
>>
>> The role requires physical presence on the trading floor in London.
>> Remote work isn't an option. Ideally you have some project and client
>> management skills -- you will talk to users, understand their
>> problems, and then implement and deliver what they really need. No
>> financial background is required.
>>
>> If this sounds exciting to you, please send CVs to dons00 at gmail.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
>
> --
> Noon Silk, ?
>
> https://sites.google.com/site/noonsilk/
>
> "Every morning when I wake up, I experience an exquisite joy ? the joy
> of being this signature."

From alpmestan at gmail.com  Sun Aug 17 12:39:44 2014
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Sun, 17 Aug 2014 14:39:44 +0200
Subject: [Haskell-cafe] Haskell developer roles at Standard Chartered
In-Reply-To: <CADt_azae2HUWs=ibWcQUhsgvRi7vkzweYn6ks=FJE_o1rnAz5Q@mail.gmail.com>
References: <CAFd+Dr3o-GjQenvcgDohSOpT39moKHbFdrA95LKUHnj+Pg+M=A@mail.gmail.com>
 <CADt_azae2HUWs=ibWcQUhsgvRi7vkzweYn6ks=FJE_o1rnAz5Q@mail.gmail.com>
Message-ID: <CADZnDvDcMaRvfAVDT652NnHX1tyE61hZEv3mfCgxAZ0GtpQ7sQ@mail.gmail.com>

Correct me if I'm wrong, but you can learn more about that compiler here:
https://www.youtube.com/watch?v=hgOzYZDrXL0

On Sun, Aug 17, 2014 at 2:17 PM, Noon Silk <noonslists at gmail.com> wrote:

> > We have [...] our own compiler [...]
>
> Why?
>
>
> On Sun, Aug 17, 2014 at 10:02 PM, Don Stewart <dons00 at gmail.com> wrote:
>
>> Hi Cafe,
>>
>> The Strats team at Standard Chartered is hiring expert typed FP
>> developers for Haskell dev roles in London.
>>
>> This is a "front office" finance role - meaning you will work directly
>> with traders building software to automate and improve their
>> efficiency. The role is very development focused, and you will use
>> Haskell for almost all tasks: data analysis, DSLs, market data
>> publishing, databases, web services, desktop GUIs, large parallel
>> tasks, quantitative models, solvers, everything. There may be a small
>> amount of C++ or F# on occasion. This is a fast paced role - code you
>> write today will be deployed within hours to hundreds of users and has
>> to work.
>>
>> You will join an expert team in London, and significant, demonstrable
>> experience in typed FP (Haskell, OCaml, F# etc) is strongly preferred.
>> We have more than 2 million lines of Haskell, and our own compiler. In
>> this context we look for skill and taste in typed API design to
>> capture and abstract over complex, messy systems.
>>
>> Experience writing typed APIs to external systems such as databases,
>> web services, pub/sub platforms is very desirable. We like working
>> code, so if you have Hackage or github libraries, we want to see them.
>> We also like StackOverflow answers, blog posts, academic papers, or
>> other arenas where you can show broad FP ability.
>>
>> The role requires physical presence on the trading floor in London.
>> Remote work isn't an option. Ideally you have some project and client
>> management skills -- you will talk to users, understand their
>> problems, and then implement and deliver what they really need. No
>> financial background is required.
>>
>> If this sounds exciting to you, please send CVs to dons00 at gmail.com
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Noon Silk, ?
>
> https://sites.google.com/site/noonsilk/
>
> "Every morning when I wake up, I experience an exquisite joy ? the joy
> of being this signature."
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140817/4fea4cb2/attachment.html>

From alan.zimm at gmail.com  Mon Aug 18 08:06:02 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 18 Aug 2014 10:06:02 +0200
Subject: [Haskell-cafe] Wish list for GHC API tooling support
Message-ID: <CANma=H8od=kWubWerJyPEqRS8PkhtCpCZN1-UvnQFvV4TU5MNw@mail.gmail.com>

At the moment the GHC API is a sort of poor relation in the haskell world,
where it could be a significantly useful resource for the growing list of
haskell tool providers.

Based on my experiences with HaRe, I have started putting together a wish
list of features I would like to see in it, which is here
https://github.com/fpco/haskell-ide/wiki/GHC-API

I welcome feedback / discussion on this.

Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/bcfd7db3/attachment.html>

From simonpj at microsoft.com  Mon Aug 18 08:20:06 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 18 Aug 2014 08:20:06 +0000
Subject: [Haskell-cafe] Wish list for GHC API tooling support
In-Reply-To: <CANma=H8od=kWubWerJyPEqRS8PkhtCpCZN1-UvnQFvV4TU5MNw@mail.gmail.com>
References: <CANma=H8od=kWubWerJyPEqRS8PkhtCpCZN1-UvnQFvV4TU5MNw@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF221BD634@DB3PRD3001MB020.064d.mgd.msft.net>

Based on my experiences with HaRe, I have started putting together a wish list of features I would like to see in it, which is here https://github.com/fpco/haskell-ide/wiki/GHC-API
Just to say: I really support having this discussion.  The GHC API is not driven enough by the needs of its clients.

I think that a client can actually access pretty much any function inside GHC, so no wonder the API feels unstable!  Steps forward might be:

?         Be very clear which functions are part of the official API. I think it?s the ones exported by GHC.lhs

?         Review them to check they all make sense

?         Add good Haddock documentation for each of them

?         Make sure that each is marked, at its definition site, as part of the GHC API.  At the moment it is far from clear when one is modifying a function that is part of the GHC API, since most of these functions aren?t in GHC.lhs

I?m happy to help, but not as a driving force.

Thanks!

Simon

From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 18 August 2014 09:06
To: haskell
Subject: [Haskell-cafe] Wish list for GHC API tooling support

At the moment the GHC API is a sort of poor relation in the haskell world, where it could be a significantly useful resource for the growing list of haskell tool providers.
Based on my experiences with HaRe, I have started putting together a wish list of features I would like to see in it, which is here https://github.com/fpco/haskell-ide/wiki/GHC-API
I welcome feedback / discussion on this.

Regards
  Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/ad981395/attachment.html>

From apfelmus at quantentunnel.de  Mon Aug 18 08:40:31 2014
From: apfelmus at quantentunnel.de (Heinrich Apfelmus)
Date: Mon, 18 Aug 2014 10:40:31 +0200
Subject: [Haskell-cafe] Wish list for GHC API tooling support
In-Reply-To: <CANma=H8od=kWubWerJyPEqRS8PkhtCpCZN1-UvnQFvV4TU5MNw@mail.gmail.com>
References: <CANma=H8od=kWubWerJyPEqRS8PkhtCpCZN1-UvnQFvV4TU5MNw@mail.gmail.com>
Message-ID: <lsse5v$9fs$1@ger.gmane.org>

Alan & Kim Zimmerman wrote:
> At the moment the GHC API is a sort of poor relation in the haskell world,
> where it could be a significantly useful resource for the growing list of
> haskell tool providers.
> 
> Based on my experiences with HaRe, I have started putting together a wish
> list of features I would like to see in it, which is here
> https://github.com/fpco/haskell-ide/wiki/GHC-API

Projects like the haskell-suite[1] and hint[2] offer more stable 
alternatives to analyzing and executing Haskell code.

GHC is simply a fast moving target, which I think is a good idea from a 
feature point of view, but it does make it difficult to offer a stable API.

   [1]: https://github.com/haskell-suite
   [2]: http://hackage.haskell.org/package/hint


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


From komendantskaya at gmail.com  Mon Aug 18 08:45:46 2014
From: komendantskaya at gmail.com (Ekaterina Komendantskaya)
Date: Mon, 18 Aug 2014 09:45:46 +0100
Subject: [Haskell-cafe] Fully funded PhD position on Computational
 Logic/Functional Programming/Interactive Theorem Proving,
 University of Dundee, Scotland
Message-ID: <CAEQEJxL9R-XmNOmpqSPOoM+Qb7FJtHxgHQkZ3gpNwdAw3UVcOA@mail.gmail.com>

One fully funded PhD position on Computational Logic/Functional
Programming/Interactive Theorem Proving
is available at the University of Dundee, Scotland.

For more information, please email  katya at computing.dundee.ac.uk or refer
to:
https://docs.google.com/document/d/10Cnlws_XPKrimo9m_CKPSXUZFCkP8FhBfD9a9xAt2AY/edit?usp=sharing

The funding is provided by EPSRC Doctoral Training Partnership Scheme, and
is available for UK residents only.

Katya

Ekaterina Komendantskaya
Senior Lecturer, Head of PhD Studies
Room 1.04, Queen Mother Building

School of Computing, University of Dundee

Scotland, DD14HN

Tel: (+44) 01382384820
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/ea8d704f/attachment.html>

From reilithion at gmail.com  Mon Aug 18 15:48:30 2014
From: reilithion at gmail.com (Lucas Paul)
Date: Mon, 18 Aug 2014 09:48:30 -0600
Subject: [Haskell-cafe] Haskell SDL2 FRP games working on Android
In-Reply-To: <53ECAF50.5070308@keera.co.uk>
References: <53ECAF50.5070308@keera.co.uk>
Message-ID: <CAMvcYxBZRuHBEDoapVST=RhamM+czQWNp78PY+Az_25A6Sm7pw@mail.gmail.com>

I, for one, am really excited about this! I can't wait to see where this
approach to Haskell on Android goes.
On Aug 14, 2014 6:45 AM, "Ivan Perez" <ivan.perez at keera.co.uk> wrote:

> Hi Caf?
>
> Answering recent questions posted on this list regarding FRP, I would like
> to announce that we have a working Android game written in Haskell, using
> SDL2 and Yampa.
>
> A short article describing the implications that this could have, together
> the libraries and backend we used, is here:
> http://keera.co.uk/blog/2014/08/13/most-inspiring-green-
> screen-you-will-ever-see/
>
> Changes made to existing libraries will be published as we move towards
> releasing the game on Google Play, and so will examples of Android programs
> written in Haskell.
>
> All the best
>
> Ivan
>
> --
> Facebook: https://www.facebook.com/keerastudios
> Twitter: https://twitter.com/KeeraStudios
> Web: http://www.keera.co.uk
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/ae17fe95/attachment.html>

From tikhon at jelv.is  Mon Aug 18 17:49:40 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Mon, 18 Aug 2014 10:49:40 -0700
Subject: [Haskell-cafe] tree insert and laziness
In-Reply-To: <20140817100906.GA19563@inanna.trygub.com>
References: <20140816210530.GA83416@inanna.trygub.com>
 <5FD2AEEE-740B-439B-B3DE-308AF48F0CD1@gmail.com>
 <20140817100906.GA19563@inanna.trygub.com>
Message-ID: <CAJN5CV+puxJo1UOZOAF1sY27yHcL7Vswaxx98mRX5fjNVCf0rQ@mail.gmail.com>

I think the most relevant part to efficiency is that trees are
*persistent*, not necessarily laziness. After all, OCaml and Clojure, among
others, manage immutable structures like this reasonably quickly themselves.

Since the tree is immutable and made up of pointers internally, we can
reuse every part that we don't modify. As a simpler example, consider a
list: to "add" a new element, we don't copy the whole list; instead, we
create a new node with a pointer to the old list. Since everything is
immutable, this is completely safe. Trees are a bit more complicated, but
the same idea remains: we only modify as little of the tree as we need,
reusing everything else.

Wikipedia has a great article[1] on persistence. I found the diagrams
especially useful, like this illustration of what a modified persistent
tree looks like[2].

[1]: http://en.wikipedia.org/wiki/Persistent_data_structure

[2]:
http://en.wikipedia.org/wiki/Persistent_data_structure#mediaviewer/File:Purely_functional_tree_after.svg


On Sun, Aug 17, 2014 at 3:09 AM, Semen Trygubenko / ????? ?????????? <
semen at trygub.com> wrote:

> Hi Nicola,
>
> On Sun, Aug 17, 2014 at 09:52:27AM +0200, Nicola Gigante wrote:
> >
> > Il giorno 16/ago/2014, alle ore 23:05, Semen Trygubenko / ?????
> ?????????? <semen at trygub.com> ha scritto:
> >
> > > Dear Haskell-Cafe,
> > >
> > > I'm presently reviewing a translation of the following paragraph
> > > (taken from LUaH, chapter 8):
> > >
> > > http://learnyouahaskell.com/making-our-own-types-and-typeclasses
> > >
> > > "In languages like C, we'd do this by modifying the pointers
> > > and values inside the tree. In Haskell, we can't really modify our
> tree,
> > > so we have to make a new sub-tree each time we decide to go left
> > > or right and in the end the insertion function returns a completely
> new tree,
> > > because Haskell doesn't really have a concept of pointer, just values.
> > > Hence, the type for our insertion function is going
> > > to be something like a -> Tree a - > Tree a. It takes an element and a
> tree
> > > and returns a new tree that has that element inside.
> > > This might seem like it's inefficient but laziness takes care of that
> > > problem."
> > >
> > > I was wondering
> > > if it is really the laziness that makes this approach efficient?
> > > If it isn't, what did the author want to say in the last sentence?
> > >
> >
> > I think he wants to say that, unlike what would happen in a strict
> language,
> > the function is not going to really copy the entire tree only to insert
> > a new value, because the evaluation of the function is lazy, thus it
> > will evaluate only some nodes of the new trees, only when needed.
> >
> > It is somewhat misleading, I agree, because actually we should also
> > take into consideration the fact that unmodified nodes gets shared
> > between the two trees so we're really copying only the nodes
> > along the path from the root to the inserted node.
>
> Given the context (the paragraph above, minus the final sentence)
> I suspect the author wants to say that the approach that involves creation
> of "a whole new
> tree" might seem inefficient (e.g., for someone coming from the imperative
> school),
> but in actuality it isn't, because of the way functional
> data structures are implemented ? since they are immutable (and there is
> sharing going on under the hood) this operation is actually a cheap one.
> I just wanted to confirm this with Haskell-Cafe (the response of
> Daniel Trstenjak)?
>
> Thanks for your help,
> S.
>
>
> > Aside, are you translating it in Russian? Is it as a job, or there's
> > a community effort of translation of that book in other languages?
>
> PS I am reviewing a Ukrainian translation, not as a job.
>
>
>
> --
> ????? ?????????? http://trygub.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/6a844306/attachment.html>

From k-bx at k-bx.com  Mon Aug 18 19:15:42 2014
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Mon, 18 Aug 2014 22:15:42 +0300
Subject: [Haskell-cafe] Type-level numbers problem
Message-ID: <CAAbahfT_RxRT=acSFHfuyRO6RetEMOAguqPP-7KV7OXjrWH-iQ@mail.gmail.com>

Hi!

I wrote one thing with type-level numbers that were represented as simple

data Zero
data Succ a

Then, in order to not invent my own peano numbers, I decided to go look for
ones, and found GHC.TypeLits. But unfortunately, it shows a weird error for
me.

Here is a piece of code: https://gist.github.com/k-bx/a7b49165399658f87358

The one that's below "main" is working properly, while the one on top of it
gives this error:

typenats.hs:17:16:
    No instance for (Op D (0 + 1)) arising from a use of `f'
    Possible fix: add an instance declaration for (Op D (0 + 1))
    In the expression: f (VJ i :: VJ D (0 + 1))
    In an equation for `f': f (VJ i) = f (VJ i :: VJ D (0 + 1))
    In the instance declaration for `Op D 0'

Maybe I worked too much on type-level numbers today to not understand this
simple error I'm getting, but could someone be so kind and explain me what
am I doing wrong?

Thank you very much!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/e40ea407/attachment.html>

From dima at dzhus.org  Mon Aug 18 19:51:29 2014
From: dima at dzhus.org (Dmitry Dzhus)
Date: Mon, 18 Aug 2014 23:51:29 +0400
Subject: [Haskell-cafe] Type-level numbers problem
In-Reply-To: <CAAbahfT_RxRT=acSFHfuyRO6RetEMOAguqPP-7KV7OXjrWH-iQ@mail.gmail.com>
References: <CAAbahfT_RxRT=acSFHfuyRO6RetEMOAguqPP-7KV7OXjrWH-iQ@mail.gmail.com>
Message-ID: <722851408391489@web18m.yandex.ru>

18.08.2014, 23:16, "Konstantine Rybnikov" <k-bx at k-bx.com>:

> The one that's below "main" is working properly, while the one on top of it gives this error:
>
> typenats.hs:17:16:
> ??? No instance for (Op D (0 + 1)) arising from a use of `f'
> ??? Possible fix: add an instance declaration for (Op D (0 + 1))
> ??? In the expression: f (VJ i :: VJ D (0 + 1))
> ??? In an equation for `f': f (VJ i) = f (VJ i :: VJ D (0 + 1))
> ??? In the instance declaration for `Op D 0'

Hello Konstantine,

I think you're using GHC 7.6.x series which had no solver
for type-level natural numbers, resulting in 0+1
not typechecking with 1.

You may find some history in https://ghc.haskell.org/trac/ghc/ticket/4385.

With GHC 7.8 this compiles fine.

Probably you can overcome the issue by providing
the required instances of `+` type family
by hand (up to the desired number), but it's hackish
and may be tedious without TH. Just switch to 7.8 already.

From k-bx at k-bx.com  Mon Aug 18 19:55:43 2014
From: k-bx at k-bx.com (Konstantine Rybnikov)
Date: Mon, 18 Aug 2014 22:55:43 +0300
Subject: [Haskell-cafe] Type-level numbers problem
In-Reply-To: <722851408391489@web18m.yandex.ru>
References: <CAAbahfT_RxRT=acSFHfuyRO6RetEMOAguqPP-7KV7OXjrWH-iQ@mail.gmail.com>
 <722851408391489@web18m.yandex.ru>
Message-ID: <CAAbahfT875x7NBkCA17B++ztuyHW016duAsk7Vb4MiG40JVcOg@mail.gmail.com>

On Mon, Aug 18, 2014 at 10:51 PM, Dmitry Dzhus <dima at dzhus.org> wrote:

> 18.08.2014, 23:16, "Konstantine Rybnikov" <k-bx at k-bx.com>:
>
> > The one that's below "main" is working properly, while the one on top of
> it gives this error:
> >
> > typenats.hs:17:16:
> >     No instance for (Op D (0 + 1)) arising from a use of `f'
> >     Possible fix: add an instance declaration for (Op D (0 + 1))
> >     In the expression: f (VJ i :: VJ D (0 + 1))
> >     In an equation for `f': f (VJ i) = f (VJ i :: VJ D (0 + 1))
> >     In the instance declaration for `Op D 0'
>
> Hello Konstantine,
>
> I think you're using GHC 7.6.x series which had no solver
> for type-level natural numbers, resulting in 0+1
> not typechecking with 1.
>
> You may find some history in https://ghc.haskell.org/trac/ghc/ticket/4385.
>
> With GHC 7.8 this compiles fine.
>
> Probably you can overcome the issue by providing
> the required instances of `+` type family
> by hand (up to the desired number), but it's hackish
> and may be tedious without TH. Just switch to 7.8 already.
>


Dmitry, you are 100% correct. Thank you very much! Moving to 7.8 straight
away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140818/3c98227f/attachment.html>

From ianmllgn at gmail.com  Tue Aug 19 07:36:00 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Tue, 19 Aug 2014 00:36:00 -0700
Subject: [Haskell-cafe] [ANN] extended-categories
Message-ID: <CAMAD-2zjPz4SCgqO9K2333P=HPp8d5+Mhc3fnk-jrOS3Sds8DA@mail.gmail.com>

extended-categories <github.com/ian-mi/extended-categories> is an
implementation of categories designed to make use of GHC's recently
enriched kind system. This project is a work in progress (only a few basic
constructs are implemented), but your comments are welcomed.
extended-categories requires a recent version of GHC (I have only tested it
with 7.8.3).

Categories are poly-kinded and have an Object constraint family:

class Category m where
    type Object (m :: k -> k -> *) (a :: k) :: Constraint
    id :: Object m a => m a a
    (.) :: (Object m a, Object m b, Object m c) => m b c -> m a b -> m a c

This means in addition to our usual categories of kind * -> * -> * we can
define categories of other kinds, for example (:-) from the constraints
package forms a category with kind Constraint -> Constraint -> * (whose
instance is used in this package)!

Functors are named (tagged) as done in the data-category package. This
allows a much wider variety of functors to be defined. Additionally
functors must provide proof that they are closed under the object
constraint, i.e. forall a. Object (Domain f c1) a :- Object (Codomain f c2)
(FMap f a).

For any two categories c1: k1 -> k1 -> * and c2: k2 -> k2 -> *, the product
category (c1 :><: c2) has kind (k1, k2) -> (k1, k2) -> *. The functor (Diag
c) is defined to be the functor from c to c :><: c which sends the object X
to '(X, X) and morphism f to the morphism f :><: f. Categories which
contain their products (the class ProductCategory) are defined by the
universal property described here <
http://en.wikipedia.org/wiki/Universal_morphism#Products>, i.e. by a
terminal morphism, for every object a and b of c, from (Diag c) to the
object '(a, b) of c :><: c. From this terminal morphism, the functions fst,
snd, (&&&), and (***), as well as the product functor from c :><: c to c
mapping '(a, b) to a >< b and f :><: g to f *** g, are defined.

Here are some examples of how this works with the standard Haskell functors:

*Functor> fmap (CanonicalF :.: CanonicalF) P.succ [P.Just 2, P.Nothing]
[Just 3,Nothing]

*Product> fmap (CanonicalF :.: ProductF) ((P.+1) :><: (P.+2)) [(1,2),
(3,4), (5,6)]
[(2,4),(4,6),(6,8)]

or alternatively fmap CanonicalF ((P.+1) *** (P.+2)) [(1,2), (3,4), (5,6)]

Next I will likely be adding more instances as well as some documentation.

Thanks for reading,
Ian Milligan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/73a07476/attachment.html>

From magicloud.magiclouds at gmail.com  Tue Aug 19 09:20:43 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Tue, 19 Aug 2014 17:20:43 +0800
Subject: [Haskell-cafe] Is there something for emacs to view project module
	structure?
Message-ID: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>

Hi,

  I think a structure viewing in editor could be very help for long file or
big project. Something like java/c# IDEs do.

  But I could not find a hint on google. Any suggestions?

-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/d31b3669/attachment.html>

From johnw at newartisans.com  Tue Aug 19 09:40:00 2014
From: johnw at newartisans.com (John Wiegley)
Date: Tue, 19 Aug 2014 04:40:00 -0500
Subject: [Haskell-cafe] [ANN] extended-categories
In-Reply-To: <CAMAD-2zjPz4SCgqO9K2333P=HPp8d5+Mhc3fnk-jrOS3Sds8DA@mail.gmail.com>
 (Ian Milligan's message of "Tue, 19 Aug 2014 00:36:00 -0700")
References: <CAMAD-2zjPz4SCgqO9K2333P=HPp8d5+Mhc3fnk-jrOS3Sds8DA@mail.gmail.com>
Message-ID: <m2ha183jin.fsf@newartisans.com>

>>>>> Ian Milligan <ianmllgn at gmail.com> writes:

> extended-categories <github.com/ian-mi/extended-categories> is an
> implementation of categories designed to make use of GHC's recently enriched
> kind system. This project is a work in progress (only a few basic constructs
> are implemented), but your comments are welcomed. extended-categories
> requires a recent version of GHC (I have only tested it with 7.8.3).

> Categories are poly-kinded and have an Object constraint family:

> class Category m where
>     type Object (m :: k -> k -> *) (a :: k) :: Constraint
>     id :: Object m a => m a a
>     (.) :: (Object m a, Object m b, Object m c) => m b c -> m a b -> m a c

Hi Ian,

You should definitely also take a look at Edward Kmett's hask library:

    https://github.com/ekmett/hask

He has taken the idea of poly-kinded Category and run with it in that library.
To compare, he has:

    class Category' (p :: i -> i -> *) where
      type Ob p :: i -> Constraint
      id :: Ob p a => p a a
      observe :: p a b -> Dict (Ob p a, Ob p b)
      (.) :: p b c -> p a b -> p a c

John

From ianmllgn at gmail.com  Tue Aug 19 10:33:31 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Tue, 19 Aug 2014 03:33:31 -0700 (PDT)
Subject: [Haskell-cafe] [ANN] extended-categories
In-Reply-To: <m2ha183jin.fsf@newartisans.com>
References: <CAMAD-2zjPz4SCgqO9K2333P=HPp8d5+Mhc3fnk-jrOS3Sds8DA@mail.gmail.com>
 <m2ha183jin.fsf@newartisans.com>
Message-ID: <dba0c9c0-6344-4ffe-aca5-5d9a84004d72@googlegroups.com>

Hi John, amazingly I hadn't ran into this package. It seems that we take 
very different approaches to functors. I borrowed the 'data-category' 
approach of named functors, while hask uses the standard approach of 
implicit functors. Without explicit functors, there are many functors that 
we cannot express, such as the product functor or the diagonal functor. I 
will have to look at hask in more depth, however, I am sure there are many 
ideas I could borrow.

Ian

On Tuesday, August 19, 2014 2:40:21 AM UTC-7, John Wiegley wrote:
>
> >>>>> Ian Milligan <ianm... at gmail.com <javascript:>> writes: 
>
> > extended-categories <github.com/ian-mi/extended-categories> is an 
> > implementation of categories designed to make use of GHC's recently 
> enriched 
> > kind system. This project is a work in progress (only a few basic 
> constructs 
> > are implemented), but your comments are welcomed. extended-categories 
> > requires a recent version of GHC (I have only tested it with 7.8.3). 
>
> > Categories are poly-kinded and have an Object constraint family: 
>
> > class Category m where 
> >     type Object (m :: k -> k -> *) (a :: k) :: Constraint 
> >     id :: Object m a => m a a 
> >     (.) :: (Object m a, Object m b, Object m c) => m b c -> m a b -> m a 
> c 
>
> Hi Ian, 
>
> You should definitely also take a look at Edward Kmett's hask library: 
>
>     https://github.com/ekmett/hask 
>
> He has taken the idea of poly-kinded Category and run with it in that 
> library. 
> To compare, he has: 
>
>     class Category' (p :: i -> i -> *) where 
>       type Ob p :: i -> Constraint 
>       id :: Ob p a => p a a 
>       observe :: p a b -> Dict (Ob p a, Ob p b) 
>       (.) :: p b c -> p a b -> p a c 
>
> John 
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/e469a2d1/attachment.html>

From tekul.hs at gmail.com  Tue Aug 19 12:32:09 2014
From: tekul.hs at gmail.com (Luke Taylor)
Date: Tue, 19 Aug 2014 13:32:09 +0100
Subject: [Haskell-cafe] Is there something for emacs to view project
 module structure?
In-Reply-To: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>
References: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>
Message-ID: <53F343C9.7010202@gmail.com>

On 19/08/2014 10:20, Magicloud Magiclouds wrote:
> Hi,
>
>    I think a structure viewing in editor could be very help for long
> file or big project. Something like java/c# IDEs do.
>
>    But I could not find a hint on google. Any suggestions?
>

Not in emacs, but there are several suggestions in this stackoverflow 
answer:

http://stackoverflow.com/questions/7427094/generate-diagrams-for-haskell-code

I've used graphmod before but I wasn't aware of sourcegraph, which seems 
to include a lot more.

From magicloud.magiclouds at gmail.com  Tue Aug 19 12:37:31 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Tue, 19 Aug 2014 20:37:31 +0800
Subject: [Haskell-cafe] Is there something for emacs to view project
 module structure?
In-Reply-To: <53F343C9.7010202@gmail.com>
References: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>
 <53F343C9.7010202@gmail.com>
Message-ID: <CABErt4d5DzyTh_teTckr1Qhr5Q-4U3w9f0jvOEvZfeDCyqH7WA@mail.gmail.com>

Great. Thank you. I will try everyone.


On Tue, Aug 19, 2014 at 8:32 PM, Luke Taylor <tekul.hs at gmail.com> wrote:

> On 19/08/2014 10:20, Magicloud Magiclouds wrote:
>
>> Hi,
>>
>>    I think a structure viewing in editor could be very help for long
>> file or big project. Something like java/c# IDEs do.
>>
>>    But I could not find a hint on google. Any suggestions?
>>
>>
> Not in emacs, but there are several suggestions in this stackoverflow
> answer:
>
> http://stackoverflow.com/questions/7427094/generate-
> diagrams-for-haskell-code
>
> I've used graphmod before but I wasn't aware of sourcegraph, which seems
> to include a lot more.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/53703286/attachment.html>

From rustompmody at gmail.com  Tue Aug 19 15:49:20 2014
From: rustompmody at gmail.com (Rustom Mody)
Date: Tue, 19 Aug 2014 21:19:20 +0530
Subject: [Haskell-cafe] Is there something for emacs to view project
 module structure?
In-Reply-To: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>
References: <CABErt4dEqhqKXkxDydZmipg_t_ra-yg4jbFZGKs2qPL35S68Dw@mail.gmail.com>
Message-ID: <CAJ+TeoerHt+sF9W20ab9YRCZY=Ko=GMRGEP+mJaT-VTkqqgJGw@mail.gmail.com>

On Tue, Aug 19, 2014 at 2:50 PM, Magicloud Magiclouds <
magicloud.magiclouds at gmail.com> wrote:

> Hi,
>
>   I think a structure viewing in editor could be very help for long file
> or big project. Something like java/c# IDEs do.
>
>   But I could not find a hint on google. Any suggestions?
>
> --
>

speedbar and ecb are the tools for this
speedbar seems to work OTOB
ecb I am not sure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/9f887a33/attachment.html>

From kaspar.bumke at gmail.com  Tue Aug 19 18:08:32 2014
From: kaspar.bumke at gmail.com (Kaspar Emanuel)
Date: Tue, 19 Aug 2014 19:08:32 +0100
Subject: [Haskell-cafe] Reducing CPU load when using Helm
Message-ID: <CAB+dmjjkR7BiVQDEkWURRooWV_peRJD8T+Mm8DFO9ay_uT-Y1w@mail.gmail.com>

Forwarding this to haskell-cafe as it failed before.

On 18 August 2014 20:24, Kaspar Emanuel <kaspar.bumke at gmail.com> wrote:
> Hi,
>
> are there some simple tricks to reduce the CPU load? This simple
> square rendering sits at 20% CPU even when the window size remains
> constant.
>
> import FRP.Helm
> import qualified FRP.Helm.Window as Window
>
> render :: (Int, Int) -> Element
> render (w, h) = collage w h [move (100, 100) $ filled red $ square 64]
>
> main :: IO ()
> main = do
>     engine <- startup defaultConfig
>     run engine $ render <~ Window.dimensions engine
>
> The binary fractal tree  I submitted in another thread on helm-dev
> sits at 100% CPU  when the mouse isn't moving. It seems to me that
> Helm keeps re-drawing and re-computing when it doesn't need to.
>
> I started digging through the source a bit but it will take me a while
> to understand Elerea and how it samples the inputs and causes things
> to update.
>
> Are there any quick fixes?
>
> Ciao,
>
> Kaspar

From ianmllgn at gmail.com  Tue Aug 19 19:12:05 2014
From: ianmllgn at gmail.com (Ian Milligan)
Date: Tue, 19 Aug 2014 12:12:05 -0700 (PDT)
Subject: [Haskell-cafe] [ANN] extended-categories
In-Reply-To: <m2ha183jin.fsf@newartisans.com>
References: <CAMAD-2zjPz4SCgqO9K2333P=HPp8d5+Mhc3fnk-jrOS3Sds8DA@mail.gmail.com>
 <m2ha183jin.fsf@newartisans.com>
Message-ID: <f13b9644-3d80-4719-9b20-d1450d9a4c3c@googlegroups.com>

I've now borrowed the approach of hask: an installation of an arrow is 
proof that its domain and codomain are objects. This is a great 
simplification.

On Tuesday, August 19, 2014 2:40:21 AM UTC-7, John Wiegley wrote:
>
> >>>>> Ian Milligan <ianm... at gmail.com <javascript:>> writes: 
>
> > extended-categories <github.com/ian-mi/extended-categories> is an 
> > implementation of categories designed to make use of GHC's recently 
> enriched 
> > kind system. This project is a work in progress (only a few basic 
> constructs 
> > are implemented), but your comments are welcomed. extended-categories 
> > requires a recent version of GHC (I have only tested it with 7.8.3). 
>
> > Categories are poly-kinded and have an Object constraint family: 
>
> > class Category m where 
> >     type Object (m :: k -> k -> *) (a :: k) :: Constraint 
> >     id :: Object m a => m a a 
> >     (.) :: (Object m a, Object m b, Object m c) => m b c -> m a b -> m a 
> c 
>
> Hi Ian, 
>
> You should definitely also take a look at Edward Kmett's hask library: 
>
>     https://github.com/ekmett/hask 
>
> He has taken the idea of poly-kinded Category and run with it in that 
> library. 
> To compare, he has: 
>
>     class Category' (p :: i -> i -> *) where 
>       type Ob p :: i -> Constraint 
>       id :: Ob p a => p a a 
>       observe :: p a b -> Dict (Ob p a, Ob p b) 
>       (.) :: p b c -> p a b -> p a c 
>
> John 
> _______________________________________________ 
> Haskell-Cafe mailing list 
> Haskel... at haskell.org <javascript:> 
> http://www.haskell.org/mailman/listinfo/haskell-cafe 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/046cbd3f/attachment.html>

From kaspar.bumke at gmail.com  Tue Aug 19 20:52:13 2014
From: kaspar.bumke at gmail.com (Kaspar Emanuel)
Date: Tue, 19 Aug 2014 21:52:13 +0100
Subject: [Haskell-cafe] Reducing CPU load when using Helm
In-Reply-To: <CAB+dmjgtBMcj5EbOj5fnmfqSnQeZvA-paVZt73by449erNi5jA@mail.gmail.com>
References: <CAB+dmjgtBMcj5EbOj5fnmfqSnQeZvA-paVZt73by449erNi5jA@mail.gmail.com>
Message-ID: <CAB+dmjgr0Fiinr5h1dc9xt+=omprtW_H85_kR+5sxReb-9+m-w@mail.gmail.com>

On 18 August 2014 20:24, Kaspar Emanuel <kaspar.bumke at gmail.com> wrote:
> Hi,
>
> are there some simple tricks to reduce the CPU load? This simple
> square rendering sits at 20% CPU even when the window size remains
> constant.
>
> import FRP.Helm
> import qualified FRP.Helm.Window as Window
>
> render :: (Int, Int) -> Element
> render (w, h) = collage w h [move (100, 100) $ filled red $ square 64]
>
> main :: IO ()
> main = do
>     engine <- startup defaultConfig
>     run engine $ render <~ Window.dimensions engine
>
> The binary fractal tree  I submitted in another thread on helm-dev
> sits at 100% CPU  when the mouse isn't moving. It seems to me that
> Helm keeps re-drawing and re-computing when it doesn't need to.
>
> I started digging through the source a bit but it will take me a while
> to understand Elerea and how it samples the inputs and causes things
> to update.
>
> Are there any quick fixes?
>

So I tried stepping the render function using a time-constant. But
that just causes the resulting programs to freeze on the first frame.

https://github.com/kasbah/helm/commit/9ef9607d8057100b5b7930fa2b5e85c6040d1a44

I modified the driveNetwork function from here:
www.formicite.com/dopage.php?frp/frp.html

Bit out of my element with this stuff. I'd just like to _not_ max out
the CPU with simple graphical programs.

From nikoamia at gmail.com  Tue Aug 19 21:36:59 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Wed, 20 Aug 2014 01:36:59 +0400
Subject: [Haskell-cafe] Locking of threads in one OS thread
Message-ID: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>

Hello Cafe,

I'm using FFI to interact with a library which calls, when fail, leave
the reason in some kind of "errno"-like variable which is retrived via
another call. AFAIU, this is not thread-safe in Haskell even if
thread-local storage is used inside the library, because Haskell uses
its own thread management and the Haskell thread in the same OS thread
might be switched between the actual call and the retrival of errno
value. This should be somehow handled already in Haskell (errno is
widely used with syscalls in Linux, for example), but the source of
Foreign.C.Error suggests that this is not handled in any way at all.
For example, throwErrnoIf is implemented as such:

throwErrno loc  = do
    errno <- getErrno
    ioError (errnoToIOError loc errno Nothing Nothing)

throwErrnoIf pred loc f  = do
    res <- f
    if pred res then throwErrno loc else return res

So, the question is: how is it ensured that this block is "atomic" in
sense that at most one Haskell thread computes this whole function at
every moment in every OS thread?

Thanks for any explanations! (And sorry if my English is poor)

Nikolay.

From carter.schonwald at gmail.com  Wed Aug 20 01:02:33 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 19 Aug 2014 21:02:33 -0400
Subject: [Haskell-cafe] Locking of threads in one OS thread
In-Reply-To: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
Message-ID: <CAHYVw0xsMoFwQtpP0NUe6x6r-VYAeFWY2055wdc0oGPHHinMSw@mail.gmail.com>

several ideas
a) you can use forkOS to run the ffi call and the the subsequent errno
value checking in a pinned OS thread so you can guarantee you can access
the thread local storage
b) you could have a CallManager that keeps a MVar or queue or something,
along with a handle on the forkOS thread id, and "intiialize" the forkOS
thread with a teeny worker that read from an input MVar and writes to a
result MVar (thus guarantee only one call a time)
c) something that uses these ideas together.

theres a lot of strategies you can use. but i hope this gives you a sketch
(i can spell it out more later this week if need be)


On Tue, Aug 19, 2014 at 5:36 PM, Nikolay Amiantov <nikoamia at gmail.com>
wrote:

> Hello Cafe,
>
> I'm using FFI to interact with a library which calls, when fail, leave
> the reason in some kind of "errno"-like variable which is retrived via
> another call. AFAIU, this is not thread-safe in Haskell even if
> thread-local storage is used inside the library, because Haskell uses
> its own thread management and the Haskell thread in the same OS thread
> might be switched between the actual call and the retrival of errno
> value. This should be somehow handled already in Haskell (errno is
> widely used with syscalls in Linux, for example), but the source of
> Foreign.C.Error suggests that this is not handled in any way at all.
> For example, throwErrnoIf is implemented as such:
>
> throwErrno loc  = do
>     errno <- getErrno
>     ioError (errnoToIOError loc errno Nothing Nothing)
>
> throwErrnoIf pred loc f  = do
>     res <- f
>     if pred res then throwErrno loc else return res
>
> So, the question is: how is it ensured that this block is "atomic" in
> sense that at most one Haskell thread computes this whole function at
> every moment in every OS thread?
>
> Thanks for any explanations! (And sorry if my English is poor)
>
> Nikolay.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140819/5c5aec82/attachment.html>

From nikoamia at gmail.com  Wed Aug 20 06:31:59 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Wed, 20 Aug 2014 10:31:59 +0400
Subject: [Haskell-cafe] Locking of threads in one OS thread
In-Reply-To: <CAHYVw0xsMoFwQtpP0NUe6x6r-VYAeFWY2055wdc0oGPHHinMSw@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
 <CAHYVw0xsMoFwQtpP0NUe6x6r-VYAeFWY2055wdc0oGPHHinMSw@mail.gmail.com>
Message-ID: <CA+waHKW2AFH=2mj0Vv-anU0_V5hkF_nHLbvYH4EOdVEX-o4FTw@mail.gmail.com>

Thanks for the answer! I've thought about (c) already, and (a) and (b)
are interesting, too -- maybe (a) is my answer.

I'm very interested in how Haskell handles this already -- for
example, in "network" or "unix" package sources I haven't found any
handling of this (see [1], [2] for example) and it looks to me that
these packages are prone to this race condition -- am I right?

If this is not a known error, then my thoughts is that to add a way to
fix this without losing much speed we could add new prims -- something
like "maskPreemption#", "unmaskPreemption#" and "getPreemptionState#"
(using "mask" implementation as an example) and new "maskPreemption"
function in Control.Concurrent, for example. Prims can use
thread-local flag without any locking that runtime checks before
thread preemption -- this should be nearly unnoticeable operation in
terms of performance.

This is all just an idea of how I would implement this, and I don't
have knowledge of RTS internals, so for someone competent this may be
utter nonsense -- I'm sorry for this.

[1]: https://hackage.haskell.org/package/network-2.6.0.1/docs/src/Network-Socket-Internal.html
[2]: http://hackage.haskell.org/package/unix-2.7.0.1/docs/src/System-Posix-Error.html
? ?????????,
??????? ????????.


On Wed, Aug 20, 2014 at 5:02 AM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> several ideas
> a) you can use forkOS to run the ffi call and the the subsequent errno value
> checking in a pinned OS thread so you can guarantee you can access the
> thread local storage
> b) you could have a CallManager that keeps a MVar or queue or something,
> along with a handle on the forkOS thread id, and "intiialize" the forkOS
> thread with a teeny worker that read from an input MVar and writes to a
> result MVar (thus guarantee only one call a time)
> c) something that uses these ideas together.
>
> theres a lot of strategies you can use. but i hope this gives you a sketch
> (i can spell it out more later this week if need be)
>
>
> On Tue, Aug 19, 2014 at 5:36 PM, Nikolay Amiantov <nikoamia at gmail.com>
> wrote:
>>
>> Hello Cafe,
>>
>> I'm using FFI to interact with a library which calls, when fail, leave
>> the reason in some kind of "errno"-like variable which is retrived via
>> another call. AFAIU, this is not thread-safe in Haskell even if
>> thread-local storage is used inside the library, because Haskell uses
>> its own thread management and the Haskell thread in the same OS thread
>> might be switched between the actual call and the retrival of errno
>> value. This should be somehow handled already in Haskell (errno is
>> widely used with syscalls in Linux, for example), but the source of
>> Foreign.C.Error suggests that this is not handled in any way at all.
>> For example, throwErrnoIf is implemented as such:
>>
>> throwErrno loc  = do
>>     errno <- getErrno
>>     ioError (errnoToIOError loc errno Nothing Nothing)
>>
>> throwErrnoIf pred loc f  = do
>>     res <- f
>>     if pred res then throwErrno loc else return res
>>
>> So, the question is: how is it ensured that this block is "atomic" in
>> sense that at most one Haskell thread computes this whole function at
>> every moment in every OS thread?
>>
>> Thanks for any explanations! (And sorry if my English is poor)
>>
>> Nikolay.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

From holmisen at gmail.com  Wed Aug 20 06:52:31 2014
From: holmisen at gmail.com (Johan Holmquist)
Date: Wed, 20 Aug 2014 08:52:31 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
Message-ID: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>

Comparing two structures for equality (structurally) can be expensive. But
if their references are the same they would for sure be equal (unless (==)
was defined in some funny way). Does GHC perform any such optimization?

(Likely a question for another list but I make a stab here first. )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/5f1d916c/attachment.html>

From alois.cochard at gmail.com  Wed Aug 20 07:09:02 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Wed, 20 Aug 2014 08:09:02 +0100
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
Message-ID: <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>

Hi Johan,

Haskell does not support referential equality, as that would break
referential transparency.

http://stackoverflow.com/questions/1717553/pointer-equality-in-haskell

Cheers
 On Aug 20, 2014 7:52 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:

> Comparing two structures for equality (structurally) can be expensive. But
> if their references are the same they would for sure be equal (unless (==)
> was defined in some funny way). Does GHC perform any such optimization?
>
> (Likely a question for another list but I make a stab here first. )
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/3fd40cc8/attachment.html>

From kazu at iij.ad.jp  Wed Aug 20 07:29:13 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 20 Aug 2014 16:29:13 +0900 (JST)
Subject: [Haskell-cafe] ghc-mod v5.0.0
Message-ID: <20140820.162913.1193211018461584634.kazu@iij.ad.jp>

Hi cafe,

We are happy to announce that ghc-mod v5.0.0 has been released.
Highlights of this version is as follows:

- ghc-mod v4.x.y is suffering from the space leak of GHC
  7.8.x(*1). So, ghc-modi consumes huge memory. ghc-modi v5.0.0
  consumes much less memory thanks to workaround.

- Alejandro Serrano merges his results of Google Summer of Code. He
  implements case splitting and sophisticated type hole handling.
  I believe that he will write an article on his results but
  I also updated the manual of Emacs fronted. (*2)

- Daniel Gr?ber brushed up the internal code by bringing the GhcMod
  monad. So, the API of ghc-mod drastically changed. If you are users
  of the ghc-mod library, you should check its document.

The main purpose of this release is to show the results of GSoC to
everyone. This is a snapshot release and its API would change in the
future.

I thank two guys above since they worked hard and did good jobs.
We hope that everyone enjoys v5.0.0.

(*1) https://ghc.haskell.org/trac/ghc/ticket/9314
(*2) http://www.mew.org/~kazu/proj/ghc-mod/en/emacs.html

--Kazu

From hesselink at gmail.com  Wed Aug 20 08:23:13 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 20 Aug 2014 10:23:13 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
Message-ID: <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>

As I understood, the question was if GHC would first compare pointers,
and only call the Eq instance if the pointers are not equal. I guess
this would be safe, but I don't think GHC does such a thing.

Erik

On Wed, Aug 20, 2014 at 9:09 AM, Alois Cochard <alois.cochard at gmail.com> wrote:
> Hi Johan,
>
> Haskell does not support referential equality, as that would break
> referential transparency.
>
> http://stackoverflow.com/questions/1717553/pointer-equality-in-haskell
>
> Cheers
>
> On Aug 20, 2014 7:52 AM, "Johan Holmquist" <holmisen at gmail.com> wrote:
>>
>> Comparing two structures for equality (structurally) can be expensive. But
>> if their references are the same they would for sure be equal (unless (==)
>> was defined in some funny way). Does GHC perform any such optimization?
>>
>> (Likely a question for another list but I make a stab here first. )
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From johan.tibell at gmail.com  Wed Aug 20 08:28:55 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 20 Aug 2014 10:28:55 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
Message-ID: <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>

On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
wrote:

> As I understood, the question was if GHC would first compare pointers,
> and only call the Eq instance if the pointers are not equal. I guess
> this would be safe, but I don't think GHC does such a thing.


I think the reason it isn't done is that it's not always an optimization.
We do it manually in e.g. bytestring.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/647392b8/attachment.html>

From michael at snoyman.com  Wed Aug 20 08:35:05 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 20 Aug 2014 11:35:05 +0300
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
Message-ID: <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>

On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
>
>> As I understood, the question was if GHC would first compare pointers,
>> and only call the Eq instance if the pointers are not equal. I guess
>> this would be safe, but I don't think GHC does such a thing.
>
>
> I think the reason it isn't done is that it's not always an optimization.
> We do it manually in e.g. bytestring.
>
>
>
There are two cases I can think of where it would also change the semantics
of the code:

1. An Eq instance that doesn't obey the reflective property (not
recommended):

data BadEq = BadEq
instance Eq BadEq where
    BadEq == BadEq = False

2. Eq instances intended to avoid timing attacks, by always comparing the
entire data structure.

newtype SlowEq a = SlowEq [a]
instance Eq a => Eq (SlowEq a) where
    SlowEq x == SlowEq y = slowAnd $ length x == length y : zipWith (==) x y

slowAnd =
    loop True
  where
    loop !x [] = x
    loop !x (!y:ys) = loop (x && y) ys

(Note: not actually tested.) It's difficult for me to imagine a case though
where a timing attack could result on two data structures sharing the same
pointer; usually we'd be talking about comparing two ByteStrings or Texts
that come from very different sources.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/ec707306/attachment.html>

From holmisen at gmail.com  Wed Aug 20 09:05:34 2014
From: holmisen at gmail.com (Johan Holmquist)
Date: Wed, 20 Aug 2014 11:05:34 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
Message-ID: <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>

> As I understood, the question was if GHC would first compare pointers,
and only call the Eq instance if the pointers are not equal.

Yes, spot on!

> 1. An Eq instance that doesn't obey the reflective property (not
recommended):

And this is what I mean with "defined in some funny way". One could
consider this optimization(?) only to kick in when GHC generates the
instance definition by means of the deriving mechanism. That should be
safe(?).

> I think the reason it isn't done is that it's not always an optimization

Could you explain when it's not?


Clarification:

Consider the following:

    let xs = [1..1000] in xs == xs

xs would surely be equal but generally finding out if two lists are equal
amounts to comparing each element. If the compiler was first to check if
the objects referenced where the same, it should safely be able to yield
True without further evaluation. (In this particular example the compiler
may make other optimizations but it gives the general idea.)

Ofcourse `let x = undefined in x == x` might be considered bad to optimize
to True but maybe this could be checked somehow...





2014-08-20 10:35 GMT+02:00 Michael Snoyman <michael at snoyman.com>:

>
>
>
> On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
>> wrote:
>>
>>> As I understood, the question was if GHC would first compare pointers,
>>> and only call the Eq instance if the pointers are not equal. I guess
>>> this would be safe, but I don't think GHC does such a thing.
>>
>>
>> I think the reason it isn't done is that it's not always an optimization.
>> We do it manually in e.g. bytestring.
>>
>>
>>
> There are two cases I can think of where it would also change the
> semantics of the code:
>
> 1. An Eq instance that doesn't obey the reflective property (not
> recommended):
>
> data BadEq = BadEq
> instance Eq BadEq where
>     BadEq == BadEq = False
>
> 2. Eq instances intended to avoid timing attacks, by always comparing the
> entire data structure.
>
> newtype SlowEq a = SlowEq [a]
> instance Eq a => Eq (SlowEq a) where
>     SlowEq x == SlowEq y = slowAnd $ length x == length y : zipWith (==) x
> y
>
> slowAnd =
>     loop True
>   where
>     loop !x [] = x
>     loop !x (!y:ys) = loop (x && y) ys
>
> (Note: not actually tested.) It's difficult for me to imagine a case
> though where a timing attack could result on two data structures sharing
> the same pointer; usually we'd be talking about comparing two ByteStrings
> or Texts that come from very different sources.
>
> Michael
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/40ac2877/attachment.html>

From rudy at matela.com.br  Wed Aug 20 09:12:10 2014
From: rudy at matela.com.br (Rudy Matela)
Date: Wed, 20 Aug 2014 10:12:10 +0100
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
Message-ID: <CALCD0B9yRpG=dEg11-t9gc7j-7zfCSaJhBbSw0dDY16Yd9vAmA@mail.gmail.com>

> There are two cases I can think of where it would also change the semantics
> of the code:
>
> 1. An Eq instance that doesn't obey the reflective property (not
> recommended):
>
> data BadEq = BadEq
> instance Eq BadEq where
>     BadEq == BadEq = False
>
> 2. Eq instances intended to avoid timing attacks, by always comparing the
> entire data structure.
>
> newtype SlowEq a = SlowEq [a]
> instance Eq a => Eq (SlowEq a) where
>     SlowEq x == SlowEq y = slowAnd $ length x == length y : zipWith (==) x y
>
> slowAnd =
>     loop True
>   where
>     loop !x [] = x
>     loop !x (!y:ys) = loop (x && y) ys

Third case that would change the semantics:

3. Non-terminating evaluation of a value:

let x = [1..]
in x == x

From hesselink at gmail.com  Wed Aug 20 09:15:27 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 20 Aug 2014 11:15:27 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
Message-ID: <CAPeieQGzrdH3bFoKHL0OPvkPa6TcTKK5TVHNASKr3+hUrxUYwQ@mail.gmail.com>

On Wed, Aug 20, 2014 at 10:35 AM, Michael Snoyman <michael at snoyman.com> wrote:
>
> On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>>
>> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
>> wrote:
>>>
>>> As I understood, the question was if GHC would first compare pointers,
>>> and only call the Eq instance if the pointers are not equal. I guess
>>> this would be safe, but I don't think GHC does such a thing.
>>
>> I think the reason it isn't done is that it's not always an optimization.
>> We do it manually in e.g. bytestring.
>
> There are two cases I can think of where it would also change the semantics
> of the code:
>
> 1. An Eq instance that doesn't obey the reflective property (not
> recommended):
>
> data BadEq = BadEq
> instance Eq BadEq where
>     BadEq == BadEq = False

I think this is just a buggy instance, and if you do this, nothing is
guaranteed. Many functions with an Eq constraint will also not work.
Interestingly, reflexivity is not a law listed in the haddock
documentation.

Erik

From ivan.miljenovic at gmail.com  Wed Aug 20 09:18:50 2014
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 20 Aug 2014 19:18:50 +1000
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
Message-ID: <CA+u6gbydyCaBd=PG5gcGa=zyWOydKoK+7KXA8VQzDFJLMoLApA@mail.gmail.com>

On 20 August 2014 19:05, Johan Holmquist <holmisen at gmail.com> wrote:
>> As I understood, the question was if GHC would first compare pointers,
> and only call the Eq instance if the pointers are not equal.
>
> Yes, spot on!
>
>
>> 1. An Eq instance that doesn't obey the reflective property (not
>> recommended):
>
> And this is what I mean with "defined in some funny way". One could consider
> this optimization(?) only to kick in when GHC generates the instance
> definition by means of the deriving mechanism. That should be safe(?).

Unless deep down a value is used that _does_ have a dodgy custom
derived Eq instance.

>
>
>> I think the reason it isn't done is that it's not always an optimization
>
> Could you explain when it's not?
>
>
> Clarification:
>
> Consider the following:
>
>     let xs = [1..1000] in xs == xs
>
> xs would surely be equal but generally finding out if two lists are equal
> amounts to comparing each element. If the compiler was first to check if the
> objects referenced where the same, it should safely be able to yield True
> without further evaluation. (In this particular example the compiler may
> make other optimizations but it gives the general idea.)
>
> Ofcourse `let x = undefined in x == x` might be considered bad to optimize
> to True but maybe this could be checked somehow...
>
>
>
>
>
> 2014-08-20 10:35 GMT+02:00 Michael Snoyman <michael at snoyman.com>:
>>
>>
>>
>>
>> On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>>
>>> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
>>> wrote:
>>>>
>>>> As I understood, the question was if GHC would first compare pointers,
>>>> and only call the Eq instance if the pointers are not equal. I guess
>>>> this would be safe, but I don't think GHC does such a thing.
>>>
>>>
>>> I think the reason it isn't done is that it's not always an optimization.
>>> We do it manually in e.g. bytestring.
>>>
>>>
>>
>> There are two cases I can think of where it would also change the
>> semantics of the code:
>>
>> 1. An Eq instance that doesn't obey the reflective property (not
>> recommended):
>>
>> data BadEq = BadEq
>> instance Eq BadEq where
>>     BadEq == BadEq = False
>>
>> 2. Eq instances intended to avoid timing attacks, by always comparing the
>> entire data structure.
>>
>> newtype SlowEq a = SlowEq [a]
>> instance Eq a => Eq (SlowEq a) where
>>     SlowEq x == SlowEq y = slowAnd $ length x == length y : zipWith (==) x
>> y
>>
>> slowAnd =
>>     loop True
>>   where
>>     loop !x [] = x
>>     loop !x (!y:ys) = loop (x && y) ys
>>
>> (Note: not actually tested.) It's difficult for me to imagine a case
>> though where a timing attack could result on two data structures sharing the
>> same pointer; usually we'd be talking about comparing two ByteStrings or
>> Texts that come from very different sources.
>>
>> Michael
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

From johan.tibell at gmail.com  Wed Aug 20 09:20:37 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 20 Aug 2014 11:20:37 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
Message-ID: <CAK-tuPahzsVxyvHE+96=SosBt5X4=U3XARTkpj=6AEGH6wFtog@mail.gmail.com>

On Wed, Aug 20, 2014 at 11:05 AM, Johan Holmquist <holmisen at gmail.com>
wrote:

> > I think the reason it isn't done is that it's not always an optimization
>
> Could you explain when it's not?
>

A simple example is when the two values aren't equal, as you'll be doing
one more branch than you otherwise would. The extra branch might also hurt
the branch predictor even in the equal case, if the branch is hard to
predict.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/cd71f61c/attachment.html>

From michael at snoyman.com  Wed Aug 20 09:20:43 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 20 Aug 2014 12:20:43 +0300
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAPeieQGzrdH3bFoKHL0OPvkPa6TcTKK5TVHNASKr3+hUrxUYwQ@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAPeieQGzrdH3bFoKHL0OPvkPa6TcTKK5TVHNASKr3+hUrxUYwQ@mail.gmail.com>
Message-ID: <CAKA2JgLF56-mw1ge_uuCa-NFY7UZB=O+dK6NaHjfKuK-JSBkbA@mail.gmail.com>

On Wed, Aug 20, 2014 at 12:15 PM, Erik Hesselink <hesselink at gmail.com>
wrote:

> On Wed, Aug 20, 2014 at 10:35 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
> >
> > On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
> > wrote:
> >>
> >> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
> >> wrote:
> >>>
> >>> As I understood, the question was if GHC would first compare pointers,
> >>> and only call the Eq instance if the pointers are not equal. I guess
> >>> this would be safe, but I don't think GHC does such a thing.
> >>
> >> I think the reason it isn't done is that it's not always an
> optimization.
> >> We do it manually in e.g. bytestring.
> >
> > There are two cases I can think of where it would also change the
> semantics
> > of the code:
> >
> > 1. An Eq instance that doesn't obey the reflective property (not
> > recommended):
> >
> > data BadEq = BadEq
> > instance Eq BadEq where
> >     BadEq == BadEq = False
>
> I think this is just a buggy instance, and if you do this, nothing is
> guaranteed. Many functions with an Eq constraint will also not work.
> Interestingly, reflexivity is not a law listed in the haddock
> documentation.
>
> Erik
>

I agree that this is terrible practice, and I hope no one is actually doing
this. It's unfortunate that reflexivity isn't listed in the Haddocks.
Perhaps we should start a separate proposal for making reflexivity an
officially required law of the Eq class.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/a8c013c2/attachment-0001.html>

From john at repetae.net  Wed Aug 20 09:46:42 2014
From: john at repetae.net (John Meacham)
Date: Wed, 20 Aug 2014 02:46:42 -0700
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
Message-ID: <CAM0WKeU7K3zwm3BFGvLCsvSMa26MCnLp=nvcBVT0WO4KmERwyg@mail.gmail.com>

Doing so would break the ability to optimize the language.

(5,_|_) == (5,_|_) should equal _|_, not true. even if they happened
to be represented by the same pointer. defining pointer equality would
enforce a specific evaluation model, which haskell specificially does
not do. doing so would kill most other optimizations and lead to a
very sloooow language as higher order transformations such as
deforestation are key to efficient haskell implementations no longer
be valid. It's unintuitive, but sometimes adding things that look like
local optimizations like this, actually hurt performance, a lot
because the higher order optimizations now have to avoid any situation
where they accidentally introduce a situation where this peephole
optimization exists.

I will admit, until I implemented a haskell compiler I was skeptical
too. but it is really the case. one step forward is sometimes ten
steps back.

    John

On Tue, Aug 19, 2014 at 11:52 PM, Johan Holmquist <holmisen at gmail.com> wrote:
> Comparing two structures for equality (structurally) can be expensive. But
> if their references are the same they would for sure be equal (unless (==)
> was defined in some funny way). Does GHC perform any such optimization?
>
> (Likely a question for another list but I make a stab here first. )
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
John Meacham - http://notanumber.net/

From lambda.fairy at gmail.com  Wed Aug 20 09:59:42 2014
From: lambda.fairy at gmail.com (Chris Wong)
Date: Wed, 20 Aug 2014 21:59:42 +1200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAKA2JgLF56-mw1ge_uuCa-NFY7UZB=O+dK6NaHjfKuK-JSBkbA@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAPeieQGzrdH3bFoKHL0OPvkPa6TcTKK5TVHNASKr3+hUrxUYwQ@mail.gmail.com>
 <CAKA2JgLF56-mw1ge_uuCa-NFY7UZB=O+dK6NaHjfKuK-JSBkbA@mail.gmail.com>
Message-ID: <CANQO64LBQppaxqTJiKcCksE-gZDkqaXh9JmSrQjkrQ_bs-7bDw@mail.gmail.com>

On Wed, Aug 20, 2014 at 9:20 PM, Michael Snoyman <michael at snoyman.com> wrote:
>
>
>
> On Wed, Aug 20, 2014 at 12:15 PM, Erik Hesselink <hesselink at gmail.com>
> wrote:
>>
>> On Wed, Aug 20, 2014 at 10:35 AM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>> >
>> > On Wed, Aug 20, 2014 at 11:28 AM, Johan Tibell <johan.tibell at gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Aug 20, 2014 at 10:23 AM, Erik Hesselink <hesselink at gmail.com>
>> >> wrote:
>> >>>
>> >>> As I understood, the question was if GHC would first compare pointers,
>> >>> and only call the Eq instance if the pointers are not equal. I guess
>> >>> this would be safe, but I don't think GHC does such a thing.
>> >>
>> >> I think the reason it isn't done is that it's not always an
>> >> optimization.
>> >> We do it manually in e.g. bytestring.
>> >
>> > There are two cases I can think of where it would also change the
>> > semantics
>> > of the code:
>> >
>> > 1. An Eq instance that doesn't obey the reflective property (not
>> > recommended):
>> >
>> > data BadEq = BadEq
>> > instance Eq BadEq where
>> >     BadEq == BadEq = False
>>
>> I think this is just a buggy instance, and if you do this, nothing is
>> guaranteed. Many functions with an Eq constraint will also not work.
>> Interestingly, reflexivity is not a law listed in the haddock
>> documentation.
>>
>> Erik
>
>
> I agree that this is terrible practice, and I hope no one is actually doing
> this. It's unfortunate that reflexivity isn't listed in the Haddocks.
> Perhaps we should start a separate proposal for making reflexivity an
> officially required law of the Eq class.
>
> Michael

The problem with requiring reflexivity (or *any* law related to
Eq/Ord, for that matter) is that Double and Float break it.

Observe:

    ghci> let nan = 0.0 / 0.0 in nan == nan
    False

Rust[1] side-steps this issue by having separate Eq (lawful) and
PartialEq (unlawful) classes, but it's a pretty intrusive change.

Chris

[1] http://doc.rust-lang.org/core/cmp/trait.PartialEq.html

From alexander.kjeldaas at gmail.com  Wed Aug 20 12:17:46 2014
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Wed, 20 Aug 2014 14:17:46 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAK-tuPahzsVxyvHE+96=SosBt5X4=U3XARTkpj=6AEGH6wFtog@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
 <CAK-tuPahzsVxyvHE+96=SosBt5X4=U3XARTkpj=6AEGH6wFtog@mail.gmail.com>
Message-ID: <CAHVSqQfUSjVKYvYa2vQYmMvVxqEcttCfvEoKMRXReBZYaJaQPw@mail.gmail.com>

On Wed, Aug 20, 2014 at 11:20 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> On Wed, Aug 20, 2014 at 11:05 AM, Johan Holmquist <holmisen at gmail.com>
> wrote:
>
>> > I think the reason it isn't done is that it's not always an optimization
>>
>> Could you explain when it's not?
>>
>
> A simple example is when the two values aren't equal, as you'll be doing
> one more branch than you otherwise would.
>

True


>  The extra branch might also hurt the branch predictor even in the equal
> case, if the branch is hard to predict.
>
>
This cost I think we can completely eliminate.  If the pointer comparison
is done only for an Eq instance that is statically known to execute N
instructions, then as as long as the cost of all subsequent branch
mispredictions are less than N, then we win, always.

Alexander


> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/0c20f1ad/attachment.html>

From alexander.kjeldaas at gmail.com  Wed Aug 20 12:36:27 2014
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Wed, 20 Aug 2014 14:36:27 +0200
Subject: [Haskell-cafe] Locking of threads in one OS thread
In-Reply-To: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
Message-ID: <CAHVSqQdF3DM+uHq1n6HGa1+sJYoa0ryaNapjkDHkPp5ZS+Ka1w@mail.gmail.com>

On Tue, Aug 19, 2014 at 11:36 PM, Nikolay Amiantov <nikoamia at gmail.com>
wrote:

> Hello Cafe,
>
> I'm using FFI to interact with a library which calls, when fail, leave
> the reason in some kind of "errno"-like variable which is retrived via
> another call. AFAIU, this is not thread-safe in Haskell even if
> thread-local storage is used inside the library, because Haskell uses
> its own thread management and the Haskell thread in the same OS thread
> might be switched between the actual call and the retrival of errno
> value.


Good question!


> This should be somehow handled already in Haskell (errno is
> widely used with syscalls in Linux, for example), but the source of
> Foreign.C.Error suggests that this is not handled in any way at all.
> For example, throwErrnoIf is implemented as such:
>
> throwErrno loc  = do
>     errno <- getErrno
>     ioError (errnoToIOError loc errno Nothing Nothing)
>
> throwErrnoIf pred loc f  = do
>     res <- f
>     if pred res then throwErrno loc else return res
>
> So, the question is: how is it ensured that this block is "atomic" in
> sense that at most one Haskell thread computes this whole function at
> every moment in every OS thread?
>
>
I do not know the RTS very well, but I think this might be unsafe.  If the
thread is *bound*, then *getErrno* is guaranteed to be executed on the same
thread, but otherwise no such guarantee is given.

However, reading http://blog.ezyang.com/2013/01/the-ghc-scheduler/ it might
be unlikely.

If GC happens, "Threads are put in *front* (pushOnRunQueue) if: ... In the
threaded runtime, if a thread was interrupted because another Capability
needed to do a stop-the-world GC (see commit 6d18141d8);"

However, the same post indicates that you can force this behavior using
signals.

"Threads are put in *back* (appendToRunQueue) in the case of pre-emption,
or if it?s new; particularly, if: ...A thread was pre-empted via the
context switch flag (e.g. incoming message from another thread, the timer
fired, the thread cooperatively yielded, etc; see also [8] on how this
interacts with heap overflows);"

Reading errno directly after the FFI call can eliminate heap overflows, but
the async exception and timer issues still seem possible.

I would also like to see a good explanation of this.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/8c0d1de7/attachment.html>

From johan.tibell at gmail.com  Wed Aug 20 12:39:54 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 20 Aug 2014 14:39:54 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAHVSqQfUSjVKYvYa2vQYmMvVxqEcttCfvEoKMRXReBZYaJaQPw@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CAJHA+wox3yf8Qns9ijC3gR1NKUJZWJa81wa17YeP661WT4nLkw@mail.gmail.com>
 <CAPeieQFGtY7M2pF6j77-5EDEibo45DxHRrt-dVacPiNoQXjA7g@mail.gmail.com>
 <CAK-tuPb0K0eYLEhUoFPtaEc-snbU1rQaOZfD3mGfK59o8LJO-A@mail.gmail.com>
 <CAKA2JgJ4XOoTvB6ADY9CUfwfc5_a4tyxGGE7esJT+KgxvOYC_Q@mail.gmail.com>
 <CAB_cSPf1t3uD9g=a+VHeHYEoi8_N6QhzY3SyV3YvrBRj7+4_ig@mail.gmail.com>
 <CAK-tuPahzsVxyvHE+96=SosBt5X4=U3XARTkpj=6AEGH6wFtog@mail.gmail.com>
 <CAHVSqQfUSjVKYvYa2vQYmMvVxqEcttCfvEoKMRXReBZYaJaQPw@mail.gmail.com>
Message-ID: <CAK-tuPb-p5U2qigaC9rNw33D6Y2r_BZ1OU6VPYkdD07j0q7saA@mail.gmail.com>

On Wed, Aug 20, 2014 at 2:17 PM, Alexander Kjeldaas <
alexander.kjeldaas at gmail.com> wrote:

> On Wed, Aug 20, 2014 at 11:20 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> The extra branch might also hurt the branch predictor even in the equal
>> case, if the branch is hard to predict.
>>
>
>>
> This cost I think we can completely eliminate.  If the pointer comparison
> is done only for an Eq instance that is statically known to execute N
> instructions, then as as long as the cost of all subsequent branch
> mispredictions are less than N, then we win, always.
>

The cost for branch prediction is typically known (per CPU model), but it's
not clear to me that we can know how much cost we're adding vs removing.
For example, consider Eq on pairs (a, b), in a use case where

 * 'a' rarely varies (and hence Eq on 'a' is easy to predict) and
 * 'b' is essentially random (and thus hard to predict).

In that case the code generated for ptr@(a, b) == ptr2(a2, b2)

if a == a2  -- we will predict correctly most of the time.
  then if b == b2 then ... else ...
  else ...  -- this case is cheap

is easy to predict (because 'a' is easy to predict). However the code for
the pointer-based Eq is not

if ptr == ptr2  -- we will predict this incorrectly most of the time, due
to the whole pair rarely being equal.
  then
    if a == a2
      then if b == b2 then ... else ...
      else ...
  else ...

However, more importantly adding extra branches can often get in the way of
other low-level optimizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/b3ca8433/attachment.html>

From holmisen at gmail.com  Wed Aug 20 13:16:03 2014
From: holmisen at gmail.com (Johan Holmquist)
Date: Wed, 20 Aug 2014 15:16:03 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
Message-ID: <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>

To summarise, the points raised sofar against this optimisation are,
roughly, as follows.


* More expensive to compare two values which aren't equal.

I think the potential gain of the optimisation might outweigh the cost in
the general case.

(Also, the optimisation would not have to be triggered for simple values
like Char, Int and Double.)


* Dodgy Eq instances may break the optimisation

But may also break other stuff and should be avoided anyway.


* _|_ will not necessarily yield _|_ on comparison

This seems the biggest problem sofar to me, that (5,_|_) == (5,_|_) would
be _|_ if both pairs where at different memory locations and True
otherwise. But perhaps not a big deal in practice.


* Disrupts other compiler optimisation opportunities

My knowledge about compilers is lacking so I cannot comment this.


Interesting that this was implemented by hbc. Would be nice to know if it
led to problems.



2014-08-20 14:32 GMT+02:00 Jan-Willem Maessen <jmaessen at alum.mit.edu>:

> On Wed, Aug 20, 2014 at 2:52 AM, Johan Holmquist <holmisen at gmail.com>
> wrote:
>
>> Comparing two structures for equality (structurally) can be expensive.
>> But if their references are the same they would for sure be equal (unless
>> (==) was defined in some funny way). Does GHC perform any such optimization?
>>
>
> The big problem in practice are the Float / Double instances in the
> presence of NaN, as noted by other folks.
>
> Back in the day, hbc had a flag that would do a pointer equality check in
> the derived Eq instances it generated before falling back to a traversal.
>  Interestingly, it does actually change the way you think about programming
> when you're working with multiple values that are very likely to share
> sub-structure.  Suddenly it seems OK to do equality checks as you traverse
> (because most of them will succeed), which would be O(n^2) if you weren't
> doing the pointer test.
>
> -Jan-Willem Maessen
>
>
>> (Likely a question for another list but I make a stab here first. )
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/6b4b7fdb/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Aug 20 13:24:50 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 20 Aug 2014 14:24:50 +0100
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
Message-ID: <20140820132450.GE22084@weber>

On Wed, Aug 20, 2014 at 03:16:03PM +0200, Johan Holmquist wrote:
> This seems the biggest problem sofar to me, that (5,_|_) == (5,_|_) would
> be _|_ if both pairs where at different memory locations and True
> otherwise. But perhaps not a big deal in practice.

This sounds like a big deal.

    f () = (5, undefined)

    -- crashes
    -- (common subexpression elimination optimization my lead to True)
    let x = f ()
        y = f ()
    in x == y

    -- True
    let x = f ()
        y = x
    in x == y

This isn't the sort of behaviour I'd like from my programming language.

Tom

From iusty at k1024.org  Wed Aug 20 15:14:00 2014
From: iusty at k1024.org (Iustin Pop)
Date: Wed, 20 Aug 2014 08:14:00 -0700
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
Message-ID: <20140820151400.GB6731@teal.hq.k1024.org>

On Wed, Aug 20, 2014 at 03:16:03PM +0200, Johan Holmquist wrote:
> To summarise, the points raised sofar against this optimisation are,
> roughly, as follows.

I think a different aspect of this is: what are you trying to optimise?
What code do you have where equality tests are a significant part of the
workload?

regards,
iustin

From ekmett at gmail.com  Wed Aug 20 15:48:26 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 20 Aug 2014 11:48:26 -0400
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <20140820151400.GB6731@teal.hq.k1024.org>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
 <20140820151400.GB6731@teal.hq.k1024.org>
Message-ID: <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>

I wanted this too when I first got into Haskell, but ultimately it comes
down to not being semantically correct here.

NaN /= NaN, so referential equality of anything that might ever compare
inside two NaN's doesn't imply value equality.

e.g. Anything with a polymorphic field can't use this.

You can argue that that was a bad call, but it was the expected call under
IEEE semantics.

If you wanted to bubble up some kind of extra 'reflexive :: a -> Bool'
through the Eq instance, then the tricky part is that determining if you
can use this can be as bad as doing the full tree comparison for
pathological cases you can construct and can introduce bottoms where there
previously were none if you do it naively.

You also start getting weird cases where things turn into Heisenbugs. this
== that would terminate before you evaluate this or that, but if you
evaluate one or the other then sometimes it works.

-Edward



On Wed, Aug 20, 2014 at 11:14 AM, Iustin Pop <iusty at k1024.org> wrote:

> On Wed, Aug 20, 2014 at 03:16:03PM +0200, Johan Holmquist wrote:
> > To summarise, the points raised sofar against this optimisation are,
> > roughly, as follows.
>
> I think a different aspect of this is: what are you trying to optimise?
> What code do you have where equality tests are a significant part of the
> workload?
>
> regards,
> iustin
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/85c7c668/attachment.html>

From holmisen at gmail.com  Wed Aug 20 16:33:06 2014
From: holmisen at gmail.com (Johan Holmquist)
Date: Wed, 20 Aug 2014 18:33:06 +0200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
 <20140820151400.GB6731@teal.hq.k1024.org>
 <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
Message-ID: <CAB_cSPfhQ4hNi+VvLE-dA4XrMr=kL4T-bm0sTHiZBZ1hnL0FDw@mail.gmail.com>

> I think a different aspect of this is: what are you trying to optimise?

Well, what led me to ask about this was not a particular problem but more
the thought that such an optimisation might perhaps be possible and maybe
already implemented. And if not, why.

If such an optimisation was not to ruin things it could be nice to have.
One simple example is the list. The time it takes to establish that two
lists are equal is linear to the number of elements. To establish if they
are not equal requires only to find one differing element. When dealing
with shared sub structures (sub lists in this case) this could matter a lot.

A nice effect is that we could then even establish equality for infinite
lists when they are the same.

> I wanted this too when I first got into Haskell, but ultimately it comes
down to not being semantically correct here.

Except for the floating points it would appear that most problems are
caused by _|_ some way or another.



2014-08-20 17:48 GMT+02:00 Edward Kmett <ekmett at gmail.com>:

> I wanted this too when I first got into Haskell, but ultimately it comes
> down to not being semantically correct here.
>
> NaN /= NaN, so referential equality of anything that might ever compare
> inside two NaN's doesn't imply value equality.
>
> e.g. Anything with a polymorphic field can't use this.
>
> You can argue that that was a bad call, but it was the expected call under
> IEEE semantics.
>
> If you wanted to bubble up some kind of extra 'reflexive :: a -> Bool'
> through the Eq instance, then the tricky part is that determining if you
> can use this can be as bad as doing the full tree comparison for
> pathological cases you can construct and can introduce bottoms where there
> previously were none if you do it naively.
>
> You also start getting weird cases where things turn into Heisenbugs. this
> == that would terminate before you evaluate this or that, but if you
> evaluate one or the other then sometimes it works.
>
> -Edward
>
>
>
> On Wed, Aug 20, 2014 at 11:14 AM, Iustin Pop <iusty at k1024.org> wrote:
>
>> On Wed, Aug 20, 2014 at 03:16:03PM +0200, Johan Holmquist wrote:
>> > To summarise, the points raised sofar against this optimisation are,
>> > roughly, as follows.
>>
>> I think a different aspect of this is: what are you trying to optimise?
>> What code do you have where equality tests are a significant part of the
>> workload?
>>
>> regards,
>> iustin
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/f8fa548e/attachment.html>

From barak at cs.nuim.ie  Wed Aug 20 20:45:23 2014
From: barak at cs.nuim.ie (Barak A. Pearlmutter)
Date: Wed, 20 Aug 2014 21:45:23 +0100
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
Message-ID: <CANa01BJUdS6gR=PbNXiaPFyWJ=aYJ+8Docsw7BDMgoBpgjoTDA@mail.gmail.com>

You don't need to define a new weird datatype in order to violate
reflexivity, as an eminent IEEE committee has already designed one for
you.

Prelude> let x = 0/0 in x == x
False

From ker0sin at ya.ru  Thu Aug 21 00:24:05 2014
From: ker0sin at ya.ru (Alexander Pakhomov)
Date: Thu, 21 Aug 2014 04:24:05 +0400
Subject: [Haskell-cafe]  Vector  sort poor performance
Message-ID: <724491408580645@web14g.yandex.ru>

Hi!

I've got dramatically low sort performamce: about 2 us of time and 5 kB of allocation
for unpacked vector of 4 (four) Double.

Code:
import Data.List
import Control.Monad
import Control.Monad.ST
import qualified Data.Vector.Unboxed as V
import qualified Data.Vector.Unboxed.Mutable as MV
import qualified Data.Vector.Algorithms.Intro as Intro
import Data.IORef

arr = V.fromList ([1,2] :: [Double])
foo x = V.head q
    where
        q = runST $ do
            res <- V.unsafeThaw $ V.concat
                [ V.map (\e -> e + x) arr 
                , V.map (\e -> e - x) arr]
            Intro.sort res 
            V.unsafeFreeze res 

main = do
    ref <- newIORef 0
    forM_ [0..100000] $! \i -> do
        modifyIORef' ref (+(foo $ fromInteger i)) -- for foo not to optimize out
    readIORef ref >>= print

ghc -O2 sort.hs && time ./sort 
[1 of 1] Compiling Main             ( sort.hs, sort.o )
Linking sort ...
-4.999949999e9

real    0m0.189s
user    0m0.184s
sys     0m0.000s

Does anybody know what's going on?

From ok at cs.otago.ac.nz  Thu Aug 21 00:55:10 2014
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Thu, 21 Aug 2014 12:55:10 +1200
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
 <20140820151400.GB6731@teal.hq.k1024.org>
 <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
Message-ID: <8AADBE16-500C-4423-B45E-62E54BFBF2A8@cs.otago.ac.nz>


On 21/08/2014, at 3:48 AM, Edward Kmett wrote:

> I wanted this too when I first got into Haskell, but ultimately it comes down to not being semantically correct here.
> 
> NaN /= NaN, so referential equality of anything that might ever compare inside two NaN's doesn't imply value equality. 
> 
> e.g. Anything with a polymorphic field can't use this.
> 
> You can argue that that was a bad call, but it was the expected call under IEEE semantics.

If I recall correctly, Prolog handles this by saying that
there is 'unification' and 'arithmetic comparison'
and NaN = NaN is true but NaN =:= NaN is false.

One way to handle this in a revised prelude would be
to have
   class MaybeEq a
     where equalIfPossible :: a -> a -> Maybe Bool
   class (MaybeEq a) => MaybeOrd a
     where compareIfPossible :: a -> a -> Maybe Order
     and then a bunch of IEEE-like operations, e.g.,
      x =? y if x = y or x,y are not comparable
      x =! y if x = y

   instance Eq t => MaybeEq t
     where equalIfPossible x y = Just (x == y)
   instance Ord t => MaybeOrd t
     where compareIfPossible x y = Just (compare x y)

and to move Double and Float to MaybeEq and MaybeOrd instead
of Eq and Ord, and support deriving (MaybeEq,MaybeOrd) in the
obvious way.

Then there could be a debate about whether to allow
instance Eq Double
  where x == y = if isNaN x then isNaN y else
                 case equalIfPossible x y of
                   Just True -> True
                   _         -> False
or not.



From john at repetae.net  Thu Aug 21 01:19:26 2014
From: john at repetae.net (John Meacham)
Date: Wed, 20 Aug 2014 18:19:26 -0700
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <8AADBE16-500C-4423-B45E-62E54BFBF2A8@cs.otago.ac.nz>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
 <20140820151400.GB6731@teal.hq.k1024.org>
 <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
 <8AADBE16-500C-4423-B45E-62E54BFBF2A8@cs.otago.ac.nz>
Message-ID: <CAM0WKeVNTM8HX+dQHxdkHBADbRLUhyoxDjoOH5gHD3mOB=RXtw@mail.gmail.com>

What you are discussing is "observable sharing". It breaks things
quite dramatically. Among other things, rather important optimizations
such as inlining are no longer valid if you allow it and reasoning
about efficiency goes right out the window.

It is possible to do safely without breaking things when done in the IO Monad,

import System.Mem.StableName
sameThing :: a -> a -> IO a
sameThing x y = liftM2 (==) (makeStableName x) (makeStableName y)

But whether it does what you expect after optimizations is
questionable and would likely behave differently under different
compilers.

    John


On Wed, Aug 20, 2014 at 5:55 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
>
> On 21/08/2014, at 3:48 AM, Edward Kmett wrote:
>
>> I wanted this too when I first got into Haskell, but ultimately it comes down to not being semantically correct here.
>>
>> NaN /= NaN, so referential equality of anything that might ever compare inside two NaN's doesn't imply value equality.
>>
>> e.g. Anything with a polymorphic field can't use this.
>>
>> You can argue that that was a bad call, but it was the expected call under IEEE semantics.
>
> If I recall correctly, Prolog handles this by saying that
> there is 'unification' and 'arithmetic comparison'
> and NaN = NaN is true but NaN =:= NaN is false.
>
> One way to handle this in a revised prelude would be
> to have
>    class MaybeEq a
>      where equalIfPossible :: a -> a -> Maybe Bool
>    class (MaybeEq a) => MaybeOrd a
>      where compareIfPossible :: a -> a -> Maybe Order
>      and then a bunch of IEEE-like operations, e.g.,
>       x =? y if x = y or x,y are not comparable
>       x =! y if x = y
>
>    instance Eq t => MaybeEq t
>      where equalIfPossible x y = Just (x == y)
>    instance Ord t => MaybeOrd t
>      where compareIfPossible x y = Just (compare x y)
>
> and to move Double and Float to MaybeEq and MaybeOrd instead
> of Eq and Ord, and support deriving (MaybeEq,MaybeOrd) in the
> obvious way.
>
> Then there could be a debate about whether to allow
> instance Eq Double
>   where x == y = if isNaN x then isNaN y else
>                  case equalIfPossible x y of
>                    Just True -> True
>                    _         -> False
> or not.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
John Meacham - http://notanumber.net/

From dstcruz at gmail.com  Thu Aug 21 04:20:27 2014
From: dstcruz at gmail.com (Daniel Santa Cruz)
Date: Wed, 20 Aug 2014 22:20:27 -0600
Subject: [Haskell-cafe] Haskell Weekly News: Issue 302
Message-ID: <CA+V-9CwgNqm=SCn0gHH9OeHjxGQLvrjDw8cOd_gmDQPdFCdXCg@mail.gmail.com>

Welcome to issue 302 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers
from August 3 to 16, 2014

Quotes of the Week

   * alpha123: I don't think I have the gonads for monads. :(

   * edwardk: There is nothing Natural about a Word.

   * bernalex: I very often have to deal with people who think
            I'm pretentious for caring about what programming
       language I use. "it's just programming". lol.
     sopvop: I used to think the same
     sopvop: Then haskell corrupted me
     sopvop: Haskell is a ghetto

Top Reddit Stories

   * ?_? :: String -> a
     Domain: hackage.haskell.org, Score: 122, Comments: 56
     Original: [1] http://goo.gl/S87evt
     On Reddit: [2] http://goo.gl/vsfwgr

   * An inspiring Haskell story: the green screen of FP
     Domain: keera.co.uk, Score: 120, Comments: 13
     Original: [3] http://goo.gl/z8Aecw
     On Reddit: [4] http://goo.gl/fevzzz

   * Haskell Platform 2014.2.0.0 is released
     Domain: haskell.org, Score: 117, Comments: 56
     Original: [5] http://goo.gl/Wc6TAF
     On Reddit: [6] http://goo.gl/hMPM7F

   * criterion 1.0: a major new release
     Domain: serpentine.com, Score: 110, Comments: 13
     Original: [7] http://goo.gl/7Qf3ox
     On Reddit: [8] http://goo.gl/Pa9fCW

   * What?s a module system good for anyway?
     Domain: blog.ezyang.com, Score: 102, Comments: 20
     Original: [9] http://goo.gl/qtm97E
     On Reddit: [10] http://goo.gl/XlWrM2

   * Easy Haskell Profiling
     Domain: danielvelkov.blogspot.com, Score: 83, Comments: 33
     Original: [11] http://goo.gl/SWdxdC
     On Reddit: [12] http://goo.gl/z6clxp

   * Type Theory Podcast: Peter Dybjer on QuickCheck, verification,
     and semantics
     Domain: typetheorypodcast.com, Score: 57, Comments: 21
     Original: [13] http://goo.gl/jN12Ak
     On Reddit: [14] http://goo.gl/tLVPpw

   * Fantasy World Haskell
     Domain: self.haskell, Score: 52, Comments: 165
     Original: [15] http://goo.gl/UmJLhG
     On Reddit: [16] http://goo.gl/UmJLhG

   * Haskell for all: managed-1.0.0: A monad for managed resources
     Domain: haskellforall.com, Score: 51, Comments: 10
     Original: [17] http://goo.gl/tbw8JN
     On Reddit: [18] http://goo.gl/cKB6xZ

   * Announcing auto-update
     Domain: yesodweb.com, Score: 47, Comments: 4
     Original: [19] http://goo.gl/xhlw04
     On Reddit: [20] http://goo.gl/GO6udg

   * Codeworld: An open-source educational programming environment
     using Haskell
     Domain: github.com, Score: 47, Comments: 8
     Original: [21] http://goo.gl/7NTgnF
     On Reddit: [22] http://goo.gl/wJBgw5

   * PureScript By Example
     Domain: leanpub.com, Score: 46, Comments: 25
     Original: [23] http://goo.gl/vzcfP6
     On Reddit: [24] http://goo.gl/p3gkEB

   * Lenses from the ground up
     Domain: taylor.fausak.me, Score: 45, Comments: 43
     Original: [25] http://goo.gl/S31V8w
     On Reddit: [26] http://goo.gl/DAGBPz

   * Algebraic Terraforming: Trees from Magma
     Domain: fpcomplete.com, Score: 42, Comments: 22
     Original: [27] http://goo.gl/1nGpnz
     On Reddit: [28] http://goo.gl/iX8ZST

   * Denotational Design: from meanings to programs By Conal Elliott
     at BayHac (Video)
     Domain: youtube.com, Score: 42, Comments: 5
     Original: [29] http://goo.gl/rHeDrK
     On Reddit: [30] http://goo.gl/SLCZ5D

   * Just LOOK at the humongous type that Hindley-Milner infers for
     this tiny program!
     Domain: spacemanaki.com, Score: 38, Comments: 27
     Original: [31] http://goo.gl/cAypnJ
     On Reddit: [32] http://goo.gl/ztDpK7

   * Recommended Reading Material
     Domain: reinh.com, Score: 37, Comments: 12
     Original: [33] http://goo.gl/LwGkEr
     On Reddit: [34] http://goo.gl/ED5pqI

   * (Monoidal) transducers are monoid homomorphisms
     Domain: oleksandrmanzyuk.wordpress.com, Score: 37, Comments: 43
     Original: [35] http://goo.gl/VPDl6Y
     On Reddit: [36] http://goo.gl/5RY9Nf

   * ? Lessons: Pattern matching, first-class functions, and abstracting
     over recursion in Haskell
     Domain: stevekrouse.github.io, Score: 36, Comments: 3
     Original: [37] http://goo.gl/NkxhS5
     On Reddit: [38] http://goo.gl/4275GH

Top StackOverflow Questions

   * What are the problems with an ADT encoding that associates types with
     data constructors? (Such as Scala.)
     votes: 41, answers: 1
     Read on SO: [39] http://goo.gl/k4bw4R

   * Why is Haskell missing ?obvious? Typeclasses
     votes: 26, answers: 7
     Read on SO: [40] http://goo.gl/2YElO8

   * Is there a way to elegantly represent this pattern in Haskell?
     votes: 22, answers: 6
     Read on SO: [41] http://goo.gl/sQdRMt

   * Why does Scala not have a return/unit function defined for each monad
     (in contrast to Haskell)?
     votes: 16, answers: 4
     Read on SO: [42] http://goo.gl/MQlZTi

   * How did Haskell add Turing-completeness to System F?
     votes: 15, answers: 1
     Read on SO: [43] http://goo.gl/weJo4Z

   * How to avoid superfluous variables in do notation?
     votes: 14, answers: 2
     Read on SO: [44] http://goo.gl/b3IgC5

Until next time,
[45]+Daniel Santa Cruz

References

   1.
https://hackage.haskell.org/package/acme-lookofdisapproval-0.1/docs/Acme-LookOfDisapproval.html
   2.
http://www.reddit.com/r/haskell/comments/2dce3d/%E0%B2%A0_%E0%B2%A0_string_a/
   3.
http://keera.co.uk/blog/2014/08/13/most-inspiring-green-screen-you-will-ever-see/
   4.
http://www.reddit.com/r/haskell/comments/2djh3b/an_inspiring_haskell_story_the_green_screen_of_fp/
   5. http://www.haskell.org/platform/#2014.2.0.0
   6.
http://www.reddit.com/r/haskell/comments/2d3p2c/haskell_platform_2014200_is_released/
   7. http://www.serpentine.com/blog/2014/08/08/criterion-1-0/
   8.
http://www.reddit.com/r/haskell/comments/2cyuv4/criterion_10_a_major_new_release/
   9. http://blog.ezyang.com/2014/08/whats-a-module-system-good-for-anyway/
  10.
http://www.reddit.com/r/haskell/comments/2d3xuh/whats_a_module_system_good_for_anyway/
  11. http://danielvelkov.blogspot.com/2014/08/easy-haskell-profiling.html
  12.
http://www.reddit.com/r/haskell/comments/2d8ob4/easy_haskell_profiling/
  13.
http://typetheorypodcast.com/2014/08/episode-1-peter-dybjer-on-type-theory-and-testing/
  14.
http://www.reddit.com/r/haskell/comments/2df24l/type_theory_podcast_peter_dybjer_on_quickcheck/
  15. http://www.reddit.com/r/haskell/comments/2chb2h/fantasy_world_haskell/
  16. http://www.reddit.com/r/haskell/comments/2chb2h/fantasy_world_haskell/
  17.
http://www.haskellforall.com/2014/08/managed-100-monad-for-managed-resources.html
  18.
http://www.reddit.com/r/haskell/comments/2d7109/haskell_for_all_managed100_a_monad_for_managed/
  19. http://www.yesodweb.com/blog/2014/08/announcing-auto-update
  20. http://www.reddit.com/r/haskell/comments/2crqyg/announcing_autoupdate/
  21. https://github.com/google/codeworld
  22.
http://www.reddit.com/r/haskell/comments/2drcwx/codeworld_an_opensource_educational_programming/
  23. https://leanpub.com/purescript/read
  24. http://www.reddit.com/r/haskell/comments/2cswdd/purescript_by_example/
  25. http://taylor.fausak.me/2014/08/03/lenses-from-the-ground-up/
  26.
http://www.reddit.com/r/haskell/comments/2cl28r/lenses_from_the_ground_up/
  27. https://www.fpcomplete.com/user/bss/magma-tree
  28.
http://www.reddit.com/r/haskell/comments/2corq6/algebraic_terraforming_trees_from_magma/
  29. https://www.youtube.com/watch?v=zzCrZEil9iI
  30.
http://www.reddit.com/r/haskell/comments/2dh0sd/denotational_design_from_meanings_to_programs_by/
  31.
http://spacemanaki.com/blog/2014/08/04/Just-LOOK-at-the-humongous-type/
  32.
http://www.reddit.com/r/haskell/comments/2cka6d/just_look_at_the_humongous_type_that/
  33.
http://reinh.com/notes/posts/2014-07-25-recommended-reading-material.html
  34.
http://www.reddit.com/r/haskell/comments/2cpr4z/recommended_reading_material/
  35.
http://oleksandrmanzyuk.wordpress.com/2014/08/09/transducers-are-monoid-homomorphisms/
  36.
http://www.reddit.com/r/haskell/comments/2d5ael/monoidal_transducers_are_monoid_homomorphisms/
  37. https://stevekrouse.github.io/hs.js/
  38.
http://www.reddit.com/r/haskell/comments/2d1dpg/%CE%BB_lessons_pattern_matching_firstclass_functions/
  39.
http://stackoverflow.com/questions/25330359/what-are-the-problems-with-an-adt-encoding-that-associates-types-with-data-const
  40.
http://stackoverflow.com/questions/25191659/why-is-haskell-missing-obvious-typeclasses
  41.
http://stackoverflow.com/questions/25107101/is-there-a-way-to-elegantly-represent-this-pattern-in-haskell
  42.
http://stackoverflow.com/questions/25238622/why-does-scala-not-have-a-return-unit-function-defined-for-each-monad-in-contra
  43.
http://stackoverflow.com/questions/25255413/how-did-haskell-add-turing-completeness-to-system-f
  44.
http://stackoverflow.com/questions/25314793/how-to-avoid-superfluous-variables-in-do-notation
  45. https://plus.google.com/105107667630152149014/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140820/68fedc89/attachment-0001.html>

From felipe.lessa at gmail.com  Thu Aug 21 05:00:55 2014
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Thu, 21 Aug 2014 02:00:55 -0300
Subject: [Haskell-cafe] Vector  sort poor performance
In-Reply-To: <724491408580645@web14g.yandex.ru>
References: <724491408580645@web14g.yandex.ru>
Message-ID: <53F57D07.30002@gmail.com>

On 20-08-2014 21:24, Alexander Pakhomov wrote:
>     ref <- newIORef 0
>     forM_ [0..100000] $! \i -> do
>         modifyIORef' ref (+(foo $ fromInteger i)) -- for foo not to optimize out
>     readIORef ref >>= print
> 
> ghc -O2 sort.hs && time ./sort 

My first recommendation is to use criterion.  It will get you a way
better idea of the timing needed for your function, specially since it
does not do much work.

Cheers,

-- 
Felipe.

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

From magicloud.magiclouds at gmail.com  Thu Aug 21 06:36:52 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Thu, 21 Aug 2014 14:36:52 +0800
Subject: [Haskell-cafe] Why this existential type could not work?
Message-ID: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>

Hi,

  For example, code like this:

newtype Sealed = Sealed { unSealed :: forall a. SomeClass a => TVar a }

mkSealed :: (SomeClass a) => a -> IO Sealed
mkSealed = fmap Sealed . newTVarIO

  When compiling, I would get:

Expected type: a -> IO (forall a1. SomeClass a1 => TVar a1)
Actual type: a -> IO (TVar a)

  How to correctly restrict type parameter a here?

-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/61e13364/attachment.html>

From dominique.devriese at cs.kuleuven.be  Thu Aug 21 06:47:58 2014
From: dominique.devriese at cs.kuleuven.be (Dominique Devriese)
Date: Thu, 21 Aug 2014 08:47:58 +0200
Subject: [Haskell-cafe] Why this existential type could not work?
In-Reply-To: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
References: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
Message-ID: <CAML5wvtkF=R-TMCADY7UCEUyzD3cDwxeBiQTYLowMhvFKZsnZw@mail.gmail.com>

Dear Magicloud,

What you're writing is not an existential type.  The syntax you used
meant that Sealed wraps a value of type "forall a. SomeClass a => TVar
a", while you wanted to say that it should contain a value of type
"TVar a" for some a that satisfies SomeClass, i.e. an existential
type. Below is what I think you want:

Regards,
Dominique

  {-# LANGUAGE RankNTypes, GADTs #-}

  module Test where

  import GHC.Conc

  class SomeClass a

  data Sealed where
    Sealed :: forall a. SomeClass a => TVar a -> Sealed

  mkSealed :: (SomeClass a) => a -> IO Sealed
  mkSealed = fmap Sealed . newTVarIO


2014-08-21 8:36 GMT+02:00 Magicloud Magiclouds <magicloud.magiclouds at gmail.com>:
> Hi,
>
>   For example, code like this:
>
> newtype Sealed = Sealed { unSealed :: forall a. SomeClass a => TVar a }
>
> mkSealed :: (SomeClass a) => a -> IO Sealed
> mkSealed = fmap Sealed . newTVarIO
>
>   When compiling, I would get:
>
> Expected type: a -> IO (forall a1. SomeClass a1 => TVar a1)
> Actual type: a -> IO (TVar a)
>
>   How to correctly restrict type parameter a here?
>
> --
> ???????
> ???????
>
> And for G+, please use magiclouds#gmail.com.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From magicloud.magiclouds at gmail.com  Thu Aug 21 07:08:52 2014
From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds)
Date: Thu, 21 Aug 2014 15:08:52 +0800
Subject: [Haskell-cafe] Why this existential type could not work?
In-Reply-To: <CAML5wvtkF=R-TMCADY7UCEUyzD3cDwxeBiQTYLowMhvFKZsnZw@mail.gmail.com>
References: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
 <CAML5wvtkF=R-TMCADY7UCEUyzD3cDwxeBiQTYLowMhvFKZsnZw@mail.gmail.com>
Message-ID: <CABErt4e+V1Sn+w33U-0AMGy5VvGqy=4jnFh4kizuqK7QsXYUFg@mail.gmail.com>

Thank you. I think I need to understand the different means of forall when
it at different positions.


On Thu, Aug 21, 2014 at 2:47 PM, Dominique Devriese <
dominique.devriese at cs.kuleuven.be> wrote:

> Dear Magicloud,
>
> What you're writing is not an existential type.  The syntax you used
> meant that Sealed wraps a value of type "forall a. SomeClass a => TVar
> a", while you wanted to say that it should contain a value of type
> "TVar a" for some a that satisfies SomeClass, i.e. an existential
> type. Below is what I think you want:
>
> Regards,
> Dominique
>
>   {-# LANGUAGE RankNTypes, GADTs #-}
>
>   module Test where
>
>   import GHC.Conc
>
>   class SomeClass a
>
>   data Sealed where
>     Sealed :: forall a. SomeClass a => TVar a -> Sealed
>
>   mkSealed :: (SomeClass a) => a -> IO Sealed
>   mkSealed = fmap Sealed . newTVarIO
>
>
> 2014-08-21 8:36 GMT+02:00 Magicloud Magiclouds <
> magicloud.magiclouds at gmail.com>:
> > Hi,
> >
> >   For example, code like this:
> >
> > newtype Sealed = Sealed { unSealed :: forall a. SomeClass a => TVar a }
> >
> > mkSealed :: (SomeClass a) => a -> IO Sealed
> > mkSealed = fmap Sealed . newTVarIO
> >
> >   When compiling, I would get:
> >
> > Expected type: a -> IO (forall a1. SomeClass a1 => TVar a1)
> > Actual type: a -> IO (TVar a)
> >
> >   How to correctly restrict type parameter a here?
> >
> > --
> > ???????
> > ???????
> >
> > And for G+, please use magiclouds#gmail.com.
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>



-- 
???????
???????

And for G+, please use magiclouds#gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/1652a443/attachment.html>

From p.stephani2 at gmail.com  Thu Aug 21 07:51:54 2014
From: p.stephani2 at gmail.com (Philipp Stephani)
Date: Thu, 21 Aug 2014 07:51:54 +0000
Subject: [Haskell-cafe] Why this existential type could not work?
References: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
Message-ID: <CAArVCkRyRXcZU8xesO-PV8cQRf7Op28NWYNVLQ7FOgGKQs3HkQ@mail.gmail.com>

Magicloud Magiclouds <magicloud.magiclouds at gmail.com> schrieb am Thu Aug 21
2014 at 08:37:09:

> Hi,
>
>   For example, code like this:
>
> newtype Sealed = Sealed { unSealed :: forall a. SomeClass a => TVar a }
>

I think this should be written as

data Sealed = forall a. SomeClass a => Sealed { unSealed :: TVar a }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/0a0e5629/attachment.html>

From ker0sin at ya.ru  Thu Aug 21 10:20:38 2014
From: ker0sin at ya.ru (Alexander Pakhomov)
Date: Thu, 21 Aug 2014 14:20:38 +0400
Subject: [Haskell-cafe] Vector  sort poor performance
In-Reply-To: <53F57D07.30002@gmail.com>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
Message-ID: <2349901408616438@web19g.yandex.ru>

1) The problem is not a measurement. The whole foo function a bottleneck in my program.
2) Change Vector.Algorithms.Intro.sort to List.sort improves performance 2-3x, remove sort improves performance 30x
C++ is 30x faster on this task. That's strange, because using Vector.Mutable.Unboxed should provide good performance.
And C++ spends all time in vector allocation. With on stack dynamic array it is 400 times faster.
3) Anyway Criterion measurement is 1.6 us (different machine)

Measurement code is:

import Data.List
import Control.Monad
import Control.Monad.ST
import qualified Data.Vector.Unboxed as V
import qualified Data.Vector.Unboxed.Mutable as MV
import qualified Data.Vector.Algorithms.Intro as Intro
import Data.IORef
import Criterion.Main

arr = V.fromList ([1,2] :: [Double])
foo x = V.head q
    where
        q = runST $ do
            res <- V.unsafeThaw $ V.concat
                [ V.map (\e -> e + x) arr
                , V.map (\e -> e - x) arr]
            Intro.sort res
            V.unsafeFreeze res

main = do
    ref <- newIORef 0
    defaultMain [
        bgroup "sort" [ bench "10" $ whnf foo 10]]


21.08.2014, 09:01, "Felipe Lessa" <felipe.lessa at gmail.com>:
> On 20-08-2014 21:24, Alexander Pakhomov wrote:
>> ?????ref <- newIORef 0
>> ?????forM_ [0..100000] $! \i -> do
>> ?????????modifyIORef' ref (+(foo $ fromInteger i)) -- for foo not to optimize out
>> ?????readIORef ref >>= print
>>
>> ?ghc -O2 sort.hs && time ./sort
>
> My first recommendation is to use criterion. ?It will get you a way
> better idea of the timing needed for your function, specially since it
> does not do much work.
>
> Cheers,
>
> --
> Felipe.
>
> ,
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From sven.bartscher at weltraumschlangen.de  Thu Aug 21 11:56:02 2014
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Thu, 21 Aug 2014 13:56:02 +0200
Subject: [Haskell-cafe] Taking over setlocale
In-Reply-To: <53BDD8F2.2030208@gmail.com>
References: <20140709233335.1d65dffb@sven.bartscher>
 <CAHYVw0yMRUh0Xr8zLs40hCEVyqoXM8JGWrCQq+j-oKz_iHyvMA@mail.gmail.com>
 <53BDD8F2.2030208@gmail.com>
Message-ID: <20140821135602.25725d6c@sven.bartscher>

On Wed, 09 Jul 2014 20:06:10 -0400
Gershom Bazerman <gershomb at gmail.com> wrote:

> On 7/9/14, 5:56 PM, Carter Schonwald wrote:
> The guideline there is "a reasonable time". That is much closer to 1 
> month than 6-12 months. I think one week is a bit short, but overall 
> sven seems to be following the process well, and given the last update 
> date on that package, we should still give a reasonable time to respond, 
> but I would err on the side of brevity if anything.

Greetings,

It's now longer than a months ago, that I send the first post about
this.
I think this is a reasonable time to respond for the maintainer.
Are there still any objections or can I now contact
admin at hackage.debian.org?

Regards
Sven

> >
> > On Wed, Jul 9, 2014 at 5:33 PM, Sven Bartscher 
> > <sven.bartscher at weltraumschlangen.de 
> > <mailto:sven.bartscher at weltraumschlangen.de>> wrote:
> >
> >     Greetings,
> >
> >     I would like to take over the setlocale package. Following the steps
> >     described on
> >     http://www.haskell.org/haskellwiki/Taking_over_a_package I
> >     need to state my intention on a public forum.
> >
> >     The original author (Lukas Mai) published his package in the Public
> >     Domain. This would be fine, but the Author seems to be living in
> >     Germany. The problem with that is that in Germany an author is not
> >     allowed to give up his copyright in this way. This means the licensing
> >     of the package defaults to "All rights reserved", making the package
> >     undistributable.
> >
> >     I already tried to contact the author about this problem, but he
> >     didn't
> >     respond in a week. This isn't a very long time, but I didn't get an
> >     answer on past attempts to contact him (this was at least a month, but
> >     probably more, ago).
> >
> >     To solve this problem, I rewrote the setlocale binding with the
> >     same API
> >     under the BSD3-clause.
> >
> >     PS: Please keep the CC to Lukas Mai and the debian-haskell list
> >         intact.
> >
> >     Regards
> >     Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/bb23d405/attachment.sig>

From felipe.lessa at gmail.com  Thu Aug 21 14:22:15 2014
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Thu, 21 Aug 2014 11:22:15 -0300
Subject: [Haskell-cafe] Vector  sort poor performance
In-Reply-To: <2349901408616438@web19g.yandex.ru>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
 <2349901408616438@web19g.yandex.ru>
Message-ID: <53F60097.3040006@gmail.com>

I've added a few more variants to your test code (see below) and I'm not
sure what to think.  Especially if you look at Optimal.sort4ByOffset's
source code, it makes no sense that it would take so much time.  So my
hypothesis is that most of the time is spent on the `compare` calls.

If you take a look at the generated core, sort4ByOffset is not inlined,
let alone sort4ByIndex.  Also, none of these two have SPECIALIZE pragmas
for Doubles (or anything else for that matter).  GHC is then calling the
function with a reference to `compare`, which transforms a few CPU
cycles into a function call that constructs a value which is then
immediately deconstructed.

I suggest that you add a few SPECIALIZE pragmas to vector-algorithms and
check its performance again.


{-# LANGUAGE Rank2Types #-}
import Control.Monad
import Control.Monad.ST
import qualified Data.Vector.Unboxed as V
import qualified Data.Vector.Unboxed.Mutable as MV
import qualified Data.Vector.Algorithms.Heap as Heap
import qualified Data.Vector.Algorithms.Insertion as Insertion
import qualified Data.Vector.Algorithms.Intro as Intro
import qualified Data.Vector.Algorithms.Merge as Merge
import qualified Data.Vector.Algorithms.Optimal as Optimal
import qualified Data.Vector.Algorithms.Radix as Radix
import Data.IORef
import Criterion.Main

type Value = Double

arr = V.fromList ([1,2] :: [Value])

foo :: (forall s. V.MVector s Value -> ST s ()) -> Value -> Value
foo f x = V.head q
  where
    q = runST $ do
      res <- V.unsafeThaw $ V.concat
        [ V.map (\e -> e + x) arr
        , V.map (\e -> e - x) arr]
      f res
      V.unsafeFreeze res

main = do
  ref <- newIORef 0
  defaultMain
    [ b "--nothing--" (const $ return ())
    , b "--best--" best
    , b "Heap" Heap.sort
    , b "Insertion" Insertion.sort
    , b "Intro" Intro.sort
    , b "Merge" Merge.sort
    , b "Optimal" (\v -> Optimal.sort4ByOffset compare v 0) ]
  where
    b :: String -> (forall s. V.MVector s Value -> ST s ()) -> Benchmark
    b s f = bgroup s [ bench "10" $ whnf (foo f) 10 ]

    best :: forall s. V.MVector s Value -> ST s ()
    best res = do
      -- [ 11, 12, -9, -8 ]
      MV.swap res 0 2
      -- [ -9, 12, 11, -8 ]
      MV.swap res 1 3
      -- [ -9, -8, 11, 12 ]

-- 
Felipe.

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

From felipe.lessa at gmail.com  Thu Aug 21 14:31:57 2014
From: felipe.lessa at gmail.com (Felipe Lessa)
Date: Thu, 21 Aug 2014 11:31:57 -0300
Subject: [Haskell-cafe] Vector  sort poor performance
In-Reply-To: <53F60097.3040006@gmail.com>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
 <2349901408616438@web19g.yandex.ru> <53F60097.3040006@gmail.com>
Message-ID: <53F602DD.1080201@gmail.com>

On 21-08-2014 11:22, Felipe Lessa wrote:
> I suggest that you add a few SPECIALIZE pragmas to vector-algorithms and
> check its performance again.

Scratch that, I remembered that one may just copy & paste :).

Here's the code and criterion results:
https://gist.github.com/meteficha/1acef6dc1e1ed81b63ae

This is the relevant part:

benchmarking --nothing--/10
time 151.5 ns (151.2 ns .. 151.8 ns)
1.000 R? (1.000 R? .. 1.000 R?)
mean 151.8 ns (151.6 ns .. 152.1 ns)
std dev 868.8 ps (732.4 ps .. 1.030 ns)

benchmarking --best--/10
time 157.4 ns (157.1 ns .. 157.7 ns)
1.000 R? (1.000 R? .. 1.000 R?)
mean 157.1 ns (156.6 ns .. 157.4 ns)
std dev 1.297 ns (786.7 ps .. 2.366 ns)

benchmarking Optimal/10
time 1.173 ?s (1.168 ?s .. 1.180 ?s)
1.000 R? (1.000 R? .. 1.000 R?)
mean 1.194 ?s (1.187 ?s .. 1.204 ?s)
std dev 27.45 ns (22.18 ns .. 36.34 ns)
variance introduced by outliers: 29% (moderately inflated)

benchmarking Optimal'/10
time 157.7 ns (157.5 ns .. 158.0 ns)
1.000 R? (1.000 R? .. 1.000 R?)
mean 157.8 ns (157.5 ns .. 158.2 ns)
std dev 1.178 ns (872.4 ps .. 1.965 ns)

Optimal', which is a copy of Optimal, takes almost the same as --best--,
which does no comparisons at all!

So vector-algorithms really needs either to force INLINE (leading to
code size bloat) or sprinkle SPECIALIZE pragmas everywhere.  I suggest
contacting the package's maintainer to see what their thoughts are on
this matter.

Cheers,

-- 
Felipe.

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

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Thu Aug 21 14:34:26 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 21 Aug 2014 15:34:26 +0100
Subject: [Haskell-cafe] Does GHC compare pointers when eval'ing (==)
In-Reply-To: <CAM0WKeVNTM8HX+dQHxdkHBADbRLUhyoxDjoOH5gHD3mOB=RXtw@mail.gmail.com>
References: <CAB_cSPfC_9LFqWQXY3D9A6fB6CfaOCbj++JNdKPKgkUx9Jj3GA@mail.gmail.com>
 <CANs0n6wizOvqgvg=v+uUGCK8cYywCDayz9bXvJgY9J-jpQmkSg@mail.gmail.com>
 <CAB_cSPdSFPc6u8Kz_eaTkpKAk1S_j3R067g2NS7Mvkr1ruG1zQ@mail.gmail.com>
 <20140820151400.GB6731@teal.hq.k1024.org>
 <CAJumaK9w7zqcCnUiqOWjPyj5Bzu+BiLLxty_hf+WLbLLcTUq1Q@mail.gmail.com>
 <8AADBE16-500C-4423-B45E-62E54BFBF2A8@cs.otago.ac.nz>
 <CAM0WKeVNTM8HX+dQHxdkHBADbRLUhyoxDjoOH5gHD3mOB=RXtw@mail.gmail.com>
Message-ID: <20140821143426.GJ22084@weber>

On Wed, Aug 20, 2014 at 06:19:26PM -0700, John Meacham wrote:
> It is possible to do safely without breaking things when done in the IO Monad,
> 
> import System.Mem.StableName
> sameThing :: a -> a -> IO a
> sameThing x y = liftM2 (==) (makeStableName x) (makeStableName y)

I don't think this has the behaviour that Johan (the OP) wants.


import System.Mem.StableName
import Control.Monad

sameThing :: a -> a -> IO Bool
sameThing x y = liftM2 (==) (makeStableName x) (makeStableName y)

main = do
  let x = 1
      y = x
  print =<< sameThing x y
  print =<< sameThing x x

GHCi> main
False
True


I suspect Johan wants "True; True".

Tom

From ker0sin at ya.ru  Thu Aug 21 22:51:55 2014
From: ker0sin at ya.ru (Alexander Pakhomov)
Date: Fri, 22 Aug 2014 02:51:55 +0400
Subject: [Haskell-cafe] Vector  sort poor performance
In-Reply-To: <53F602DD.1080201@gmail.com>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
 <2349901408616438@web19g.yandex.ru> <53F60097.3040006@gmail.com>
 <53F602DD.1080201@gmail.com>
Message-ID: <4395171408661515@web8j.yandex.ru>

Hi Feilpe,

Which GHC version do you use?
With 7.6.3 I have all the same BUT Optimal'/10 260 ns. It's better than 1200 ns
but still bad. Also there are INLINEs everywhere at vector-algorithms.
Seems to be compiler problem.

21.08.2014, 18:32, "Felipe Lessa" <felipe.lessa at gmail.com>:
> On 21-08-2014 11:22, Felipe Lessa wrote:
>> ?I suggest that you add a few SPECIALIZE pragmas to vector-algorithms and
>> ?check its performance again.
>
> Scratch that, I remembered that one may just copy & paste :).
>
> Here's the code and criterion results:
> https://gist.github.com/meteficha/1acef6dc1e1ed81b63ae
>
> This is the relevant part:
>
> benchmarking --nothing--/10
> time 151.5 ns (151.2 ns .. 151.8 ns)
> 1.000 R? (1.000 R? .. 1.000 R?)
> mean 151.8 ns (151.6 ns .. 152.1 ns)
> std dev 868.8 ps (732.4 ps .. 1.030 ns)
>
> benchmarking --best--/10
> time 157.4 ns (157.1 ns .. 157.7 ns)
> 1.000 R? (1.000 R? .. 1.000 R?)
> mean 157.1 ns (156.6 ns .. 157.4 ns)
> std dev 1.297 ns (786.7 ps .. 2.366 ns)
>
> benchmarking Optimal/10
> time 1.173 ?s (1.168 ?s .. 1.180 ?s)
> 1.000 R? (1.000 R? .. 1.000 R?)
> mean 1.194 ?s (1.187 ?s .. 1.204 ?s)
> std dev 27.45 ns (22.18 ns .. 36.34 ns)
> variance introduced by outliers: 29% (moderately inflated)
>
> benchmarking Optimal'/10
> time 157.7 ns (157.5 ns .. 158.0 ns)
> 1.000 R? (1.000 R? .. 1.000 R?)
> mean 157.8 ns (157.5 ns .. 158.2 ns)
> std dev 1.178 ns (872.4 ps .. 1.965 ns)
>
> Optimal', which is a copy of Optimal, takes almost the same as --best--,
> which does no comparisons at all!
>
> So vector-algorithms really needs either to force INLINE (leading to
> code size bloat) or sprinkle SPECIALIZE pragmas everywhere. ?I suggest
> contacting the package's maintainer to see what their thoughts are on
> this matter.
>
> Cheers,
>
> --
> Felipe.

From bos at serpentine.com  Thu Aug 21 23:18:23 2014
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Thu, 21 Aug 2014 16:18:23 -0700
Subject: [Haskell-cafe] Vector sort poor performance
In-Reply-To: <4395171408661515@web8j.yandex.ru>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
 <2349901408616438@web19g.yandex.ru> <53F60097.3040006@gmail.com>
 <53F602DD.1080201@gmail.com> <4395171408661515@web8j.yandex.ru>
Message-ID: <CACw0niL2k6_y2QtGmhMpPAcoZYVmcffp1am62i4Ft52wP-ukmg@mail.gmail.com>

On Thu, Aug 21, 2014 at 3:51 PM, Alexander Pakhomov <ker0sin at ya.ru> wrote:

> Which GHC version do you use?
> With 7.6.3 I have all the same BUT Optimal'/10 260 ns. It's better than
> 1200 ns
> but still bad. Also there are INLINEs everywhere at vector-algorithms.
> Seems to be compiler problem.
>

There's a lot of sensitivity in the compiler to exactly how and which rules
are specified. I already brought up this regression with Dan a few weeks
ago, and we didn't come up with a good way to deal with it. I don't think
it's quite fair to call it a compiler problem, so much as just a change
that caused a previously-good-but-fragile behaviour to now not be so good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/150d116c/attachment.html>

From efsubenovex at gmail.com  Fri Aug 22 04:33:50 2014
From: efsubenovex at gmail.com (Schell Scivally)
Date: Thu, 21 Aug 2014 21:33:50 -0700
Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage.
Message-ID: <CA+11MeACA+JncKyk_8xdOP3EudKBMrzcHEaGwkONU3L2GDU-Pg@mail.gmail.com>

Hi all, it seems that Bit Connor (the author of hdevtools -
https://github.com/bitc/hdevtools) has been MIA since January. There are a
number of pull requests that need to be merged and uploaded to hackage for
GHC 7.8. I tried contacting him last week through both emails listed on
hackage - one bounced and the other is unanswered. Has anyone seen/heard
from the author? I'd like to temporarily hijack hackage responsibilities
until we hear from him again in order to merge and upload these changes (
https://github.com/bitc/hdevtools/issues/24#ref-commit-a996411).

-- 
Schell Scivally | github <https://github.com/schell> | twitter
<http://twitter.com/schellsan> | blog <http://efnx.com> | wiki
<http://wiki.zyghost.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140821/853b206e/attachment.html>

From johan.tibell at gmail.com  Fri Aug 22 06:13:21 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 22 Aug 2014 08:13:21 +0200
Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage.
In-Reply-To: <CA+11MeACA+JncKyk_8xdOP3EudKBMrzcHEaGwkONU3L2GDU-Pg@mail.gmail.com>
References: <CA+11MeACA+JncKyk_8xdOP3EudKBMrzcHEaGwkONU3L2GDU-Pg@mail.gmail.com>
Message-ID: <CAK-tuPa2xAtrFg-wEcftRDr+2T+FRRUVpwurYUe5jNSzhgD+eg@mail.gmail.com>

Hi!

Please have a look at
http://www.haskell.org/haskellwiki/Taking_over_a_package.


On Fri, Aug 22, 2014 at 6:33 AM, Schell Scivally <efsubenovex at gmail.com>
wrote:

> Hi all, it seems that Bit Connor (the author of hdevtools -
> https://github.com/bitc/hdevtools) has been MIA since January. There are
> a number of pull requests that need to be merged and uploaded to hackage
> for GHC 7.8. I tried contacting him last week through both emails listed on
> hackage - one bounced and the other is unanswered. Has anyone seen/heard
> from the author? I'd like to temporarily hijack hackage responsibilities
> until we hear from him again in order to merge and upload these changes (
> https://github.com/bitc/hdevtools/issues/24#ref-commit-a996411).
>
> --
> Schell Scivally | github <https://github.com/schell> | twitter
> <http://twitter.com/schellsan> | blog <http://efnx.com> | wiki
>  <http://wiki.zyghost.com>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/e88ba8b8/attachment.html>

From bneijt at gmail.com  Fri Aug 22 16:49:22 2014
From: bneijt at gmail.com (Bram Neijt)
Date: Fri, 22 Aug 2014 18:49:22 +0200
Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal
Message-ID: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>

Dear reader,

I have a single executable package in Cabal[1] and I have added a test
for it using an example configuration from the ltc package[2].

With my test on my executable I can't depend on the main package, but
I seem to have to repeat the dependencies of my executable, or split
off functionality into a library. [3]

Can I easily depend on the dependencies of another package or should I
create a library  and depend on that in my test and executable?

All source is at: https://github.com/bneijt/after/

Greetings,

Bram

[1] https://github.com/bneijt/after/blob/master/after.cabal
[2] https://github.com/scvalex/ltc/blob/master/ltc.cabal
[3] A part of my cabal file added below

executable after
    main-is:            Main.hs
    build-depends:      base >=4.7 && <4.8,
                        options ==1.*,
                        directory ==1.2.*,
                        parallel-io ==0.3.*,
                        filepath ==1.3.*,
                        unix ==2.7.*
    hs-source-dirs:     src
    ghc-options:        -Wall
    default-language:   Haskell2010


test-suite afterTests
    hs-source-dirs:    test src
    main-is:           AfterTest.hs
    type:              exitcode-stdio-1.0
    build-depends:     base >=4.7 && <4.8,
                       unix ==2.7.*, -- Here because of after depending on it
                       directory ==1.2.*, -- Here because of after
depending on it
                       filepath ==1.3.*, -- Here because of after
depending on it
                       test-framework,
                       test-framework-hunit,
                       HUnit
    default-language:  Haskell2010

From tdammers at gmail.com  Fri Aug 22 17:03:09 2014
From: tdammers at gmail.com (Tobias Dammers)
Date: Fri, 22 Aug 2014 19:03:09 +0200
Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal
In-Reply-To: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>
References: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>
Message-ID: <CAK_X-ePVuJXKVRvUBg0Qumsmg2omysuMcbRom=_gqqp7J+39hA@mail.gmail.com>

I have found that splitting functionality off into a library is way too
useful for a lot of things anyway, so I'd just do that.
On Aug 22, 2014 6:49 PM, "Bram Neijt" <bneijt at gmail.com> wrote:

> Dear reader,
>
> I have a single executable package in Cabal[1] and I have added a test
> for it using an example configuration from the ltc package[2].
>
> With my test on my executable I can't depend on the main package, but
> I seem to have to repeat the dependencies of my executable, or split
> off functionality into a library. [3]
>
> Can I easily depend on the dependencies of another package or should I
> create a library  and depend on that in my test and executable?
>
> All source is at: https://github.com/bneijt/after/
>
> Greetings,
>
> Bram
>
> [1] https://github.com/bneijt/after/blob/master/after.cabal
> [2] https://github.com/scvalex/ltc/blob/master/ltc.cabal
> [3] A part of my cabal file added below
>
> executable after
>     main-is:            Main.hs
>     build-depends:      base >=4.7 && <4.8,
>                         options ==1.*,
>                         directory ==1.2.*,
>                         parallel-io ==0.3.*,
>                         filepath ==1.3.*,
>                         unix ==2.7.*
>     hs-source-dirs:     src
>     ghc-options:        -Wall
>     default-language:   Haskell2010
>
>
> test-suite afterTests
>     hs-source-dirs:    test src
>     main-is:           AfterTest.hs
>     type:              exitcode-stdio-1.0
>     build-depends:     base >=4.7 && <4.8,
>                        unix ==2.7.*, -- Here because of after depending on
> it
>                        directory ==1.2.*, -- Here because of after
> depending on it
>                        filepath ==1.3.*, -- Here because of after
> depending on it
>                        test-framework,
>                        test-framework-hunit,
>                        HUnit
>     default-language:  Haskell2010
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/7d1b1b72/attachment.html>

From trebla at vex.net  Fri Aug 22 17:08:15 2014
From: trebla at vex.net (Albert Y. C. Lai)
Date: Fri, 22 Aug 2014 13:08:15 -0400
Subject: [Haskell-cafe] Why this existential type could not work?
In-Reply-To: <CABErt4e+V1Sn+w33U-0AMGy5VvGqy=4jnFh4kizuqK7QsXYUFg@mail.gmail.com>
References: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
 <CAML5wvtkF=R-TMCADY7UCEUyzD3cDwxeBiQTYLowMhvFKZsnZw@mail.gmail.com>
 <CABErt4e+V1Sn+w33U-0AMGy5VvGqy=4jnFh4kizuqK7QsXYUFg@mail.gmail.com>
Message-ID: <53F778FF.6010200@vex.net>

On 14-08-21 03:08 AM, Magicloud Magiclouds wrote:
> Thank you. I think I need to understand the different means of forall
> when it at different positions.

Each value has a giver (aka creator, implementer) and a receiver (aka 
user, client).

It always and only comes down to: who chooses what to plug into the type 
variable, the giver or the receiver. Exactly one of the two can choose.


data Head = HC (forall b. Maybe b)

head_example :: Head
head_example = HC (...)

The receiver of head_example can choose what b is. The giver of 
head_example cannot choose.

How do I know? Because this is analogous to:

like_head_example :: forall b. Maybe b
like_head_example = ...

The giver of like_head_example cannot choose.


data Tail = forall b. TC (Maybe b)

tail_example :: Tail
tail_example = TC (...)

The giver of tail_example can choose what b is. The receiver cannot choose.

How do I know? Because the type of TC is

     TC :: forall b. Maybe b -> Tail

The user of TC can choose. The user of TC is the giver of tail_example.


Now I talk about parametricity. Parametricity implies: the person who 
cannot choose cannot ask either.

The giver of head_example cannot choose b. He/She cannot ask what is 
chosen either.

The receiver of tail_example cannot choose b. He/She cannot ask what is 
chosen either.

Non-generic Java lacks parametricity. Therefore, the person who cannot 
choose can still ask what is chosen by instanceOf.

Generic Java has parametricity. Like Haskell, the person who cannot 
choose cannot ask by instanceOf.

From dan.doel at gmail.com  Fri Aug 22 17:21:31 2014
From: dan.doel at gmail.com (Dan Doel)
Date: Fri, 22 Aug 2014 13:21:31 -0400
Subject: [Haskell-cafe] Vector sort poor performance
In-Reply-To: <CACw0niL2k6_y2QtGmhMpPAcoZYVmcffp1am62i4Ft52wP-ukmg@mail.gmail.com>
References: <724491408580645@web14g.yandex.ru> <53F57D07.30002@gmail.com>
 <2349901408616438@web19g.yandex.ru> <53F60097.3040006@gmail.com>
 <53F602DD.1080201@gmail.com> <4395171408661515@web8j.yandex.ru>
 <CACw0niL2k6_y2QtGmhMpPAcoZYVmcffp1am62i4Ft52wP-ukmg@mail.gmail.com>
Message-ID: <CAHEA9tMVs44K80jr8qyM-WxEh2nODn6FqTB98YqZh3creqqfoQ@mail.gmail.com>

To be more specific...

GHC used to inline the code you're exercising, which allows it to
specialize to the comparison function, which allows it to keep all the
numbers unboxed. But the current version of GHC doesn't do this, and if I
force it to inline, the compiler will just die with a 'simplifier ticks
exhausted' message.

I've been thinking about ways to avoid this situation, and have some ideas
(one of which would work for your use case). But I guess in the mean time I
should turn off use of these functions.


On Thu, Aug 21, 2014 at 7:18 PM, Bryan O'Sullivan <bos at serpentine.com>
wrote:

>
> On Thu, Aug 21, 2014 at 3:51 PM, Alexander Pakhomov <ker0sin at ya.ru> wrote:
>
>> Which GHC version do you use?
>> With 7.6.3 I have all the same BUT Optimal'/10 260 ns. It's better than
>> 1200 ns
>> but still bad. Also there are INLINEs everywhere at vector-algorithms.
>> Seems to be compiler problem.
>>
>
> There's a lot of sensitivity in the compiler to exactly how and which
> rules are specified. I already brought up this regression with Dan a few
> weeks ago, and we didn't come up with a good way to deal with it. I don't
> think it's quite fair to call it a compiler problem, so much as just a
> change that caused a previously-good-but-fragile behaviour to now not be so
> good.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/eaefb833/attachment.html>

From omari at smileystation.com  Fri Aug 22 17:22:43 2014
From: omari at smileystation.com (Omari Norman)
Date: Fri, 22 Aug 2014 13:22:43 -0400
Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal
In-Reply-To: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>
References: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>
Message-ID: <CAL2jp57_Be6YX8bqfyChu7=hjxaDQvKWA3t_E8QZHgC233e_vA@mail.gmail.com>

On Fri, Aug 22, 2014 at 12:49 PM, Bram Neijt <bneijt at gmail.com> wrote:

>
> Can I easily depend on the dependencies of another package or should I
> create a library  and depend on that in my test and executable?
>
>
There's no way to do what you're trying to do without putting your
functionality into a library.  Cabal then has a feature that allows you to
depend on the library in your executables and test suites.  Then you don't
repeat your library dependencies in your executables and test suites.

This feature has, however, some unresolved bugs:

https://github.com/haskell/cabal/issues/1919

so I wouldn't recommend its use unless you are willing to deal with some
bugs.  I would just gulp and deal with the duplication in your Cabal file
(and the longer compile times) or, alternatively, adopt a tool to deal
directly with the problem of duplication, such as:

https://hackage.haskell.org/package/cartel

But a tool like Cartel does nothing about compile times.  If compile times
are really a concern, I would just put the library in a completely separate
package and package the executables and tests separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/b934f79d/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Fri Aug 22 17:45:37 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Fri, 22 Aug 2014 18:45:37 +0100
Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal
In-Reply-To: <CAK_X-ePVuJXKVRvUBg0Qumsmg2omysuMcbRom=_gqqp7J+39hA@mail.gmail.com>
References: <CADS_YUxsJBOz_e5garKAhSLcggsOFzw4JV3BrdEcgu_icBETAA@mail.gmail.com>
 <CAK_X-ePVuJXKVRvUBg0Qumsmg2omysuMcbRom=_gqqp7J+39hA@mail.gmail.com>
Message-ID: <53F781C1.1060403@fuuzetsu.co.uk>

On 08/22/2014 06:03 PM, Tobias Dammers wrote:
> I have found that splitting functionality off into a library is way too
> useful for a lot of things anyway, so I'd just do that.
> On Aug 22, 2014 6:49 PM, "Bram Neijt" <bneijt at gmail.com> wrote:
> 
>> Dear reader,
>>
>> I have a single executable package in Cabal[1] and I have added a test
>> for it using an example configuration from the ltc package[2].
>>
>> With my test on my executable I can't depend on the main package, but
>> I seem to have to repeat the dependencies of my executable, or split
>> off functionality into a library. [3]
>>
>> Can I easily depend on the dependencies of another package or should I
>> create a library  and depend on that in my test and executable?
>>
>> All source is at: https://github.com/bneijt/after/
>>
>> Greetings,
>>
>> Bram
>> [snip]

+1 to this, just stick it into a library section. You can even have your
executable be just ?main = realMain? and everything else (including
realMain) in the library.

There's a benefit of someone being able to come along and go ?hey, this
program does these useful things, I sure could use some of them for my
own program? which is great.

-- 
Mateusz K.

From S.D.Swierstra at uu.nl  Fri Aug 22 21:40:49 2014
From: S.D.Swierstra at uu.nl (Swierstra, S.D.)
Date: Fri, 22 Aug 2014 21:40:49 +0000
Subject: [Haskell-cafe] Why this existential type could not work?
In-Reply-To: <CABErt4e+V1Sn+w33U-0AMGy5VvGqy=4jnFh4kizuqK7QsXYUFg@mail.gmail.com>
References: <CABErt4ek_-vxkBSZjEaNxfzLn7fRjqHbDU=OKX6ZF1jOHgdJsQ@mail.gmail.com>
 <CAML5wvtkF=R-TMCADY7UCEUyzD3cDwxeBiQTYLowMhvFKZsnZw@mail.gmail.com>
 <CABErt4e+V1Sn+w33U-0AMGy5VvGqy=4jnFh4kizuqK7QsXYUFg@mail.gmail.com>
Message-ID: <3FB8CB89-4EB8-42E4-A1D6-BC6B5ACCC2FC@uu.nl>


On 21 Aug 2014, at 9:08 , Magicloud Magiclouds <magicloud.magiclouds at gmail.com<mailto:magicloud.magiclouds at gmail.com>> wrote:

Thank you. I think I need to understand the different means of forall when it at different positions.

The forall in this case should be "pronounced" as "exists"; reusing the keyword forall was clearly an unfortunate decision.

When should either write:


  data Sealed where
    Sealed :: forall a. SomeClass a => TVar a -> Sealed


or

data Sealed = exists a . SomeClass a=>   Sealed (TVar a)

In the former notation the emphasis is on Sealed being used to construct a value, whereas in the second case the emphasis is more on its role as a constituent of a pattern.

    Doaitse




On Thu, Aug 21, 2014 at 2:47 PM, Dominique Devriese <dominique.devriese at cs.kuleuven.be<mailto:dominique.devriese at cs.kuleuven.be>> wrote:
Dear Magicloud,

What you're writing is not an existential type.  The syntax you used
meant that Sealed wraps a value of type "forall a. SomeClass a => TVar
a", while you wanted to say that it should contain a value of type
"TVar a" for some a that satisfies SomeClass, i.e. an existential
type. Below is what I think you want:

Regards,
Dominique

  {-# LANGUAGE RankNTypes, GADTs #-}

  module Test where

  import GHC.Conc

  class SomeClass a

  data Sealed where
    Sealed :: forall a. SomeClass a => TVar a -> Sealed

  mkSealed :: (SomeClass a) => a -> IO Sealed
  mkSealed = fmap Sealed . newTVarIO


2014-08-21 8:36 GMT+02:00 Magicloud Magiclouds <magicloud.magiclouds at gmail.com<mailto:magicloud.magiclouds at gmail.com>>:
> Hi,
>
>   For example, code like this:
>
> newtype Sealed = Sealed { unSealed :: forall a. SomeClass a => TVar a }
>
> mkSealed :: (SomeClass a) => a -> IO Sealed
> mkSealed = fmap Sealed . newTVarIO
>
>   When compiling, I would get:
>
> Expected type: a -> IO (forall a1. SomeClass a1 => TVar a1)
> Actual type: a -> IO (TVar a)
>
>   How to correctly restrict type parameter a here?
>
> --
> ???????
> ???????
>
> And for G+, please use magiclouds#gmail.com<http://gmail.com/>.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



--
???????
???????

And for G+, please use magiclouds#gmail.com<http://gmail.com/>.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org>
http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/2d7c39b3/attachment.html>

From sven.bartscher at weltraumschlangen.de  Fri Aug 22 22:38:14 2014
From: sven.bartscher at weltraumschlangen.de (Sven Bartscher)
Date: Sat, 23 Aug 2014 00:38:14 +0200
Subject: [Haskell-cafe] Unable to build a mingw cross compiler.
Message-ID: <20140823003814.21b7ddef@sven.bartscher>

Greetings,

I'm trying to build GHC to cross compile to windows.
GCC and friends are in /usr/bin/x86_64-w64-mingw32-*, libraries and
headers are in /usr/x86_64-w64-mingw32/{include,lib}.

I configured with:
./configure --target=x86_64-w64-mingw32 \
  --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc # Needed because
  					     # otherwise /usr/bin/gcc
  					     # would be used

Building fails with the following error:
utils/hsc2hs/dist/build/Main.o: In function `s2nI_info':
(.text+0x5c5): undefined reference to `GetModuleFileNameW'
collect2: error: ld returned 1 exit status

(The GHC invocation line is included in the attached file)

So it seems that GHC either uses the wrong linker or invokes it with
the wrong search path.
However, the configure script detects the right linker
(/usr/bin/x86_64-w64-mingw32).

Is this a bug, or a feature?

System data:
OS: Debian jessie Linux/GNU i386
Installed GHC (for bootstrapping): version 7.6.3
GHC I'm trying to build: version 7.8.3

Regards
Sven
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: error.txt
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/52d98cd1/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/52d98cd1/attachment.sig>

From efsubenovex at gmail.com  Sat Aug 23 06:06:11 2014
From: efsubenovex at gmail.com (Schell Scivally)
Date: Fri, 22 Aug 2014 23:06:11 -0700
Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage.
In-Reply-To: <CAK-tuPa2xAtrFg-wEcftRDr+2T+FRRUVpwurYUe5jNSzhgD+eg@mail.gmail.com>
References: <CA+11MeACA+JncKyk_8xdOP3EudKBMrzcHEaGwkONU3L2GDU-Pg@mail.gmail.com>
 <CAK-tuPa2xAtrFg-wEcftRDr+2T+FRRUVpwurYUe5jNSzhgD+eg@mail.gmail.com>
Message-ID: <CA+11MeC_qfSZe_CkRJ71_3D-HNo9NEfeLi-WZVEdfqfwa0RajQ@mail.gmail.com>

Hi Johan - thanks, this is the step where I message haskell-cafe and wait a
while ;)


On Thu, Aug 21, 2014 at 11:13 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Hi!
>
> Please have a look at
> http://www.haskell.org/haskellwiki/Taking_over_a_package.
>
>
> On Fri, Aug 22, 2014 at 6:33 AM, Schell Scivally <efsubenovex at gmail.com>
> wrote:
>
>> Hi all, it seems that Bit Connor (the author of hdevtools -
>> https://github.com/bitc/hdevtools) has been MIA since January. There are
>> a number of pull requests that need to be merged and uploaded to hackage
>> for GHC 7.8. I tried contacting him last week through both emails listed on
>> hackage - one bounced and the other is unanswered. Has anyone seen/heard
>> from the author? I'd like to temporarily hijack hackage responsibilities
>> until we hear from him again in order to merge and upload these changes (
>> https://github.com/bitc/hdevtools/issues/24#ref-commit-a996411).
>>
>> --
>> Schell Scivally | github <https://github.com/schell> | twitter
>> <http://twitter.com/schellsan> | blog <http://efnx.com> | wiki
>>  <http://wiki.zyghost.com>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
Schell Scivally | github <https://github.com/schell> | twitter
<http://twitter.com/schellsan> | blog <http://efnx.com> | wiki
<http://wiki.zyghost.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140822/9b1e72dd/attachment.html>

From konn.jinro at gmail.com  Sat Aug 23 10:04:56 2014
From: konn.jinro at gmail.com (Hiromi ISHII)
Date: Sat, 23 Aug 2014 19:04:56 +0900
Subject: [Haskell-cafe] How to add Haddock comment for standalone derived
	instances?
Message-ID: <F497E932-A889-4747-93A9-4AED7C588406@gmail.com>

Hi cafe,

Is there any way to add the documentation comment for the instances defined with StandaloneDeriving?

I'm currently defining data-type using GADTs and its Typeable instance.
Normally, this can be done only StandaloneDeriving and DeriveDataTypeable extensions:

> {-# LANGUAGE StandaloneDeriving, GADTs, DeriveDataTypeable #-}
> data Ordinal n where
>   OZ :: Ordinal (S n)
>   OS :: Ordinal n -> Ordinal (S n)
> 
> deriving instance Typeable Ordinal

I added `Typeable` instance for Ordinal recently, so I want to add some comments like "Since 0.2.3.0".
But any of the following doesn't work or, even worse, haddock won't compile:

* Just before `deriving instance` line using  `-- | `
* Just after `deriving` keyword but before `instance` using `-- | `
* Just after the `Typeable Ordinal`, but no newline in-between, with `-- ^ `
* The next line of `deriving` clause with `-- ^ `

Is there any way to add documentation for instances with standalone deriving, or it's just not supported yet?

-- Hiromi ISHII
konn.jinro at gmail.com




From marco-oweber at gmx.de  Sat Aug 23 10:42:08 2014
From: marco-oweber at gmx.de (Marc Weber)
Date: Sat, 23 Aug 2014 10:42:08 +0000
Subject: [Haskell-cafe] Set (Set a) like container - but more efficient?
Message-ID: <1408790268-sup-7146@nixos>

Does a Set (Set a) like container exist already but which is represented
as tree internally, eg

A
` - B - C
    ` - D
` - X - Y

which would represent ABC ABD and AXY ? If it does not what would be a
nice name to create such container?

Marc Weber

From ivan.miljenovic at gmail.com  Sat Aug 23 10:46:50 2014
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Sat, 23 Aug 2014 20:46:50 +1000
Subject: [Haskell-cafe] Set (Set a) like container - but more efficient?
In-Reply-To: <1408790268-sup-7146@nixos>
References: <1408790268-sup-7146@nixos>
Message-ID: <CA+u6gbxJVTSvEUAKdZ83wKS_FxYX1E1XrSJptPZVDK4tZ2AYrA@mail.gmail.com>

Sounds a bit like a Trie...

On 23 August 2014 20:42, Marc Weber <marco-oweber at gmx.de> wrote:
> Does a Set (Set a) like container exist already but which is represented
> as tree internally, eg
>
> A
> ` - B - C
>     ` - D
> ` - X - Y
>
> which would represent ABC ABD and AXY ? If it does not what would be a
> nice name to create such container?
>
> Marc Weber
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



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

From fuuzetsu at fuuzetsu.co.uk  Sat Aug 23 11:18:22 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 23 Aug 2014 12:18:22 +0100
Subject: [Haskell-cafe] How to add Haddock comment for standalone
 derived instances?
In-Reply-To: <F497E932-A889-4747-93A9-4AED7C588406@gmail.com>
References: <F497E932-A889-4747-93A9-4AED7C588406@gmail.com>
Message-ID: <53F8787E.5070903@fuuzetsu.co.uk>

On 08/23/2014 11:04 AM, Hiromi ISHII wrote:
> Hi cafe,
> 
> Is there any way to add the documentation comment for the instances defined with StandaloneDeriving?
> 
> I'm currently defining data-type using GADTs and its Typeable instance.
> Normally, this can be done only StandaloneDeriving and DeriveDataTypeable extensions:
> 
>> {-# LANGUAGE StandaloneDeriving, GADTs, DeriveDataTypeable #-}
>> data Ordinal n where
>>   OZ :: Ordinal (S n)
>>   OS :: Ordinal n -> Ordinal (S n)
>>
>> deriving instance Typeable Ordinal
> 
> I added `Typeable` instance for Ordinal recently, so I want to add some comments like "Since 0.2.3.0".
> But any of the following doesn't work or, even worse, haddock won't compile:
> 
> * Just before `deriving instance` line using  `-- | `
> * Just after `deriving` keyword but before `instance` using `-- | `
> * Just after the `Typeable Ordinal`, but no newline in-between, with `-- ^ `
> * The next line of `deriving` clause with `-- ^ `
> 
> Is there any way to add documentation for instances with standalone deriving, or it's just not supported yet?
> 
> -- Hiromi ISHII
> konn.jinro at gmail.com
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

I don't think there's support. Problem with these kind of issues is that
they have to be fixed in the GHC lexer + parser. Please open a GHC and
Haddock issue to track this if you want eventually want it to make it in.

-- 
Mateusz K.

From fuuzetsu at fuuzetsu.co.uk  Sat Aug 23 11:22:56 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 23 Aug 2014 12:22:56 +0100
Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage.
In-Reply-To: <CA+11MeC_qfSZe_CkRJ71_3D-HNo9NEfeLi-WZVEdfqfwa0RajQ@mail.gmail.com>
References: <CA+11MeACA+JncKyk_8xdOP3EudKBMrzcHEaGwkONU3L2GDU-Pg@mail.gmail.com>
 <CAK-tuPa2xAtrFg-wEcftRDr+2T+FRRUVpwurYUe5jNSzhgD+eg@mail.gmail.com>
 <CA+11MeC_qfSZe_CkRJ71_3D-HNo9NEfeLi-WZVEdfqfwa0RajQ@mail.gmail.com>
Message-ID: <53F87990.70105@fuuzetsu.co.uk>

On 08/23/2014 07:06 AM, Schell Scivally wrote:
> Hi Johan - thanks, this is the step where I message haskell-cafe and wait a
> while ;)
> 
> 
> On Thu, Aug 21, 2014 at 11:13 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> 
>> Hi!
>>
>> Please have a look at
>> http://www.haskell.org/haskellwiki/Taking_over_a_package.
>>
>>
>> On Fri, Aug 22, 2014 at 6:33 AM, Schell Scivally <efsubenovex at gmail.com>
>> wrote:
>>
>>> Hi all, it seems that Bit Connor (the author of hdevtools -
>>> https://github.com/bitc/hdevtools) has been MIA since January. There are
>>> a number of pull requests that need to be merged and uploaded to hackage
>>> for GHC 7.8. I tried contacting him last week through both emails listed on
>>> hackage - one bounced and the other is unanswered. Has anyone seen/heard
>>> from the author? I'd like to temporarily hijack hackage responsibilities
>>> until we hear from him again in order to merge and upload these changes (
>>> https://github.com/bitc/hdevtools/issues/24#ref-commit-a996411).
>>>
>>> --
>>> Schell Scivally | github <https://github.com/schell> | twitter
>>> <http://twitter.com/schellsan> | blog <http://efnx.com> | wiki
>>>  <http://wiki.zyghost.com>
>>>

CC'ing libraries@ is probably a good step.


-- 
Mateusz K.

From ducis_cn at 126.com  Sat Aug 23 14:24:36 2014
From: ducis_cn at 126.com (ducis)
Date: Sat, 23 Aug 2014 22:24:36 +0800 (CST)
Subject: [Haskell-cafe] How to write transform one set of ADTs to another
	with SYB?
In-Reply-To: <mailman.9.1408795204.8102.haskell-cafe@haskell.org>
References: <mailman.9.1408795204.8102.haskell-cafe@haskell.org>
Message-ID: <42512013.8d49.14803412e4c.Coremail.ducis_cn@126.com>

More specifically, I want to transform a tree of SomeExpr to a tree of (SomethingElse, SomeExpr), "prefixing" each node with a default value in the process.
The result have essentially the same structure as the input.

data ASTAttachment = AA {} deriving (Eq,Read,Show,Ord,Typeable,Data)
type family AST a :: *
type instance AST () = ASTExpr ()
type instance AST AA = (AA, ASTExpr AA)
data ASTExpr a
    = ALiteral String
    | AApplication [AST a] (ASTOp a)
    | ARef String
    | ABind (AST a) String
    | AMany (ASTMany a)
data ASTOp a
    = AOSym String
    | AOAlpha String
    | AOMany (ASTMany a)
data ASTMany a
    = AMSimple [AST a]
    | AMAggeregate [AST a]
deriving instance Typeable ASTMany
deriving instance Typeable ASTOp
deriving instance Typeable ASTExpr
deriving instance Data (ASTMany ())
deriving instance Data (ASTOp ())
deriving instance Data (ASTExpr ())

Currently I have values of type (AST ()),  and I need to transform them to (AST ASTAttachment) in the obvious way.
Now I'm stuck at "derive instance Data (ASTExpr ASTAttachment)", where ghc reports "Multiple declarations of '$cSomeConstructor'".
Even if I can get past this, I still don't know how to use SYB to transform between trees of different types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/8da12ac4/attachment.html>

From vogt.adam at gmail.com  Sat Aug 23 17:10:40 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Sat, 23 Aug 2014 13:10:40 -0400
Subject: [Haskell-cafe] How to write transform one set of ADTs to
 another with SYB?
In-Reply-To: <42512013.8d49.14803412e4c.Coremail.ducis_cn@126.com>
References: <mailman.9.1408795204.8102.haskell-cafe@haskell.org>
 <42512013.8d49.14803412e4c.Coremail.ducis_cn@126.com>
Message-ID: <CAHfjoWnmKRA0OLL3QDJTPOZPAwkmNVYoXLBT8vRqR0gR7Af9Vg@mail.gmail.com>

Hi Ducis,

Did you mean: "data AA = AA" when you write "data ASTAttachment = AA"?

In any case, you can write Data instances that cover (ASTExpr AA) and
(ASTExpr ()) with:

deriving instance (Data t, Data (AST t)) => Data (ASTMany t)
deriving instance (Data t, Data (AST t)) => Data (ASTOp t)
deriving instance (Data t, Data (AST t)) => Data (ASTExpr t)

As for writing a

f :: (Data (t AA), Data (t ())) => t () -> t AA

where t could be ASTExpr, it might help to look at the two options
here: http://www.haskell.org/haskellwiki/Scrap_your_boilerplate#fmap

Regards,
Adam

On Sat, Aug 23, 2014 at 10:24 AM, ducis <ducis_cn at 126.com> wrote:
> More specifically, I want to transform a tree of SomeExpr to a tree of
> (SomethingElse, SomeExpr), "prefixing" each node with a default value in the
> process.
> The result have essentially the same structure as the input.
>
> data ASTAttachment = AA {} deriving (Eq,Read,Show,Ord,Typeable,Data)
> type family AST a :: *
> type instance AST () = ASTExpr ()
> type instance AST AA = (AA, ASTExpr AA)
> data ASTExpr a
>     = ALiteral String
>     | AApplication [AST a] (ASTOp a)
>     | ARef String
>     | ABind (AST a) String
>     | AMany (ASTMany a)
> data ASTOp a
>     = AOSym String
>     | AOAlpha String
>     | AOMany (ASTMany a)
> data ASTMany a
>     = AMSimple [AST a]
>     | AMAggeregate [AST a]
> deriving instance Typeable ASTMany
> deriving instance Typeable ASTOp
> deriving instance Typeable ASTExpr
> deriving instance Data (ASTMany ())
> deriving instance Data (ASTOp ())
> deriving instance Data (ASTExpr ())
>
> Currently I have values of type (AST ()),  and I need to transform them to
> (AST ASTAttachment) in the obvious way.
> Now I'm stuck at "derive instance Data (ASTExpr ASTAttachment)", where ghc
> reports "Multiple declarations of '$cSomeConstructor'".
> Even if I can get past this, I still don't know how to use SYB to transform
> between trees of different types.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From eir at cis.upenn.edu  Sat Aug 23 18:36:19 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 23 Aug 2014 14:36:19 -0400
Subject: [Haskell-cafe] lightweight web interface for Haskell?
Message-ID: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>

Hi Cafe,

Does anyone know of a website where I can write a few lines of Haskell and have them run? Ideally, there would be a place to write a module and then a place to load the module into GHCi. I seem to recall something that fit my needs at paste.hskll.org, but that site is no longer working.

I'm asking because I'll be teaching an undergraduate course this fall in introductory Haskell. There are no prerequisites for the course, and my course roster suggests that I'll have several students with no programming background at all. (This is great, actually -- I love facilitating a new programmer's first steps!) It might be nice to get students off the ground quickly before bogging them down with installation details -- hence the website I'm looking for.

Thanks!
Richard

From michael at snoyman.com  Sat Aug 23 18:41:04 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Sat, 23 Aug 2014 21:41:04 +0300
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
Message-ID: <CAKA2JgJAnaTPzj6u7vVMu4C73W392g8Z4E7mX19X2TfsexzUtg@mail.gmail.com>

On Sat, Aug 23, 2014 at 9:36 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Hi Cafe,
>
> Does anyone know of a website where I can write a few lines of Haskell and
> have them run? Ideally, there would be a place to write a module and then a
> place to load the module into GHCi. I seem to recall something that fit my
> needs at paste.hskll.org, but that site is no longer working.
>
> I'm asking because I'll be teaching an undergraduate course this fall in
> introductory Haskell. There are no prerequisites for the course, and my
> course roster suggests that I'll have several students with no programming
> background at all. (This is great, actually -- I love facilitating a new
> programmer's first steps!) It might be nice to get students off the ground
> quickly before bogging them down with installation details -- hence the
> website I'm looking for.
>
> Thanks!
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


I'd recommend looking into FP Haskell Center[1], a full online Haskell IDE,
or just using School of Haskell[2] which allows running code, but doesn't
offer all IDE features (e.g., type information isn't present). Both are
freely available, though if you're going to recommend a number of users to
go onto the site at once, please give us a heads-up in advance so we can
boost the base number of servers and avoid any delays in spinning up an EC2
instance for the extra load.

Feel free to follow up privately if you have specific questions about how
this would work for a course, this wouldn't be the first time FPHC has been
used this way.

Michael

[1] https://www.fpcomplete.com/business/haskell-industry/
[2] https://www.fpcomplete.com/school
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/32b7dd8c/attachment.html>

From allbery.b at gmail.com  Sat Aug 23 18:41:46 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Aug 2014 14:41:46 -0400
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
Message-ID: <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>

On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Does anyone know of a website where I can write a few lines of Haskell and
> have them run?


http://ideone.com (ghc 7.6.3)
fpcomplete.com's online IDE has a free/community tier, although for this I
suspect you can't meet the ToS

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/a8590c40/attachment.html>

From tikhon at jelv.is  Sat Aug 23 18:43:03 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Sat, 23 Aug 2014 11:43:03 -0700
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
Message-ID: <CAJN5CV+_nQr6qjxdgdhdqP02H=-D72tEoQOi_969-USQORKC-w@mail.gmail.com>

Perhaps tryhaskell.org matches what you're looking for? It comes with an
interactive tutorial which might be a good place to start?or, if you want,
I'm sure you could use it to set up your own tutorial just by changing the
code. However, I think it's mainly interactive and doesn't support writing
and loading modules.

It's a shame that paste.hskll.org is down, especially because it had
support for the diagrams library.


On Sat, Aug 23, 2014 at 11:36 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Hi Cafe,
>
> Does anyone know of a website where I can write a few lines of Haskell and
> have them run? Ideally, there would be a place to write a module and then a
> place to load the module into GHCi. I seem to recall something that fit my
> needs at paste.hskll.org, but that site is no longer working.
>
> I'm asking because I'll be teaching an undergraduate course this fall in
> introductory Haskell. There are no prerequisites for the course, and my
> course roster suggests that I'll have several students with no programming
> background at all. (This is great, actually -- I love facilitating a new
> programmer's first steps!) It might be nice to get students off the ground
> quickly before bogging them down with installation details -- hence the
> website I'm looking for.
>
> Thanks!
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/8a399067/attachment.html>

From cma at bitemyapp.com  Sat Aug 23 18:48:15 2014
From: cma at bitemyapp.com (Christopher Allen)
Date: Sat, 23 Aug 2014 13:48:15 -0500
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
Message-ID: <CADnndOp+PpmW_oQpoULRD-51a_A9_s=gU2UVre-H_pbSPB_iQg@mail.gmail.com>

It's not perfect, but Chris Done's http://tryhaskell.org/ comes to mind.

There's also Google's (not officially endorsed) Codeworld:
https://github.com/google/codeworld http://www.codeworld.info/

Curious to see if anybody knows of any others.

Cheers,
Chris Allen



On Sat, Aug 23, 2014 at 1:36 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Hi Cafe,
>
> Does anyone know of a website where I can write a few lines of Haskell and
> have them run? Ideally, there would be a place to write a module and then a
> place to load the module into GHCi. I seem to recall something that fit my
> needs at paste.hskll.org, but that site is no longer working.
>
> I'm asking because I'll be teaching an undergraduate course this fall in
> introductory Haskell. There are no prerequisites for the course, and my
> course roster suggests that I'll have several students with no programming
> background at all. (This is great, actually -- I love facilitating a new
> programmer's first steps!) It might be nice to get students off the ground
> quickly before bogging them down with installation details -- hence the
> website I'm looking for.
>
> Thanks!
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140823/07797d57/attachment.html>

From stegeman at gmail.com  Sun Aug 24 12:19:46 2014
From: stegeman at gmail.com (Luite Stegeman)
Date: Sun, 24 Aug 2014 14:19:46 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <CAJN5CV+_nQr6qjxdgdhdqP02H=-D72tEoQOi_969-USQORKC-w@mail.gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAJN5CV+_nQr6qjxdgdhdqP02H=-D72tEoQOi_969-USQORKC-w@mail.gmail.com>
Message-ID: <CALqQuogFnevfZRSYbrAVnjmF+B8wS4cy8fBVOkavMHnT5Qpu+Q@mail.gmail.com>

On Sat, Aug 23, 2014 at 8:43 PM, Tikhon Jelvis <tikhon at jelv.is> wrote:

> Perhaps tryhaskell.org matches what you're looking for? It comes with an
> interactive tutorial which might be a good place to start?or, if you want,
> I'm sure you could use it to set up your own tutorial just by changing the
> code. However, I think it's mainly interactive and doesn't support writing
> and loading modules.
>
> It's a shame that paste.hskll.org is down, especially because it had
> support for the diagrams library.
>
>
I moved the service to a new machine because a hard drive in the old one
died, but unfortunately I had some trouble restarting the evaluation
service (it has to be started in some special way, in an SELinux sandbox).
I managed to get it up and running now.

Codeworld is quite cool, but unfortunately Chris' goal of teaching
programming with a simplified variant of Haskell might not align with the
course's goals of teaching Haskell.

I've mostly finished updating/completing the Gloss backend for GHCJS
though. It supports keyboard and mouse input now, so you can really create
games with it. The main loop is a bit glitchy still (sometimes draws older
frames), it keeps hogging CPU even if the tab is in the background and
sprites are not supported yet, so I still have a bit of work to do [1] [2] .

If anyone is interested in setting up a Codeworld instance that uses Gloss
instead of Codeworld's own simplified Haskell graphics library, I'd be
happy to help. Students should be able to copy/paste their working code in
a local file and compile it unchanged with native Gloss to get an
application that runs in a GLUT/OpenGL window (and it should be reasonably
easy to install that even on Windows now that the Haskell Platform comes
with freeglut).

At this point, it's unfortunately not yet possible to easily add a proper
REPL easily to projects like Codeworld. Most of the infrastructure is
already there (it's used for Template Haskell among other things), but it's
missing a front end. Hopefully after GHCJS is (finally) released on Hackage
and I've finished the new codegen and filled the biggest holes in the
libraries I'll have some time to implement GHCJSi.

luite

[1] http://hdiff.luite.com/tmp/boids.jsexe/ (from gloss-examples)
[2] http://hdiff.luite.com/tmp/pinhole.jsexe/ (by Omar Rizman, posted here:
http://rsnous.com/posts/2014-08-07-pinhole-a-falling-ball-demo.html )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140824/eea79cc8/attachment.html>

From stegeman at gmail.com  Sun Aug 24 12:29:55 2014
From: stegeman at gmail.com (Luite Stegeman)
Date: Sun, 24 Aug 2014 14:29:55 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <CALqQuogFnevfZRSYbrAVnjmF+B8wS4cy8fBVOkavMHnT5Qpu+Q@mail.gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAJN5CV+_nQr6qjxdgdhdqP02H=-D72tEoQOi_969-USQORKC-w@mail.gmail.com>
 <CALqQuogFnevfZRSYbrAVnjmF+B8wS4cy8fBVOkavMHnT5Qpu+Q@mail.gmail.com>
Message-ID: <CALqQuojmmKmq80VubBDYeuV78OuKr84S4TZvi-+eRkr+YrZa-g@mail.gmail.com>

On Sun, Aug 24, 2014 at 2:19 PM, Luite Stegeman <stegeman at gmail.com> wrote:

>
> I moved the service to a new machine because a hard drive in the old one
> died, but unfortunately I had some trouble restarting the evaluation
> service (it has to be started in some special way, in an SELinux sandbox).
> I managed to get it up and running now.
>
> Oops, it died again since something is still wrong with the permissions,
I'm looking into it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140824/8f595048/attachment.html>

From kazu at iij.ad.jp  Sun Aug 24 16:25:29 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Mon, 25 Aug 2014 01:25:29 +0900 (JST)
Subject: [Haskell-cafe] ghc-mod v5.0.0
In-Reply-To: <20140820.162913.1193211018461584634.kazu@iij.ad.jp>
References: <20140820.162913.1193211018461584634.kazu@iij.ad.jp>
Message-ID: <20140825.012529.1689734486647052920.kazu@iij.ad.jp>

Hi,

I found Alejandro's blog post:

	http://serras-haskell-gsoc.blogspot.jp/2014/08/summer-of-code-on-emacs.html

--Kazu


> Hi cafe,
> 
> We are happy to announce that ghc-mod v5.0.0 has been released.
> Highlights of this version is as follows:
> 
> - ghc-mod v4.x.y is suffering from the space leak of GHC
>   7.8.x(*1). So, ghc-modi consumes huge memory. ghc-modi v5.0.0
>   consumes much less memory thanks to workaround.
> 
> - Alejandro Serrano merges his results of Google Summer of Code. He
>   implements case splitting and sophisticated type hole handling.
>   I believe that he will write an article on his results but
>   I also updated the manual of Emacs fronted. (*2)
> 
> - Daniel Gr?ber brushed up the internal code by bringing the GhcMod
>   monad. So, the API of ghc-mod drastically changed. If you are users
>   of the ghc-mod library, you should check its document.
> 
> The main purpose of this release is to show the results of GSoC to
> everyone. This is a snapshot release and its API would change in the
> future.
> 
> I thank two guys above since they worked hard and did good jobs.
> We hope that everyone enjoys v5.0.0.
> 
> (*1) https://ghc.haskell.org/trac/ghc/ticket/9314
> (*2) http://www.mew.org/~kazu/proj/ghc-mod/en/emacs.html
> 
> --Kazu
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From alan.zimm at gmail.com  Sun Aug 24 16:52:12 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 24 Aug 2014 18:52:12 +0200
Subject: [Haskell-cafe] ghc-mod v5.0.0
In-Reply-To: <20140825.012529.1689734486647052920.kazu@iij.ad.jp>
References: <20140820.162913.1193211018461584634.kazu@iij.ad.jp>
 <20140825.012529.1689734486647052920.kazu@iij.ad.jp>
Message-ID: <CANma=H8oGSs0JM4cdU+AhDaAAt4UM8jDtt=mx=FHnAmuAHpzsQ@mail.gmail.com>

Yes, seen it already. And it is on hackernews too, just saw on the twitter
feed


On Sun, Aug 24, 2014 at 6:25 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi,
>
> I found Alejandro's blog post:
>
>
> http://serras-haskell-gsoc.blogspot.jp/2014/08/summer-of-code-on-emacs.html
>
> --Kazu
>
>
> > Hi cafe,
> >
> > We are happy to announce that ghc-mod v5.0.0 has been released.
> > Highlights of this version is as follows:
> >
> > - ghc-mod v4.x.y is suffering from the space leak of GHC
> >   7.8.x(*1). So, ghc-modi consumes huge memory. ghc-modi v5.0.0
> >   consumes much less memory thanks to workaround.
> >
> > - Alejandro Serrano merges his results of Google Summer of Code. He
> >   implements case splitting and sophisticated type hole handling.
> >   I believe that he will write an article on his results but
> >   I also updated the manual of Emacs fronted. (*2)
> >
> > - Daniel Gr?ber brushed up the internal code by bringing the GhcMod
> >   monad. So, the API of ghc-mod drastically changed. If you are users
> >   of the ghc-mod library, you should check its document.
> >
> > The main purpose of this release is to show the results of GSoC to
> > everyone. This is a snapshot release and its API would change in the
> > future.
> >
> > I thank two guys above since they worked hard and did good jobs.
> > We hope that everyone enjoys v5.0.0.
> >
> > (*1) https://ghc.haskell.org/trac/ghc/ticket/9314
> > (*2) http://www.mew.org/~kazu/proj/ghc-mod/en/emacs.html
> >
> > --Kazu
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140824/d9028f0f/attachment.html>

From hoerdegen at funktional.info  Sun Aug 24 18:43:45 2014
From: hoerdegen at funktional.info (=?ISO-8859-15?Q?Heinrich_H=F6rdegen?=)
Date: Sun, 24 Aug 2014 20:43:45 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting
Message-ID: <53FA3261.6080801@funktional.info>


Dear all,

next Tuesday, 26th of August, Munich's Haskell enthusiasts will meet
again at Cafe Puck around 19h30. Everyone is wellcome. Please note that
we will meet at Cafe Puck.

To help us reserve enough tables, please go to

http://www.haskell-munich.de/dates

and click the button.

Heinrich

From douglas.mcclean at gmail.com  Sun Aug 24 23:35:21 2014
From: douglas.mcclean at gmail.com (Douglas McClean)
Date: Sun, 24 Aug 2014 19:35:21 -0400
Subject: [Haskell-cafe] [ANN] igrf-0.2
Message-ID: <CACruqwS4CBMmt9Nt4=kUs6741wyJGYFgR9uSy=hMc+F8O6+G8g@mail.gmail.com>

igrf is a library that provides an implementation of the International
Geomagnetic Reference Field, which is just what it sounds like.

I've tested it against NOAA's online calculator, but use it at your own
risk. Note that the input is in geocentric and not geodetic coordinates.

There is haddock documentation, I'm working on figuring out why it isn't on
hackage and how to fix it.

-Doug McClean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140824/399d608f/attachment.html>

From tifonzafel at gmail.com  Mon Aug 25 17:12:49 2014
From: tifonzafel at gmail.com (felipe zapata)
Date: Mon, 25 Aug 2014 13:12:49 -0400
Subject: [Haskell-cafe] Undesired email
Message-ID: <CA+AeLgRMjaxkvm6s82W9-=G39EEeHkTumggfiSiURDXFuQphpw@mail.gmail.com>

Dear List,
I have a problem with me new smartphone.

Sorry for the inconvenient.

Best,

FelipeZ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140825/c1625899/attachment.html>

From michael at snoyman.com  Mon Aug 25 17:35:06 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 25 Aug 2014 20:35:06 +0300
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
Message-ID: <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>

On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Does anyone know of a website where I can write a few lines of Haskell
>> and have them run?
>
>
> http://ideone.com (ghc 7.6.3)
> fpcomplete.com's online IDE has a free/community tier, although for this
> I suspect you can't meet the ToS
>
>
>
Just to follow up publicly: the FP Complete terms of service should *not*
prevent any kind of usage in this case. We're in the process of revising
our ToS to make it clearer with the upcoming open publish model, but the
simple explanation of that model is: you can do whatever you want in the
IDE, but- like Github- all commits will be publicly viewable.

If anyone has questions about this, feel free to contact me.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140825/035efbb7/attachment.html>

From eir at cis.upenn.edu  Mon Aug 25 19:30:27 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 25 Aug 2014 15:30:27 -0400
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
Message-ID: <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>

Thanks for the many, varied responses to my query. I've learned more about all these tools!

Just to close the loop, though: I've decided not to go with any of these tools because of lack of REPL support. My approach to Haskell will not start with `main`, and I want students to get used to just writing functions first, before writing programs.

Thanks again for the pointers,
Richard

On Aug 25, 2014, at 1:35 PM, Michael Snoyman <michael at snoyman.com> wrote:

> 
> 
> 
> On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Does anyone know of a website where I can write a few lines of Haskell and have them run?
> 
> http://ideone.com (ghc 7.6.3)
> fpcomplete.com's online IDE has a free/community tier, although for this I suspect you can't meet the ToS
> 
> 
> 
> Just to follow up publicly: the FP Complete terms of service should *not* prevent any kind of usage in this case. We're in the process of revising our ToS to make it clearer with the upcoming open publish model, but the simple explanation of that model is: you can do whatever you want in the IDE, but- like Github- all commits will be publicly viewable.
> 
> If anyone has questions about this, feel free to contact me.
> 
> Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140825/c87908f4/attachment.html>

From gershomb at gmail.com  Tue Aug 26 02:10:06 2014
From: gershomb at gmail.com (Gershom B)
Date: Mon, 25 Aug 2014 22:10:06 -0400
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
Message-ID: <etPan.53fbec8d.507ed7ab.6c87@mbp.local>

One more suggestion then :-) SageMathCloud (https://cloud.sagemath.com/) now has ghc 7.6.3 running on it. It has a nice webeditor with haskell syntax highlighting and sharing of .hs files, and you can also pop open a terminal in the browser and interact with ghci directly. This basically gives a minimal unixy environment to play with the repl without having to do any installation work, etc.

It isn?t necessarly rich with libraries, etc. But for giving a ?real ghc? experience without the install, it might not be bad.

?g



On August 25, 2014 at 3:30:52 PM, Richard Eisenberg (eir at cis.upenn.edu) wrote:
> Thanks for the many, varied responses to my query. I've learned more about all these tools!  
>  
> Just to close the loop, though: I've decided not to go with any of these tools because of  
> lack of REPL support. My approach to Haskell will not start with `main`, and I want students  
> to get used to just writing functions first, before writing programs.
>  
> Thanks again for the pointers,
> Richard
>  
> On Aug 25, 2014, at 1:35 PM, Michael Snoyman wrote:
>  
> >
> >
> >
> > On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery wrote:
> > On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg wrote:
> > Does anyone know of a website where I can write a few lines of Haskell and have them run?  
> >
> > http://ideone.com (ghc 7.6.3)
> > fpcomplete.com's online IDE has a free/community tier, although for this I suspect  
> you can't meet the ToS
> >
> >
> >
> > Just to follow up publicly: the FP Complete terms of service should *not* prevent any  
> kind of usage in this case. We're in the process of revising our ToS to make it clearer with  
> the upcoming open publish model, but the simple explanation of that model is: you can  
> do whatever you want in the IDE, but- like Github- all commits will be publicly viewable.  
> >
> > If anyone has questions about this, feel free to contact me.
> >
> > Michael
>  
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>  


From madhub.bits at gmail.com  Tue Aug 26 04:51:27 2014
From: madhub.bits at gmail.com (Madhu Babu)
Date: Tue, 26 Aug 2014 00:51:27 -0400
Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac
Message-ID: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>

I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my
mac. Everything was working great. Just now saw the haskell platform
website again and found new version was released ( Haskell Platform
2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the
older version using uninstall-hs.

Now when i type "cabal" or "cabal update" on my terminal, it hangs.
Actually when i look into Activity Monitor, i can see that it is invoking
some "sh script & possibly some find command" infinitely. I initially guess
may be it is building some indexes. but it has been running for an hr or so.

I have Xcode 5, gcc and other command line tools installed properly

Please advice. I cannot install any other package using cabal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/42b4a99b/attachment.html>

From carter.schonwald at gmail.com  Tue Aug 26 05:20:51 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 26 Aug 2014 01:20:51 -0400
Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac
In-Reply-To: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
References: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
Message-ID: <CAHYVw0zhncvyP8dueL+XmHba1vb9uQRig=kc3tiq_3PaahKyzA@mail.gmail.com>

try downloading cabal-install from
http://www.haskell.org/cabal/download.html and running that one


On Tue, Aug 26, 2014 at 12:51 AM, Madhu Babu <madhub.bits at gmail.com> wrote:

>  I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my
> mac. Everything was working great. Just now saw the haskell platform
> website again and found new version was released ( Haskell Platform
> 2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the
> older version using uninstall-hs.
>
> Now when i type "cabal" or "cabal update" on my terminal, it hangs.
> Actually when i look into Activity Monitor, i can see that it is invoking
> some "sh script & possibly some find command" infinitely. I initially guess
> may be it is building some indexes. but it has been running for an hr or so.
>
> I have Xcode 5, gcc and other command line tools installed properly
>
> Please advice. I cannot install any other package using cabal.
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/32ce1e84/attachment.html>

From nicola.gigante at gmail.com  Tue Aug 26 06:23:43 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Tue, 26 Aug 2014 08:23:43 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
Message-ID: <8FADC04F-E02D-4B72-8AAC-8E4867376443@gmail.com>

Il giorno 25/ago/2014, alle ore 21:30, Richard Eisenberg <eir at cis.upenn.edu> ha scritto:
> 
> Thanks for the many, varied responses to my query. I've learned more about all these tools!
> 
> Just to close the loop, though: I've decided not to go with any of these tools because of lack of REPL support. My approach to Haskell will not start with `main`, and I want students to get used to just writing functions first, before writing programs.
> 

Have you seen IHaskell? It is very interactive!

http://gibiansky.github.io/IHaskell/

> Thanks again for the pointers,
> Richard

From mwm at mired.org  Tue Aug 26 07:46:30 2014
From: mwm at mired.org (Mike Meyer)
Date: Tue, 26 Aug 2014 02:46:30 -0500
Subject: [Haskell-cafe] Types depending on tuples.
Message-ID: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>

I'm doing some geometry in 2 and 3 dimensions. To do this, I've got
Vector2d and Vector3d classes, which are basically just wrappers around 2
and 3-tuples of doubles:

type Vector2d = (Double, Double)
type Vector3d = (Double, Double, Double)

I've also got a typeclass Vector so I can do polymorphic things on them:

type Vector3d = (Double, Double, Double)

(Ok, polymorphic thing).

I now have a need to convert lists of Vector's to a list of lists of
Doubles. I'd like that to be part of the Vector typeclass, but - well,
declaring it is interesting.

I can't just add a method "toLists :: a -> [Double]", because (according to
ghc), there's no match between the expected type 'Double' and the actual
type '[t1]'.

Can I declare this typeclass?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/11d3cd94/attachment.html>

From mike at izbicki.me  Tue Aug 26 07:59:24 2014
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 26 Aug 2014 00:59:24 -0700
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
Message-ID: <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>

You never actually provided the Vector type class, so it's difficult
to tell what exactly you're trying to do.

On Tue, Aug 26, 2014 at 12:46 AM, Mike Meyer <mwm at mired.org> wrote:
> I'm doing some geometry in 2 and 3 dimensions. To do this, I've got Vector2d
> and Vector3d classes, which are basically just wrappers around 2 and
> 3-tuples of doubles:
>
> type Vector2d = (Double, Double)
> type Vector3d = (Double, Double, Double)
>
> I've also got a typeclass Vector so I can do polymorphic things on them:
>
> type Vector3d = (Double, Double, Double)
>
> (Ok, polymorphic thing).
>
> I now have a need to convert lists of Vector's to a list of lists of
> Doubles. I'd like that to be part of the Vector typeclass, but - well,
> declaring it is interesting.
>
> I can't just add a method "toLists :: a -> [Double]", because (according to
> ghc), there's no match between the expected type 'Double' and the actual
> type '[t1]'.
>
> Can I declare this typeclass?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From mike at izbicki.me  Tue Aug 26 08:31:30 2014
From: mike at izbicki.me (Mike Izbicki)
Date: Tue, 26 Aug 2014 01:31:30 -0700
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
 <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>
 <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
Message-ID: <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>

This works just fine for me:

class Vector a where
    toLists :: a -> [Double]

instance Vector (Double,Double,Double) where
    toLists (a,b,c)=[a,b,c]

On Tue, Aug 26, 2014 at 1:17 AM, Mike Meyer <mwm at mired.org> wrote:
> It's there, but in the text:
>
> class Vector a where
>    toLists :: a -> [Double]
>
>
> On Tue, Aug 26, 2014 at 2:59 AM, Mike Izbicki <mike at izbicki.me> wrote:
>>
>> You never actually provided the Vector type class, so it's difficult
>> to tell what exactly you're trying to do.
>>
>> On Tue, Aug 26, 2014 at 12:46 AM, Mike Meyer <mwm at mired.org> wrote:
>> > I'm doing some geometry in 2 and 3 dimensions. To do this, I've got
>> > Vector2d
>> > and Vector3d classes, which are basically just wrappers around 2 and
>> > 3-tuples of doubles:
>> >
>> > type Vector2d = (Double, Double)
>> > type Vector3d = (Double, Double, Double)
>> >
>> > I've also got a typeclass Vector so I can do polymorphic things on them:
>> >
>> > type Vector3d = (Double, Double, Double)
>> >
>> > (Ok, polymorphic thing).
>> >
>> > I now have a need to convert lists of Vector's to a list of lists of
>> > Doubles. I'd like that to be part of the Vector typeclass, but - well,
>> > declaring it is interesting.
>> >
>> > I can't just add a method "toLists :: a -> [Double]", because (according
>> > to
>> > ghc), there's no match between the expected type 'Double' and the actual
>> > type '[t1]'.
>> >
>> > Can I declare this typeclass?
>> >
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe at haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>
>

From mwm at mired.org  Tue Aug 26 08:54:41 2014
From: mwm at mired.org (Mike Meyer)
Date: Tue, 26 Aug 2014 03:54:41 -0500
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
 <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>
 <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
 <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>
Message-ID: <CAD=7U2CtjcPRbHXM4ojuugsU6WizLcBEjDo713cxYVPdopH6_Q@mail.gmail.com>

Weird. I thought that's what I tried. Must have done something else.

Thanks!


On Tue, Aug 26, 2014 at 3:31 AM, Mike Izbicki <mike at izbicki.me> wrote:

> This works just fine for me:
>
> class Vector a where
>     toLists :: a -> [Double]
>
> instance Vector (Double,Double,Double) where
>     toLists (a,b,c)=[a,b,c]
>
> On Tue, Aug 26, 2014 at 1:17 AM, Mike Meyer <mwm at mired.org> wrote:
> > It's there, but in the text:
> >
> > class Vector a where
> >    toLists :: a -> [Double]
> >
> >
> > On Tue, Aug 26, 2014 at 2:59 AM, Mike Izbicki <mike at izbicki.me> wrote:
> >>
> >> You never actually provided the Vector type class, so it's difficult
> >> to tell what exactly you're trying to do.
> >>
> >> On Tue, Aug 26, 2014 at 12:46 AM, Mike Meyer <mwm at mired.org> wrote:
> >> > I'm doing some geometry in 2 and 3 dimensions. To do this, I've got
> >> > Vector2d
> >> > and Vector3d classes, which are basically just wrappers around 2 and
> >> > 3-tuples of doubles:
> >> >
> >> > type Vector2d = (Double, Double)
> >> > type Vector3d = (Double, Double, Double)
> >> >
> >> > I've also got a typeclass Vector so I can do polymorphic things on
> them:
> >> >
> >> > type Vector3d = (Double, Double, Double)
> >> >
> >> > (Ok, polymorphic thing).
> >> >
> >> > I now have a need to convert lists of Vector's to a list of lists of
> >> > Doubles. I'd like that to be part of the Vector typeclass, but - well,
> >> > declaring it is interesting.
> >> >
> >> > I can't just add a method "toLists :: a -> [Double]", because
> (according
> >> > to
> >> > ghc), there's no match between the expected type 'Double' and the
> actual
> >> > type '[t1]'.
> >> >
> >> > Can I declare this typeclass?
> >> >
> >> > _______________________________________________
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe at haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/707ab897/attachment.html>

From hjgtuyl at chello.nl  Tue Aug 26 12:13:29 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Tue, 26 Aug 2014 14:13:29 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <8FADC04F-E02D-4B72-8AAC-8E4867376443@gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
 <8FADC04F-E02D-4B72-8AAC-8E4867376443@gmail.com>
Message-ID: <op.xk678v1bpz0j5l@alquantor>


L.S.,

I have added the various suggestions here:
   https://www.haskell.org/haskellwiki/Learning_Haskell#Trying_Haskell_online

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 tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Aug 26 13:15:49 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 26 Aug 2014 14:15:49 +0100
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <CAD=7U2CtjcPRbHXM4ojuugsU6WizLcBEjDo713cxYVPdopH6_Q@mail.gmail.com>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
 <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>
 <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
 <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>
 <CAD=7U2CtjcPRbHXM4ojuugsU6WizLcBEjDo713cxYVPdopH6_Q@mail.gmail.com>
Message-ID: <20140826131548.GJ2021@weber>

On Tue, Aug 26, 2014 at 03:54:41AM -0500, Mike Meyer wrote:
> Weird. I thought that's what I tried. Must have done something else.

You said "need to convert lists of Vector's to a list of lists of                                                                               
Doubles" ([[Double]]).  This is just list of Doubles ([Double]).

From nikoamia at gmail.com  Tue Aug 26 14:22:58 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Tue, 26 Aug 2014 18:22:58 +0400
Subject: [Haskell-cafe] Locking of threads in one OS thread
In-Reply-To: <CAHVSqQdF3DM+uHq1n6HGa1+sJYoa0ryaNapjkDHkPp5ZS+Ka1w@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
 <CAHVSqQdF3DM+uHq1n6HGa1+sJYoa0ryaNapjkDHkPp5ZS+Ka1w@mail.gmail.com>
Message-ID: <CA+waHKVxY0Kw5pHVm1204VMYhDQajEn5GfLd=UKHk4FZ1mBPXA@mail.gmail.com>

On Wed, Aug 20, 2014 at 4:36 PM, Alexander Kjeldaas <
alexander.kjeldaas at gmail.com> wrote:

> Reading errno directly after the FFI call can eliminate heap overflows,
> but the async exception and timer issues still seem possible.
>

I have played around a bit and I can't understand what's going on with this
anymore. Check out this example:
https://gist.github.com/abbradar/76dafcee1807c9c5ac4d. Compile it with "ghc
test_c.c test.hs". I used "mask_" here to check if it can fix the problem.

There will be multiple discrepancies seen between written and read values
because of threads preemption if my_errno is used. However, if you use
"errno" (change #define for that) instead, everything seems good.

Anyway, it looks like getErrno and friends rely on this magical behaviour
of errno -- if some other library which uses global error state like
"my_errno" in example is used (I remember SDL doing that, and I have also
done it myself), there should be problems without some way to temporary
disable threads preemption, which I haven't found. Hence -- should I maybe
post a bug report about this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/f2d3b78e/attachment.html>

From agocorona at gmail.com  Tue Aug 26 14:54:28 2014
From: agocorona at gmail.com (Alberto G. Corona )
Date: Tue, 26 Aug 2014 16:54:28 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <8FADC04F-E02D-4B72-8AAC-8E4867376443@gmail.com>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
 <8FADC04F-E02D-4B72-8AAC-8E4867376443@gmail.com>
Message-ID: <CAArEJmb=mXixgyuhfUYXmT4i6ivVtgVwaZ7Bw9FE9dKZDnuhUg@mail.gmail.com>

sagemathCloud has a REPL


2014-08-26 8:23 GMT+02:00 Nicola Gigante <nicola.gigante at gmail.com>:

> Il giorno 25/ago/2014, alle ore 21:30, Richard Eisenberg <
> eir at cis.upenn.edu> ha scritto:
> >
> > Thanks for the many, varied responses to my query. I've learned more
> about all these tools!
> >
> > Just to close the loop, though: I've decided not to go with any of these
> tools because of lack of REPL support. My approach to Haskell will not
> start with `main`, and I want students to get used to just writing
> functions first, before writing programs.
> >
>
> Have you seen IHaskell? It is very interactive!
>
> http://gibiansky.github.io/IHaskell/
>
> > Thanks again for the pointers,
> > Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/c09e126e/attachment.html>

From hsyl20 at gmail.com  Tue Aug 26 14:59:42 2014
From: hsyl20 at gmail.com (Sylvain Henry)
Date: Tue, 26 Aug 2014 16:59:42 +0200
Subject: [Haskell-cafe] Locking of threads in one OS thread
In-Reply-To: <CA+waHKVxY0Kw5pHVm1204VMYhDQajEn5GfLd=UKHk4FZ1mBPXA@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
 <CAHVSqQdF3DM+uHq1n6HGa1+sJYoa0ryaNapjkDHkPp5ZS+Ka1w@mail.gmail.com>
 <CA+waHKVxY0Kw5pHVm1204VMYhDQajEn5GfLd=UKHk4FZ1mBPXA@mail.gmail.com>
Message-ID: <CAPmptcUnxdLJmxGOHv7yGZUbSpWVOGAJBWj1bJkotZJTNQ=z1A@mail.gmail.com>

AFAIK "errno" is handled explicitly in the RTS:
https://ghc.haskell.org/trac/ghc/browser/ghc/rts/Schedule.c#L484

-Sylvain


2014-08-26 16:22 GMT+02:00 Nikolay Amiantov <nikoamia at gmail.com>:

>
> On Wed, Aug 20, 2014 at 4:36 PM, Alexander Kjeldaas <
> alexander.kjeldaas at gmail.com> wrote:
>
>> Reading errno directly after the FFI call can eliminate heap overflows,
>> but the async exception and timer issues still seem possible.
>>
>
> I have played around a bit and I can't understand what's going on with
> this anymore. Check out this example:
> https://gist.github.com/abbradar/76dafcee1807c9c5ac4d. Compile it with
> "ghc test_c.c test.hs". I used "mask_" here to check if it can fix the
> problem.
>
> There will be multiple discrepancies seen between written and read values
> because of threads preemption if my_errno is used. However, if you use
> "errno" (change #define for that) instead, everything seems good.
>
> Anyway, it looks like getErrno and friends rely on this magical behaviour
> of errno -- if some other library which uses global error state like
> "my_errno" in example is used (I remember SDL doing that, and I have also
> done it myself), there should be problems without some way to temporary
> disable threads preemption, which I haven't found. Hence -- should I maybe
> post a bug report about this?
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/6923bf40/attachment.html>

From nikoamia at gmail.com  Tue Aug 26 16:08:47 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Tue, 26 Aug 2014 20:08:47 +0400
Subject: [Haskell-cafe] Fwd:  Locking of threads in one OS thread
In-Reply-To: <CA+waHKVuBkP4Yt2nm8UHrWVdbnyLTOuYrfdbjq=_g-a0GL8Gqw@mail.gmail.com>
References: <CA+waHKUJ0SeiOxvCsSeyTD659Qap_2gg90OidyVXWnWLjatojQ@mail.gmail.com>
 <CAHVSqQdF3DM+uHq1n6HGa1+sJYoa0ryaNapjkDHkPp5ZS+Ka1w@mail.gmail.com>
 <CA+waHKVxY0Kw5pHVm1204VMYhDQajEn5GfLd=UKHk4FZ1mBPXA@mail.gmail.com>
 <CAPmptcUnxdLJmxGOHv7yGZUbSpWVOGAJBWj1bJkotZJTNQ=z1A@mail.gmail.com>
 <CA+waHKVuBkP4Yt2nm8UHrWVdbnyLTOuYrfdbjq=_g-a0GL8Gqw@mail.gmail.com>
Message-ID: <CA+waHKVzTsP3VLOHF6zPftwDRK=6O9+veFM6_G8PvPaJU=kNVg@mail.gmail.com>

On Tue, Aug 26, 2014 at 6:59 PM, Sylvain Henry <hsyl20 at gmail.com> wrote:

> AFAIK "errno" is handled explicitly in the RTS:
> https://ghc.haskell.org/trac/ghc/browser/ghc/rts/Schedule.c#L484
>
> -Sylvain
>

Oh, thanks for pointing this out! Now this behaviour makes sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/873ecccb/attachment.html>

From jwlato at gmail.com  Tue Aug 26 19:36:38 2014
From: jwlato at gmail.com (John Lato)
Date: Tue, 26 Aug 2014 12:36:38 -0700
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <20140826131548.GJ2021@weber>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
 <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>
 <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
 <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>
 <CAD=7U2CtjcPRbHXM4ojuugsU6WizLcBEjDo713cxYVPdopH6_Q@mail.gmail.com>
 <20140826131548.GJ2021@weber>
Message-ID: <CAJ727Gg+Q7dFweML1AUa6HfLNYxTWxGGRWB3TMTYT5wF-p4bXw@mail.gmail.com>

On Aug 26, 2014 6:16 AM, "Tom Ellis" <
tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
>
> On Tue, Aug 26, 2014 at 03:54:41AM -0500, Mike Meyer wrote:
> > Weird. I thought that's what I tried. Must have done something else.
>
> You said "need to convert lists of Vector's to a list of lists of
> Doubles" ([[Double]]).  This is just list of Doubles ([Double]).

This operates on a single Vector. You can just map this function over a
list to do the requested conversion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/12bc7775/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Tue Aug 26 20:00:23 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Tue, 26 Aug 2014 21:00:23 +0100
Subject: [Haskell-cafe] Types depending on tuples.
In-Reply-To: <CAJ727Gg+Q7dFweML1AUa6HfLNYxTWxGGRWB3TMTYT5wF-p4bXw@mail.gmail.com>
References: <CAD=7U2DBWtivn-AmkHJGrA=1-G=pPB3x8x8qi2sF-Q2d2azzMA@mail.gmail.com>
 <CAKKZoUXHgsz8gj3b+E_BSLSWG4b0C9caVte=X+FyduBbG9qtWg@mail.gmail.com>
 <CAD=7U2A7uTUXZ9V1VrsOQBt6CS3UQ5DmfUwD1bneyLiAF=eoWA@mail.gmail.com>
 <CAKKZoUWOwbGORzSZ1n54AQEhk0Z6VX7Dx8=WozE7TOk3J+C_tQ@mail.gmail.com>
 <CAD=7U2CtjcPRbHXM4ojuugsU6WizLcBEjDo713cxYVPdopH6_Q@mail.gmail.com>
 <20140826131548.GJ2021@weber>
 <CAJ727Gg+Q7dFweML1AUa6HfLNYxTWxGGRWB3TMTYT5wF-p4bXw@mail.gmail.com>
Message-ID: <20140826200023.GK2021@weber>

On Tue, Aug 26, 2014 at 12:36:38PM -0700, John Lato wrote:
> On Aug 26, 2014 6:16 AM, "Tom Ellis" <
> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote:
> >
> > On Tue, Aug 26, 2014 at 03:54:41AM -0500, Mike Meyer wrote:
> > > Weird. I thought that's what I tried. Must have done something else.
> >
> > You said "need to convert lists of Vector's to a list of lists of
> > Doubles" ([[Double]]).  This is just list of Doubles ([Double]).
> 
> This operates on a single Vector. You can just map this function over a
> list to do the requested conversion.

Sure, I'm just saying that given that the original error was apparently

    no match between the expected type 'Double' and the actual type '[t1]'

this may be the source of the problem.

From doaitse.swierstra at gmail.com  Tue Aug 26 20:23:15 2014
From: doaitse.swierstra at gmail.com (S D Swierstra)
Date: Tue, 26 Aug 2014 22:23:15 +0200
Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac
In-Reply-To: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
References: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
Message-ID: <59D8EF48-B854-407B-A067-C87DCDF1C9B7@gmail.com>

I suffered from the same phenomenon. I carefully removed everything which smelled of ghc, including .ghc in my home directory and many spurious aliases. That cured the problem,

 Doaitse


On 26 Aug 2014, at 6:51 , Madhu Babu <madhub.bits at gmail.com> wrote:

> I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my mac. Everything was working great. Just now saw the haskell platform website again and found new version was released ( Haskell Platform 2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the older version using uninstall-hs.
> 
> Now when i type "cabal" or "cabal update" on my terminal, it hangs. Actually when i look into Activity Monitor, i can see that it is invoking some "sh script & possibly some find command" infinitely. I initially guess may be it is building some indexes. but it has been running for an hr or so.
> 
> I have Xcode 5, gcc and other command line tools installed properly
> 
> Please advice. I cannot install any other package using cabal.
> 
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/7526e890/attachment.html>

From madhub.bits at gmail.com  Tue Aug 26 23:58:20 2014
From: madhub.bits at gmail.com (Madhu Babu)
Date: Tue, 26 Aug 2014 19:58:20 -0400
Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac
In-Reply-To: <59D8EF48-B854-407B-A067-C87DCDF1C9B7@gmail.com>
References: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
 <59D8EF48-B854-407B-A067-C87DCDF1C9B7@gmail.com>
Message-ID: <CALh-VV6gLG3iuE=0CMKp8XygNt2XsN9ngyXzrgX=wYwt0Te6Qg@mail.gmail.com>

You are right. It worked for me now. Earlier, i deleted only
/Library/Hashell, ~/.cabal & one more similar dir. Looks like there are lot
of directories ( & more importantly broken symlinks which were still
pointing to old Library ).

Once i deleted all of them, it worked.

Thanks again for the advice.


On Tue, Aug 26, 2014 at 4:23 PM, S D Swierstra <doaitse.swierstra at gmail.com>
wrote:

> I suffered from the same phenomenon. I carefully removed everything which
> smelled of ghc, including .ghc in my home directory and many spurious
> aliases. That cured the problem,
>
>  Doaitse
>
>
> On 26 Aug 2014, at 6:51 , Madhu Babu <madhub.bits at gmail.com> wrote:
>
> I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my
> mac. Everything was working great. Just now saw the haskell platform
> website again and found new version was released ( Haskell Platform
> 2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the
> older version using uninstall-hs.
>
> Now when i type "cabal" or "cabal update" on my terminal, it hangs.
> Actually when i look into Activity Monitor, i can see that it is invoking
> some "sh script & possibly some find command" infinitely. I initially guess
> may be it is building some indexes. but it has been running for an hr or so.
>
> I have Xcode 5, gcc and other command line tools installed properly
>
> Please advice. I cannot install any other package using cabal.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140826/6f6b406a/attachment.html>

From dgorin at dc.uba.ar  Wed Aug 27 10:19:52 2014
From: dgorin at dc.uba.ar (=?windows-1252?Q?Daniel_Gor=EDn?=)
Date: Wed, 27 Aug 2014 11:19:52 +0100
Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac
In-Reply-To: <CALh-VV6gLG3iuE=0CMKp8XygNt2XsN9ngyXzrgX=wYwt0Te6Qg@mail.gmail.com>
References: <CALh-VV5Qob3MCh3_srM=LfDXDE30wUwXPEpdTWKyXUiuyyHqUA@mail.gmail.com>
 <59D8EF48-B854-407B-A067-C87DCDF1C9B7@gmail.com>
 <CALh-VV6gLG3iuE=0CMKp8XygNt2XsN9ngyXzrgX=wYwt0Te6Qg@mail.gmail.com>
Message-ID: <1397DF7E-BDB9-46F8-B7D8-4887681F91C2@dc.uba.ar>

I had the same problem. It turned out to be that for some unknown reason I ended up with:

/Library/Haskell/ghc-7.8.3-x86_64/bin/cabal -> cabal.wrap
/Library/Haskell/ghc-7.8.3-x86_64/bin/cabal.real -> cabal.wrap
/Library/Haskell/ghc-7.8.3-x86_64/bin/cabal.wrap

where cabal.wrap is a shell script that checks if a new cabal.config should be created and then calls? cabal.real. Replacing cabal.real with a binary version of cabal solves it.

I don?t know why this happened, I suspect that it might occur if you had ghc 7.8.2 already installed...

Daniel



On 27 Aug 2014, at 00:58, Madhu Babu <madhub.bits at gmail.com> wrote:

> You are right. It worked for me now. Earlier, i deleted only /Library/Hashell, ~/.cabal & one more similar dir. Looks like there are lot of directories ( & more importantly broken symlinks which were still pointing to old Library ).
> 
> Once i deleted all of them, it worked.
> 
> Thanks again for the advice.
> 
> 
> On Tue, Aug 26, 2014 at 4:23 PM, S D Swierstra <doaitse.swierstra at gmail.com> wrote:
> I suffered from the same phenomenon. I carefully removed everything which smelled of ghc, including .ghc in my home directory and many spurious aliases. That cured the problem,
> 
>  Doaitse
> 
> 
> On 26 Aug 2014, at 6:51 , Madhu Babu <madhub.bits at gmail.com> wrote:
> 
>> I initially installed haskell platform ( 2013 version; 7.6.3 ghc ) on my mac. Everything was working great. Just now saw the haskell platform website again and found new version was released ( Haskell Platform 2014.2.0.0 for Mac OS X, 64bit ). I installed it, and un-installed the older version using uninstall-hs.
>> 
>> Now when i type "cabal" or "cabal update" on my terminal, it hangs. Actually when i look into Activity Monitor, i can see that it is invoking some "sh script & possibly some find command" infinitely. I initially guess may be it is building some indexes. but it has been running for an hr or so.
>> 
>> I have Xcode 5, gcc and other command line tools installed properly
>> 
>> Please advice. I cannot install any other package using cabal.
>> 
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


From gershomb at gmail.com  Wed Aug 27 13:01:18 2014
From: gershomb at gmail.com (Gershom B)
Date: Wed, 27 Aug 2014 09:01:18 -0400
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <etPan.53fbec8d.507ed7ab.6c87@mbp.local>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
 <etPan.53fbec8d.507ed7ab.6c87@mbp.local>
Message-ID: <etPan.53fdd6ae.5bd062c2.6c87@mbp.local>

William Stein just sent me a nice note follwing up on this:

"I run SageMathCloud. If there are any libraries you want installed,?
just let me know (wstein at uw.edu). And if there is anything I should?
do to improve support for Haskell in SMC, let me know.?

Thanks,?

? William?

For those unfamiliar with SMC by the way, here is a nice post that he recently wrote about it and the vision behind it (aspects of which, I?m sure are shared by many in the Haskell community).

http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-lets-clear-some.html

Cheers,
g.


On August 25, 2014 at 10:10:22 PM, Gershom B (gershomb at gmail.com) wrote:
> One more suggestion then :-) SageMathCloud (https://cloud.sagemath.com/) now has  
> ghc 7.6.3 running on it. It has a nice webeditor with haskell syntax highlighting and  
> sharing of .hs files, and you can also pop open a terminal in the browser and interact with  
> ghci directly. This basically gives a minimal unixy environment to play with the repl  
> without having to do any installation work, etc.
>  
> It isn?t necessarly rich with libraries, etc. But for giving a ?real ghc? experience  
> without the install, it might not be bad.
>  
> ?g
>  
>  
>  
> On August 25, 2014 at 3:30:52 PM, Richard Eisenberg (eir at cis.upenn.edu) wrote:
> > Thanks for the many, varied responses to my query. I've learned more about all these  
> tools!
> >
> > Just to close the loop, though: I've decided not to go with any of these tools because  
> of
> > lack of REPL support. My approach to Haskell will not start with `main`, and I want students  
> > to get used to just writing functions first, before writing programs.
> >
> > Thanks again for the pointers,
> > Richard
> >
> > On Aug 25, 2014, at 1:35 PM, Michael Snoyman wrote:
> >
> > >
> > >
> > >
> > > On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery wrote:
> > > On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg wrote:
> > > Does anyone know of a website where I can write a few lines of Haskell and have them run?  
> > >
> > > http://ideone.com (ghc 7.6.3)
> > > fpcomplete.com's online IDE has a free/community tier, although for this I suspect  
> > you can't meet the ToS
> > >
> > >
> > >
> > > Just to follow up publicly: the FP Complete terms of service should *not* prevent any  
> > kind of usage in this case. We're in the process of revising our ToS to make it clearer  
> with
> > the upcoming open publish model, but the simple explanation of that model is: you can  
> > do whatever you want in the IDE, but- like Github- all commits will be publicly viewable.  
> > >
> > > If anyone has questions about this, feel free to contact me.
> > >
> > > Michael
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>  
>  


From me at khanson.io  Wed Aug 27 13:26:26 2014
From: me at khanson.io (Kyle Hanson)
Date: Wed, 27 Aug 2014 06:26:26 -0700
Subject: [Haskell-cafe] [ANN] Wheb 0.3 release
Message-ID: <CAMJUouB1KjdVMNDdNcece3e+tShCWNJe_sZjRktaNGPLnSXnWQ@mail.gmail.com>

Hello all,

I have been working on a web framework that I use for my personal projects
and I thought I would share my small progress. I started this project
several months ago when I hit a big bump in difficulty going from a simple
skeleton project to a more intricate project using alternative frameworks.

Lately I've added three main features: WebSockets, Cache and Redis.

WebSockets use the same WhebT interface as the standard HTTP handlers
allowing you to share functions and middlware accross your application.

Cache is a new plugin for simplistic Caching. It provides an interface to
cache ByteStrings under Text keys. Like the other plugins, it is backend
agnostic so you can write your own backend or use the prebuilt Redis cache
(this requires you to configure your redis instance for caching).

In addition to Redis acting as a Cache, you can also use it as a database
and as a backend for the plugins Auth and Sessions.

You can mix Redis with other plugins. For one of my projects I use the
MongoDB plugin for auth and storage and Redis as a cache for the queries.

Also included are typed web-routes, stateful cookie handling, and some
other stuff.

Feel free to check it out. I tried to include some documentation and
examples that I refer to when I use it. Maybe it will help someone. Its far
from perfect, so if you find any problems, let me know.

https://hackage.haskell.org/package/Wheb
https://github.com/hansonkd/Wheb-Framework

Cheers,
Kyle Hanson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/31ebb5a6/attachment.html>

From bryanvick at gmail.com  Wed Aug 27 18:19:37 2014
From: bryanvick at gmail.com (Bryan Vicknair)
Date: Wed, 27 Aug 2014 11:19:37 -0700
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
Message-ID: <20140827181937.GA28786@dev-auto.pittsburg.pmi>

Hello Cafe,

First I'd like to thank Michael Snoyman and Gabriel Gonzalez for the work
they've done on the conduit and pipes stream processing libraries, and all the
accompanying tutorial content.  I've been having fun converting a text
processing app from C to Haskell.

I'm seeing unexpectedly high memory usage in a stream-processing program that
uses the conduit library.

I've created a example that demonstrates the problem.  The program accepts gzip
files as arguments, and for each one, classifies each line as either Even or
Odd depending on the length, then outputs some result depending on the Sink
used.  For each gzip file:

  action :: GzipFilePath -> IO ()
  action (GzipFilePath filePath) = do
    result <- runResourceT $  CB.sourceFile filePath
                           $$ Zlib.ungzip
                           =$ CB.lines
                           =$ token
                           =$ sink2
    putStrLn $ show result

The problem is the following Sink, which counts how many even/odd Tokens are
seen:

  type SinkState = (Integer, Integer)

  sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
  sink2 state@(!evenCount, !oddCount) = do
    maybeToken <- await
    case maybeToken of
      Nothing     -> return state
      (Just Even) -> sink2 (evenCount + 1, oddCount    )
      (Just Odd ) -> sink2 (evenCount    , oddCount + 1)

When I give this program a few gzip files, it uses hundreds of megabytes of
resident memory.  When I give the same files as input, but use the following
simple Sink, it only uses about 8Mb of resident memory:

  sink1 :: MonadIO m => Sink Token m ()
  sink1 = awaitForever (liftIO . putStrLn . show)

At first I thought that sink2 performed so poorly because the addition thunks
were being placed onto the heap until the end, so I added some bang patterns to
make it strict.  That didn't help however.

I've done profiling, but I'm unable to figure out exactly what is being added
to the heap in sink2 but not sink1, or what is being garbage collected in
sink1, but not sink2.


The full source is here:
https://bitbucket.org/bryanvick/conduit-mem/src/HEAD/hsrc/bin/mem.hs

Or you can clone the repo, which contains a cabal file for easy building:

  git clone git at bitbucket.org:bryanvick/conduit-mem.git
  cd comduit-mem
  cabal sandbox init
  cabal install --only-dependencies
  cabal build mem
  ./dist/build/mem/mem [GIVE SOME GZIP FILES HERE]

You can change which sink is used in the 'action' function to see the different
memory usage.

From simonpj at microsoft.com  Wed Aug 27 19:20:56 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 27 Aug 2014 19:20:56 +0000
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <etPan.53fdd6ae.5bd062c2.6c87@mbp.local>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
 <etPan.53fbec8d.507ed7ab.6c87@mbp.local>
 <etPan.53fdd6ae.5bd062c2.6c87@mbp.local>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F33EE@DB3PRD3001MB020.064d.mgd.msft.net>

I may have missed this, but it'd be great if someone summarised the pointers in this thread on a Haskell Wiki page.

Simon

| -----Original Message-----
| From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of
| Gershom B
| Sent: 27 August 2014 14:01
| To: Richard Eisenberg
| Cc: haskell Cafe
| Subject: Re: [Haskell-cafe] lightweight web interface for Haskell?
| 
| William Stein just sent me a nice note follwing up on this:
| 
| "I run SageMathCloud. If there are any libraries you want installed,
| just let me know (wstein at uw.edu). And if there is anything I should
| do to improve support for Haskell in SMC, let me know.
| 
| Thanks,
| 
| ? William?
| 
| For those unfamiliar with SMC by the way, here is a nice post that he
| recently wrote about it and the vision behind it (aspects of which, I?m
| sure are shared by many in the Haskell community).
| 
| http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-lets-clear-
| some.html
| 
| Cheers,
| g.
| 
| 
| On August 25, 2014 at 10:10:22 PM, Gershom B (gershomb at gmail.com) wrote:
| > One more suggestion then :-) SageMathCloud
| (https://cloud.sagemath.com/) now has
| > ghc 7.6.3 running on it. It has a nice webeditor with haskell syntax
| highlighting and
| > sharing of .hs files, and you can also pop open a terminal in the
| browser and interact with
| > ghci directly. This basically gives a minimal unixy environment to play
| with the repl
| > without having to do any installation work, etc.
| >
| > It isn?t necessarly rich with libraries, etc. But for giving a ?real
| ghc? experience
| > without the install, it might not be bad.
| >
| > ?g
| >
| >
| >
| > On August 25, 2014 at 3:30:52 PM, Richard Eisenberg (eir at cis.upenn.edu)
| wrote:
| > > Thanks for the many, varied responses to my query. I've learned more
| about all these
| > tools!
| > >
| > > Just to close the loop, though: I've decided not to go with any of
| these tools because
| > of
| > > lack of REPL support. My approach to Haskell will not start with
| `main`, and I want students
| > > to get used to just writing functions first, before writing programs.
| > >
| > > Thanks again for the pointers,
| > > Richard
| > >
| > > On Aug 25, 2014, at 1:35 PM, Michael Snoyman wrote:
| > >
| > > >
| > > >
| > > >
| > > > On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery wrote:
| > > > On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg wrote:
| > > > Does anyone know of a website where I can write a few lines of
| Haskell and have them run?
| > > >
| > > > http://ideone.com (ghc 7.6.3)
| > > > fpcomplete.com's online IDE has a free/community tier, although for
| this I suspect
| > > you can't meet the ToS
| > > >
| > > >
| > > >
| > > > Just to follow up publicly: the FP Complete terms of service should
| *not* prevent any
| > > kind of usage in this case. We're in the process of revising our ToS
| to make it clearer
| > with
| > > the upcoming open publish model, but the simple explanation of that
| model is: you can
| > > do whatever you want in the IDE, but- like Github- all commits will
| be publicly viewable.
| > > >
| > > > If anyone has questions about this, feel free to contact me.
| > > >
| > > > Michael
| > >
| > > _______________________________________________
| > > Haskell-Cafe mailing list
| > > Haskell-Cafe at haskell.org
| > > http://www.haskell.org/mailman/listinfo/haskell-cafe
| > >
| >
| >
| 
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe

From alan.zimm at gmail.com  Wed Aug 27 19:29:11 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 27 Aug 2014 21:29:11 +0200
Subject: [Haskell-cafe] lightweight web interface for Haskell?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221F33EE@DB3PRD3001MB020.064d.mgd.msft.net>
References: <D3619018-E385-492E-951C-819B32C94D76@cis.upenn.edu>
 <CAKFCL4WWNMvOJ9a_ynqJJq2w9=5UvncWJXTT82wXZDZPKTu-2A@mail.gmail.com>
 <CAKA2JgKu+nYrKAeDC+idFibx_sGjRD01pXr+qx8vGa0pn69RBw@mail.gmail.com>
 <D8AD7516-EA4B-4440-8956-1F5FF22DBA67@cis.upenn.edu>
 <etPan.53fbec8d.507ed7ab.6c87@mbp.local>
 <etPan.53fdd6ae.5bd062c2.6c87@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF221F33EE@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CANma=H9fUFaryXh8ZEriHxafrwB1NwNsDwD+8TqJ6CqUJJ6Q-Q@mail.gmail.com>

I think it was added here
http://www.haskell.org/haskellwiki/Learning_Haskell#Trying_Haskell_online
See
http://www.haskell.org/haskellwiki/index.php?title=Learning_Haskell&action=history



On Wed, Aug 27, 2014 at 9:20 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I may have missed this, but it'd be great if someone summarised the
> pointers in this thread on a Haskell Wiki page.
>
> Simon
>
> | -----Original Message-----
> | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf
> Of
> | Gershom B
> | Sent: 27 August 2014 14:01
> | To: Richard Eisenberg
> | Cc: haskell Cafe
> | Subject: Re: [Haskell-cafe] lightweight web interface for Haskell?
> |
> | William Stein just sent me a nice note follwing up on this:
> |
> | "I run SageMathCloud. If there are any libraries you want installed,
> | just let me know (wstein at uw.edu). And if there is anything I should
> | do to improve support for Haskell in SMC, let me know.
> |
> | Thanks,
> |
> | ? William?
> |
> | For those unfamiliar with SMC by the way, here is a nice post that he
> | recently wrote about it and the vision behind it (aspects of which, I?m
> | sure are shared by many in the Haskell community).
> |
> | http://sagemath.blogspot.com/2014/08/what-is-sagemathcloud-lets-clear-
> | some.html
> |
> | Cheers,
> | g.
> |
> |
> | On August 25, 2014 at 10:10:22 PM, Gershom B (gershomb at gmail.com) wrote:
> | > One more suggestion then :-) SageMathCloud
> | (https://cloud.sagemath.com/) now has
> | > ghc 7.6.3 running on it. It has a nice webeditor with haskell syntax
> | highlighting and
> | > sharing of .hs files, and you can also pop open a terminal in the
> | browser and interact with
> | > ghci directly. This basically gives a minimal unixy environment to play
> | with the repl
> | > without having to do any installation work, etc.
> | >
> | > It isn?t necessarly rich with libraries, etc. But for giving a ?real
> | ghc? experience
> | > without the install, it might not be bad.
> | >
> | > ?g
> | >
> | >
> | >
> | > On August 25, 2014 at 3:30:52 PM, Richard Eisenberg (eir at cis.upenn.edu
> )
> | wrote:
> | > > Thanks for the many, varied responses to my query. I've learned more
> | about all these
> | > tools!
> | > >
> | > > Just to close the loop, though: I've decided not to go with any of
> | these tools because
> | > of
> | > > lack of REPL support. My approach to Haskell will not start with
> | `main`, and I want students
> | > > to get used to just writing functions first, before writing programs.
> | > >
> | > > Thanks again for the pointers,
> | > > Richard
> | > >
> | > > On Aug 25, 2014, at 1:35 PM, Michael Snoyman wrote:
> | > >
> | > > >
> | > > >
> | > > >
> | > > > On Sat, Aug 23, 2014 at 9:41 PM, Brandon Allbery wrote:
> | > > > On Sat, Aug 23, 2014 at 2:36 PM, Richard Eisenberg wrote:
> | > > > Does anyone know of a website where I can write a few lines of
> | Haskell and have them run?
> | > > >
> | > > > http://ideone.com (ghc 7.6.3)
> | > > > fpcomplete.com's online IDE has a free/community tier, although
> for
> | this I suspect
> | > > you can't meet the ToS
> | > > >
> | > > >
> | > > >
> | > > > Just to follow up publicly: the FP Complete terms of service should
> | *not* prevent any
> | > > kind of usage in this case. We're in the process of revising our ToS
> | to make it clearer
> | > with
> | > > the upcoming open publish model, but the simple explanation of that
> | model is: you can
> | > > do whatever you want in the IDE, but- like Github- all commits will
> | be publicly viewable.
> | > > >
> | > > > If anyone has questions about this, feel free to contact me.
> | > > >
> | > > > Michael
> | > >
> | > > _______________________________________________
> | > > Haskell-Cafe mailing list
> | > > Haskell-Cafe at haskell.org
> | > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> | > >
> | >
> | >
> |
> | _______________________________________________
> | Haskell-Cafe mailing list
> | Haskell-Cafe at haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/9c3065e1/attachment.html>

From nicola.gigante at gmail.com  Wed Aug 27 20:39:32 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Wed, 27 Aug 2014 22:39:32 +0200
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
Message-ID: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>

Hello!

I just want to point to your attention this issue of Homebrew:

https://github.com/Homebrew/homebrew/issues/31609

It seems that they?re forced to remove the formula for the
Haskell Platform because, it seems, the build process has
become extremely complicated and they can?t figure out how
to automate it.

Is there someone that know enough internals of the platform
to help them or to give some advice?

Thanks,
Nicola

From michael at snoyman.com  Wed Aug 27 20:48:06 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 27 Aug 2014 23:48:06 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
Message-ID: <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>

On Wed, Aug 27, 2014 at 9:19 PM, Bryan Vicknair <bryanvick at gmail.com> wrote:

> Hello Cafe,
>
> First I'd like to thank Michael Snoyman and Gabriel Gonzalez for the work
> they've done on the conduit and pipes stream processing libraries, and all
> the
> accompanying tutorial content.  I've been having fun converting a text
> processing app from C to Haskell.
>
> I'm seeing unexpectedly high memory usage in a stream-processing program
> that
> uses the conduit library.
>
> I've created a example that demonstrates the problem.  The program accepts
> gzip
> files as arguments, and for each one, classifies each line as either Even
> or
> Odd depending on the length, then outputs some result depending on the Sink
> used.  For each gzip file:
>
>   action :: GzipFilePath -> IO ()
>   action (GzipFilePath filePath) = do
>     result <- runResourceT $  CB.sourceFile filePath
>                            $$ Zlib.ungzip
>                            =$ CB.lines
>                            =$ token
>                            =$ sink2
>     putStrLn $ show result
>
> The problem is the following Sink, which counts how many even/odd Tokens
> are
> seen:
>
>   type SinkState = (Integer, Integer)
>
>   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
>   sink2 state@(!evenCount, !oddCount) = do
>     maybeToken <- await
>     case maybeToken of
>       Nothing     -> return state
>       (Just Even) -> sink2 (evenCount + 1, oddCount    )
>       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
>
> When I give this program a few gzip files, it uses hundreds of megabytes of
> resident memory.  When I give the same files as input, but use the
> following
> simple Sink, it only uses about 8Mb of resident memory:
>
>   sink1 :: MonadIO m => Sink Token m ()
>   sink1 = awaitForever (liftIO . putStrLn . show)
>
> At first I thought that sink2 performed so poorly because the addition
> thunks
> were being placed onto the heap until the end, so I added some bang
> patterns to
> make it strict.  That didn't help however.
>
> I've done profiling, but I'm unable to figure out exactly what is being
> added
> to the heap in sink2 but not sink1, or what is being garbage collected in
> sink1, but not sink2.
>
>
> The full source is here:
> https://bitbucket.org/bryanvick/conduit-mem/src/HEAD/hsrc/bin/mem.hs
>
> Or you can clone the repo, which contains a cabal file for easy building:
>
>   git clone git at bitbucket.org:bryanvick/conduit-mem.git
>   cd comduit-mem
>   cabal sandbox init
>   cabal install --only-dependencies
>   cabal build mem
>   ./dist/build/mem/mem [GIVE SOME GZIP FILES HERE]
>
> You can change which sink is used in the 'action' function to see the
> different
> memory usage. <http://www.haskell.org/mailman/listinfo/haskell-cafe>


Wow, talk about timing! What you've run into here is expensive monadic
bindings. As it turns out, this is exactly what my blog post from last
week[1] covered. You have three options to fix this:

1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
uses the codensity transform to avoid the problem. (I just tested your
code; you get constant memory usage under conduit 1.2.0, seemingly without
any code change necessary.)
2. Instead of writing your `sink2` as you have, express it in terms of
Data.Conduit.List.fold, which associates the right way. This looks like:

    fold add (0, 0)
      where
        add (!x, !y) Even = (x + 1, y)
        add (!x, !y) Odd = (x, y + 1)
3. Allow conduit 1.1's rewrite rules to emulate the same behavior and
bypass the expensive monadic bind. This can be done by replacing your
current `await` with "await followed by bind", e.g.:

sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
sink2 state@(!evenCount, !oddCount) = do
  await >>= maybe (return state) go
 where
  go Even = sink2 (evenCount + 1, oddCount    )
  go Odd  = sink2 (evenCount    , oddCount + 1)

I'd definitely recommend (1). I'd *also* recommend using (2), as the built
in functions will often times be more efficient than something hand-rolled,
especially now that stream fusion is being added[2]. With conduit 1.2, step
(3) *will* be a bit more efficient still (it avoids create an extra Maybe
value), but not in a significant way.

Michael

[1] https://www.fpcomplete.com/blog/2014/08/iap-speeding-up-conduit
[2] https://www.fpcomplete.com/blog/2014/08/conduit-stream-fusion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/bc0a1822/attachment.html>

From dev at rodlogic.net  Wed Aug 27 20:49:45 2014
From: dev at rodlogic.net (RodLogic)
Date: Wed, 27 Aug 2014 17:49:45 -0300
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
Message-ID: <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>

fwiw, instead of waiting for this I created a new set of formulas (based on
the stock homebrew one). The main difference is that I created one formula
for each version since I want to be able to switch between them using brew
link/unlink.

https://github.com/rodlogic/homebrew-ghc



On Wed, Aug 27, 2014 at 5:39 PM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

> Hello!
>
> I just want to point to your attention this issue of Homebrew:
>
> https://github.com/Homebrew/homebrew/issues/31609
>
> It seems that they?re forced to remove the formula for the
> Haskell Platform because, it seems, the build process has
> become extremely complicated and they can?t figure out how
> to automate it.
>
> Is there someone that know enough internals of the platform
> to help them or to give some advice?
>
> Thanks,
> Nicola
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/82e4712d/attachment.html>

From nicola.gigante at gmail.com  Wed Aug 27 21:01:29 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Wed, 27 Aug 2014 23:01:29 +0200
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
 <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
Message-ID: <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>


Il giorno 27/ago/2014, alle ore 22:49, RodLogic <dev at rodlogic.net> ha scritto:

> 
> fwiw, instead of waiting for this I created a new set of formulas (based on the stock homebrew one). The main difference is that I created one formula for each version since I want to be able to switch between them using brew link/unlink. 
> 
> https://github.com/rodlogic/homebrew-ghc
> 
> 

Actually, the formula for ghc 7.8 works well since very few days. 
The problem is with the Haskell Platform. Any idea?

Thanks,
Nicola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/d7b5df30/attachment.html>

From johan.tibell at gmail.com  Wed Aug 27 21:02:56 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 27 Aug 2014 23:02:56 +0200
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
 <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
 <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>
Message-ID: <CAK-tuPakeOiC1cuHK57g1pA-pj3MhE1zKqi0B+2Yze2SK__QXw@mail.gmail.com>

On Wed, Aug 27, 2014 at 11:01 PM, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

>
> Il giorno 27/ago/2014, alle ore 22:49, RodLogic <dev at rodlogic.net> ha
> scritto:
>
>
> fwiw, instead of waiting for this I created a new set of formulas (based
> on the stock homebrew one). The main difference is that I created one
> formula for each version since I want to be able to switch between them
> using brew link/unlink.
>
> https://github.com/rodlogic/homebrew-ghc
>
>
>
> Actually, the formula for ghc 7.8 works well since very few days.
> The problem is with the Haskell Platform. Any idea?
>
> Thanks,
> Nicola
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/1ecef61e/attachment.html>

From roma at ro-che.info  Wed Aug 27 21:55:16 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Thu, 28 Aug 2014 00:55:16 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
Message-ID: <20140827215516.GA2678@sniper>

* Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > The problem is the following Sink, which counts how many even/odd Tokens
> > are
> > seen:
> >
> >   type SinkState = (Integer, Integer)
> >
> >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> >   sink2 state@(!evenCount, !oddCount) = do
> >     maybeToken <- await
> >     case maybeToken of
> >       Nothing     -> return state
> >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> 
> Wow, talk about timing! What you've run into here is expensive monadic
> bindings. As it turns out, this is exactly what my blog post from last
> week[1] covered. You have three options to fix this:
> 
> 1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
> uses the codensity transform to avoid the problem. (I just tested your
> code; you get constant memory usage under conduit 1.2.0, seemingly without
> any code change necessary.)

Interesting. From looking at sink2, it seems that it produces a good,
right-associated bind tree. Am I missing something?

And what occupies the memory in this case?

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/a77e6740/attachment.sig>

From danburton.email at gmail.com  Wed Aug 27 22:39:06 2014
From: danburton.email at gmail.com (Dan Burton)
Date: Wed, 27 Aug 2014 15:39:06 -0700
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <20140827215516.GA2678@sniper>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
Message-ID: <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>

Michael, I don't see how your code sample for (3) is any different to the
compiler than Roman's original sink2.

I also don't see how the original sink2 creates a bad bind tree. I presume
that the reason "fold" works is due to the streaming optimization rule, and
not due to its implementation, which looks almost identical to (3).

I worry about using fold in this case, which is only strict up to WHNF, and
therefore wouldn't necessarily force the integers in the tuples; instead it
would create tons of integer thunks, wouldn't it? Roman's hand-coded sink2
avoids this issue so I presume that's not what is causing his memory woes.

-- Dan Burton


On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > > The problem is the following Sink, which counts how many even/odd
> Tokens
> > > are
> > > seen:
> > >
> > >   type SinkState = (Integer, Integer)
> > >
> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > >   sink2 state@(!evenCount, !oddCount) = do
> > >     maybeToken <- await
> > >     case maybeToken of
> > >       Nothing     -> return state
> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> >
> > Wow, talk about timing! What you've run into here is expensive monadic
> > bindings. As it turns out, this is exactly what my blog post from last
> > week[1] covered. You have three options to fix this:
> >
> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
> > uses the codensity transform to avoid the problem. (I just tested your
> > code; you get constant memory usage under conduit 1.2.0, seemingly
> without
> > any code change necessary.)
>
> Interesting. From looking at sink2, it seems that it produces a good,
> right-associated bind tree. Am I missing something?
>
> And what occupies the memory in this case?
>
> Roman
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/40d57ec4/attachment.html>

From carter.schonwald at gmail.com  Wed Aug 27 23:33:55 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 27 Aug 2014 19:33:55 -0400
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <CAK-tuPakeOiC1cuHK57g1pA-pj3MhE1zKqi0B+2Yze2SK__QXw@mail.gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
 <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
 <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>
 <CAK-tuPakeOiC1cuHK57g1pA-pj3MhE1zKqi0B+2Yze2SK__QXw@mail.gmail.com>
Message-ID: <CAHYVw0yQtYQr=2P-tah29re+Vke0RCrrhnZuPhTe99wN3mAf6Q@mail.gmail.com>

basically the problem is theres no one actively "owning" the brew formula
for ghc or platform AND also famliar with haskell.  if someone was willing
to be the "proactive owner" on the brew formula, i'm happy to help them
when they hit tricky OS X issues, but baring that development, I avoid
using Brew to manage GHC/Haskell platform like the plague, and advise
others thusly.

the Brew GHC formula is painfully out of date and kinda iffy .
https://github.com/Homebrew/homebrew/blob/master/Library/Formula/ghc.rb

It still defaults to 7.6 despite 7.6 being hosed on more modern build envs
unless you install userland GCC  (which then in turn breaks any haskell
package that assumes a suitable mac friendly / objective ), AND the GHC 7.8
version it provides is 7.8.2 which had many nasty bugs and is no .

Additionally, theres ZERO good reason to expose "build from source" option
for the GHC formula.  AND that has a complicated bootstrap process owing to
their focus on 7.6 support, which would go away if they switch to a "7.8
only" motif.

the GHC OS X build that Mark used for the newest haskell platform build
will work with OS X 10.6-10.1. Doing a binary install of that bindist
(./configure --prefix=$brewGHCprefix ; make install; link the executables
into path) should be the full extent of the brew formula.




On Wed, Aug 27, 2014 at 5:02 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

>
>
>
> On Wed, Aug 27, 2014 at 11:01 PM, Nicola Gigante <nicola.gigante at gmail.com
> > wrote:
>
>>
>> Il giorno 27/ago/2014, alle ore 22:49, RodLogic <dev at rodlogic.net> ha
>> scritto:
>>
>>
>> fwiw, instead of waiting for this I created a new set of formulas (based
>> on the stock homebrew one). The main difference is that I created one
>> formula for each version since I want to be able to switch between them
>> using brew link/unlink.
>>
>> https://github.com/rodlogic/homebrew-ghc
>>
>>
>>
>> Actually, the formula for ghc 7.8 works well since very few days.
>> The problem is with the Haskell Platform. Any idea?
>>
>> Thanks,
>> Nicola
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/8d7c2ef8/attachment.html>

From michael at snoyman.com  Thu Aug 28 04:00:41 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 07:00:41 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
Message-ID: <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>

Firstly, I think you mean Bryan's code, right? Secondly, I wrote this email
five minutes before going to bed, so please excuse any inaccuracies or
incoherence in it.

(3) is different to the original because it is form as `await >>= maybe`.
There's a rewrite rule for this (providing the conduit 1.1 version):

{-# RULES "await >>= maybe" forall x y. await >>= maybe x y = ConduitM
(NeedInput (unConduitM . y) (unConduitM . const x)) #-}

This gives two advantages: it avoids a costly (at least in conduit 1.1)
monadic bind, and avoids creating a Maybe value that we're going to
immediately throw away. This is the general idea of church encoding data
structures, which is why it should give *some* speedup, but nothing
significant.

Regarding fold: it *is* identical to (3). I don't think the rewrite rules
are playing a big part here. You're right about needing to be careful about
fold due to WHNF. However, Bryan's code already used bang patterns to force
evaluation of both values, so that isn't a problem. In a real-world
application, I'd *also* recommend creating a strict pair datatype to avoid
accidentally leaking thunks.

But looking at the code again with fresher eyes than last night: I really
don't understand why it had such abysmal performance. I'll look into this a
bit more, looks like it should be interesting.


On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
wrote:

> Michael, I don't see how your code sample for (3) is any different to the
> compiler than Roman's original sink2.
>
> I also don't see how the original sink2 creates a bad bind tree. I presume
> that the reason "fold" works is due to the streaming optimization rule, and
> not due to its implementation, which looks almost identical to (3).
>
> I worry about using fold in this case, which is only strict up to WHNF,
> and therefore wouldn't necessarily force the integers in the tuples;
> instead it would create tons of integer thunks, wouldn't it? Roman's
> hand-coded sink2 avoids this issue so I presume that's not what is causing
> his memory woes.
>
> -- Dan Burton
>
>
> On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
>> > > The problem is the following Sink, which counts how many even/odd
>> Tokens
>> > > are
>> > > seen:
>> > >
>> > >   type SinkState = (Integer, Integer)
>> > >
>> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
>> > >   sink2 state@(!evenCount, !oddCount) = do
>> > >     maybeToken <- await
>> > >     case maybeToken of
>> > >       Nothing     -> return state
>> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
>> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
>> >
>> > Wow, talk about timing! What you've run into here is expensive monadic
>> > bindings. As it turns out, this is exactly what my blog post from last
>> > week[1] covered. You have three options to fix this:
>> >
>> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
>> > uses the codensity transform to avoid the problem. (I just tested your
>> > code; you get constant memory usage under conduit 1.2.0, seemingly
>> without
>> > any code change necessary.)
>>
>> Interesting. From looking at sink2, it seems that it produces a good,
>> right-associated bind tree. Am I missing something?
>>
>> And what occupies the memory in this case?
>>
>> Roman
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/250a75fa/attachment-0001.html>

From dstcruz at gmail.com  Thu Aug 28 05:40:57 2014
From: dstcruz at gmail.com (Daniel Santa Cruz)
Date: Wed, 27 Aug 2014 23:40:57 -0600
Subject: [Haskell-cafe] Haskell Weekly News: Issue 303
Message-ID: <CA+V-9CwNi095CY90b9Lwx8tFPGf04B-c8cF_YopP4PNh5jnPpQ@mail.gmail.com>

Welcome to issue 303 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers
from August 17 to 23, 2014

Quotes of the Week

   * monochrom: "point free" can be decomposed to: "point" refers to
                ".", "free" refers to using no "$". :)

Top Reddit Stories

   * ? Bubble Pop!
     Domain: chrisuehlinger.com, Score: 97, Comments: 41
     Original: [1] http://goo.gl/hVQq2F
     On Reddit: [2] http://goo.gl/OQWXK2

   * The fundamental problem of programming language package management
     Domain: blog.ezyang.com, Score: 82, Comments: 54
     Original: [3] http://goo.gl/fWmA0P
     On Reddit: [4] http://goo.gl/PfJbY0

   * How Programming language subreddits talk (including Haskell)
     Domain: github.com, Score: 72, Comments: 31
     Original: [5] http://goo.gl/2Ef0tB
     On Reddit: [6] http://goo.gl/KpTH74

   * A fast, generic and type-safe image processing library written in
Haskell
     Domain: hackage.haskell.org, Score: 59, Comments: 27
     Original: [7] http://goo.gl/Pmeot3
     On Reddit: [8] http://goo.gl/Veffgp

   * GHC company-mode
     Domain: github.com, Score: 58, Comments: 7
     Original: [9] http://goo.gl/UVDEhl
     On Reddit: [10] http://goo.gl/uuxRCd

   * Hase - bringing state-of-the-art NLP to Haskell
     Domain: github.com, Score: 55, Comments: 8
     Original: [11] http://goo.gl/l39RVB
     On Reddit: [12] http://goo.gl/A8FI9k

   * Lens 4.4 release notes
     Domain: self.haskell, Score: 54, Comments: 18
     Original: [13] http://goo.gl/WjndWF
     On Reddit: [14] http://goo.gl/WjndWF

   * Jobs: Haskell developer roles at Standard Chartered
     Domain: donsbot.wordpress.com, Score: 48, Comments: 21
     Original: [15] http://goo.gl/ik0pc3
     On Reddit: [16] http://goo.gl/vDC3Jn

   * Speeding up conduit
     Domain: fpcomplete.com, Score: 42, Comments: 27
     Original: [17] http://goo.gl/wdbJVY
     On Reddit: [18] http://goo.gl/hfnyhj

   * Why is GHC Runtime Enviornment in C?
     Domain: self.haskell, Score: 39, Comments: 34
     Original: [19] http://goo.gl/9uh3YJ
     On Reddit: [20] http://goo.gl/9uh3YJ

   * An introduction to QuickCheck by example: Number theory and
     Okasaki's red-black trees
     Domain: matt.might.net, Score: 37, Comments: 1
     Original: [21] http://goo.gl/DnXQrK
     On Reddit: [22] http://goo.gl/zkLzQi

   * [ANN] dash-haskell: Package dependency approximate documentation
     look-up & access for IDE(s) (Emacs,Vim+)
     Domain: github.com, Score: 31, Comments: 9
     Original: [23] http://goo.gl/Z6HHFK
     On Reddit: [24] http://goo.gl/jxtJWW

   * Deprecating yesod-platform
     Domain: yesodweb.com, Score: 30, Comments: 10
     Original: [25] http://goo.gl/C3sSj9
     On Reddit: [26] http://goo.gl/P5w22y

   * Building Monad Transformers.
     Domain: jakubarnold.cz, Score: 25, Comments: 8
     Original: [27] http://goo.gl/SBeulZ
     On Reddit: [28] http://goo.gl/0a5vYr

   * Better code readability with Vim Haskell Conceal+
     Domain: github.com, Score: 20, Comments: 44
     Original: [29] http://goo.gl/2pNWCz
     On Reddit: [30] http://goo.gl/FMThMu

   * What's the best practice for building a DSL in haskell?
     Domain: self.haskell, Score: 19, Comments: 22
     Original: [31] http://goo.gl/v9fIO8
     On Reddit: [32] http://goo.gl/v9fIO8

   * Object-Oriented Style Overloading for Haskell
     Domain: research.microsoft.com, Score: 18, Comments: 9
     Original: [33] http://goo.gl/SPkDps
     On Reddit: [34] http://goo.gl/UwF6X5

   * SmartChecking Matt Might?s Red-Black Trees
     Domain: leepike.wordpress.com, Score: 18, Comments: 0
     Original: [35] http://goo.gl/gd5aUQ
     On Reddit: [36] http://goo.gl/9Ubkra

Top StackOverflow Questions

   * What kinds of type errors can Haskell catch at compile time that
     Java cannot? [closed]
     votes: 23, answers: 4
     Read on SO: [37] http://goo.gl/19MljX

   * How to link custom object file with Haskell library
     votes: 18, answers: 0
     Read on SO: [38] http://goo.gl/K6uC0X

   * Finding where <<loop>> happened
     votes: 17, answers: 2
     Read on SO: [39] http://goo.gl/kby69L

   * What exactly makes Option a monad in Scala?
     votes: 17, answers: 3
     Read on SO: [40] http://goo.gl/whDpHu

   * Arrow without arr
     votes: 16, answers: 0
     Read on SO: [41] http://goo.gl/VBbo0Z

   * max and min with NaN in Haskell
     votes: 15, answers: 3
     Read on SO: [42] http://goo.gl/xLFDhm

   * Simplifying a GADT with Uniplate
     votes: 11, answers: 1
     Read on SO: [43] http://goo.gl/uWL1pI

   * Trying to apply CPS to an interpreter
     votes: 9, answers: 1
     Read on SO: [44] http://goo.gl/kCtbcq

   * Jumping forward with the continuation monad
     votes: 8, answers: 1
     Read on SO: [45] http://goo.gl/fBKheg

   Until next time,
   [46]+Daniel Santa Cruz

References

   1. http://chrisuehlinger.com/LambdaBubblePop/
   2. http://www.reddit.com/r/haskell/comments/2eak9t/%CE%BB_bubble_pop/
   3.
http://blog.ezyang.com/2014/08/the-fundamental-problem-of-programming-language-package-management/
   4.
http://www.reddit.com/r/haskell/comments/2e74cn/the_fundamental_problem_of_programming_language/
   5.
https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words
   6.
http://www.reddit.com/r/haskell/comments/2e3ie6/how_programming_language_subreddits_talk/
   7. https://hackage.haskell.org/package/friday
   8.
http://www.reddit.com/r/haskell/comments/2e6cof/a_fast_generic_and_typesafe_image_processing/
   9. https://github.com/iquiw/company-ghc
  10. http://www.reddit.com/r/haskell/comments/2ebcim/ghc_companymode/
  11. https://github.com/slyrz/hase
  12.
http://www.reddit.com/r/haskell/comments/2edwtj/hase_bringing_stateoftheart_nlp_to_haskell/
  13. http://www.reddit.com/r/haskell/comments/2e9918/lens_44_release_notes/
  14. http://www.reddit.com/r/haskell/comments/2e9918/lens_44_release_notes/
  15.
http://donsbot.wordpress.com/2014/08/17/haskell-development-job-at-standard-chartered/
  16.
http://www.reddit.com/r/haskell/comments/2dsndt/jobs_haskell_developer_roles_at_standard_chartered/
  17. https://www.fpcomplete.com/blog/2014/08/iap-speeding-up-conduit
  18. http://www.reddit.com/r/haskell/comments/2e5ykd/speeding_up_conduit/
  19.
http://www.reddit.com/r/haskell/comments/2dx5rt/why_is_ghc_runtime_enviornment_in_c/
  20.
http://www.reddit.com/r/haskell/comments/2dx5rt/why_is_ghc_runtime_enviornment_in_c/
  21. http://matt.might.net/articles/quick-quickcheck/
  22.
http://www.reddit.com/r/haskell/comments/2dykb7/an_introduction_to_quickcheck_by_example_number/
  23. http://www.github.com/jfeltz/dash-haskell
  24.
http://www.reddit.com/r/haskell/comments/2dv68h/ann_dashhaskell_package_dependency_approximate/
  25. http://www.yesodweb.com/blog/2014/08/deprecating-yesod-platform
  26.
http://www.reddit.com/r/haskell/comments/2e1doq/deprecating_yesodplatform/
  27.
http://jakubarnold.cz/2014/07/22/building-monad-transformers-part-1.html
  28.
http://www.reddit.com/r/haskell/comments/2duen1/building_monad_transformers/
  29. https://github.com/enomsg/vim-haskellConcealPlus
  30.
http://www.reddit.com/r/haskell/comments/2dxg0h/better_code_readability_with_vim_haskell_conceal/
  31.
http://www.reddit.com/r/haskell/comments/2e8d53/whats_the_best_practice_for_building_a_dsl_in/
  32.
http://www.reddit.com/r/haskell/comments/2e8d53/whats_the_best_practice_for_building_a_dsl_in/
  33.
http://research.microsoft.com/en-us/um/people/simonpj/papers/oo-haskell/overloading.pdf
  34.
http://www.reddit.com/r/haskell/comments/2dyhbn/objectoriented_style_overloading_for_haskell/
  35.
http://leepike.wordpress.com/2014/08/20/smartchecking-matt-mights-red-black-trees/
  36.
http://www.reddit.com/r/haskell/comments/2e5t39/smartchecking_matt_mights_redblack_trees/
  37.
http://stackoverflow.com/questions/25374362/what-kinds-of-type-errors-can-haskell-catch-at-compile-time-that-java-cannot
  38.
http://stackoverflow.com/questions/25424615/how-to-link-custom-object-file-with-haskell-library
  39.
http://stackoverflow.com/questions/25359461/finding-where-loop-happened
  40.
http://stackoverflow.com/questions/25361203/what-exactly-makes-option-a-monad-in-scala
  41. http://stackoverflow.com/questions/25394745/arrow-without-arr
  42.
http://stackoverflow.com/questions/25375294/max-and-min-with-nan-in-haskell
  43.
http://stackoverflow.com/questions/25355570/simplifying-a-gadt-with-uniplate
  44.
http://stackoverflow.com/questions/25365900/trying-to-apply-cps-to-an-interpreter
  45.
http://stackoverflow.com/questions/25412238/jumping-forward-with-the-continuation-monad
  46. https://plus.google.com/105107667630152149014/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140827/e26d20b1/attachment.html>

From bryanvick at gmail.com  Thu Aug 28 05:58:26 2014
From: bryanvick at gmail.com (Bryan Vicknair)
Date: Wed, 27 Aug 2014 22:58:26 -0700
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
Message-ID: <20140828055826.GA14212@x220.att.net>

Thanks for the interesting blog posts Michael.  I updated the example project
[1] to use conduit 1.2.  Unfortunately, on my machine [2], my original sink2
still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
each, while sink1 only uses about 8Mb.  I added sink3, which does the same as
sink2 but uses fold from Conduit.List as you recommended, and that seems to
work, using about 8Mb.

Looking at the code for sink2 vs sink3, I don't understand what would be
occupying so much memory in sink2 even in the case of expensive monadic
binding, or exclusion from stream fusion.  I'm curious if sink2 adds thunks to
the heap that sink3 doesn't, or if the GC is failing to clean up heap objects
in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
action function is expensive.

In the real project that inspired this example I'm going to do some cleanup,
replacing manual recursion with higher-level functions from Conduit.List, as
that seems like an all around good idea.


Bryan Vicknair

[1] https://bitbucket.org/bryanvick/conduit-mem
[2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64


On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
<snip> 
> But looking at the code again with fresher eyes than last night: I really
> don't understand why it had such abysmal performance. I'll look into this a
> bit more, looks like it should be interesting.
> 
> 
> On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
> wrote:
> 
> > Michael, I don't see how your code sample for (3) is any different to the
> > compiler than Roman's original sink2.
> >
> > I also don't see how the original sink2 creates a bad bind tree. I presume
> > that the reason "fold" works is due to the streaming optimization rule, and
> > not due to its implementation, which looks almost identical to (3).
> >
> > I worry about using fold in this case, which is only strict up to WHNF,
> > and therefore wouldn't necessarily force the integers in the tuples;
> > instead it would create tons of integer thunks, wouldn't it? Roman's
> > hand-coded sink2 avoids this issue so I presume that's not what is causing
> > his memory woes.
> >
> > -- Dan Burton
> >
> >
> > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
> >
> >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> >> > > The problem is the following Sink, which counts how many even/odd
> >> Tokens
> >> > > are
> >> > > seen:
> >> > >
> >> > >   type SinkState = (Integer, Integer)
> >> > >
> >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> >> > >   sink2 state@(!evenCount, !oddCount) = do
> >> > >     maybeToken <- await
> >> > >     case maybeToken of
> >> > >       Nothing     -> return state
> >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> >> >
> >> > Wow, talk about timing! What you've run into here is expensive monadic
> >> > bindings. As it turns out, this is exactly what my blog post from last
> >> > week[1] covered. You have three options to fix this:
> >> >
> >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
> >> > uses the codensity transform to avoid the problem. (I just tested your
> >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> >> without
> >> > any code change necessary.)

From michael at snoyman.com  Thu Aug 28 05:56:34 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 08:56:34 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <20140828055826.GA14212@x220.att.net>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
Message-ID: <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>

I actually just got to an interesting result: sink2 is a red herring.
Consider the following program:

import Control.Monad.IO.Class ( liftIO )
import Data.Conduit.Internal (ConduitM (..), Pipe (..), (>+>), runPipe,
awaitForever)

main :: IO ()
main = runPipe $
    (HaveOutput (Done ()) (return ()) ()) >+>
    awaitForever (\_ -> liftIO $ lengthM 0 [1..10000000 :: Int] >>= print)

lengthM :: Monad m => Int -> [a] -> m Int
lengthM cnt [] = return cnt
lengthM cnt (_:xs) =
    cnt' `seq` lengthM cnt' xs
  where
    cnt' = cnt + 1


On my machine, it takes 375MB of memory. What appears to be the cause is
that GHC is keeping the entire representation of `lengthM` in memory, which
is clearly a pessimization. I still need to research this further, but I
thought you'd want to see these results now. (Plus, maybe someone else has
some other ideas.)

In case anyone wants, the core for this code is available at:

http://lpaste.net/110125

Michael


On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com> wrote:

> Thanks for the interesting blog posts Michael.  I updated the example
> project
> [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
> sink2
> still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
> each, while sink1 only uses about 8Mb.  I added sink3, which does the same
> as
> sink2 but uses fold from Conduit.List as you recommended, and that seems to
> work, using about 8Mb.
>
> Looking at the code for sink2 vs sink3, I don't understand what would be
> occupying so much memory in sink2 even in the case of expensive monadic
> binding, or exclusion from stream fusion.  I'm curious if sink2 adds
> thunks to
> the heap that sink3 doesn't, or if the GC is failing to clean up heap
> objects
> in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
> chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
> action function is expensive.
>
> In the real project that inspired this example I'm going to do some
> cleanup,
> replacing manual recursion with higher-level functions from Conduit.List,
> as
> that seems like an all around good idea.
>
>
> Bryan Vicknair
>
> [1] https://bitbucket.org/bryanvick/conduit-mem
> [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
>
>
> On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
> <snip>
> > But looking at the code again with fresher eyes than last night: I really
> > don't understand why it had such abysmal performance. I'll look into
> this a
> > bit more, looks like it should be interesting.
> >
> >
> > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
> > wrote:
> >
> > > Michael, I don't see how your code sample for (3) is any different to
> the
> > > compiler than Roman's original sink2.
> > >
> > > I also don't see how the original sink2 creates a bad bind tree. I
> presume
> > > that the reason "fold" works is due to the streaming optimization
> rule, and
> > > not due to its implementation, which looks almost identical to (3).
> > >
> > > I worry about using fold in this case, which is only strict up to WHNF,
> > > and therefore wouldn't necessarily force the integers in the tuples;
> > > instead it would create tons of integer thunks, wouldn't it? Roman's
> > > hand-coded sink2 avoids this issue so I presume that's not what is
> causing
> > > his memory woes.
> > >
> > > -- Dan Burton
> > >
> > >
> > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> > >
> > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > >> > > The problem is the following Sink, which counts how many even/odd
> > >> Tokens
> > >> > > are
> > >> > > seen:
> > >> > >
> > >> > >   type SinkState = (Integer, Integer)
> > >> > >
> > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > >> > >   sink2 state@(!evenCount, !oddCount) = do
> > >> > >     maybeToken <- await
> > >> > >     case maybeToken of
> > >> > >       Nothing     -> return state
> > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> > >> >
> > >> > Wow, talk about timing! What you've run into here is expensive
> monadic
> > >> > bindings. As it turns out, this is exactly what my blog post from
> last
> > >> > week[1] covered. You have three options to fix this:
> > >> >
> > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago,
> and
> > >> > uses the codensity transform to avoid the problem. (I just tested
> your
> > >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> > >> without
> > >> > any code change necessary.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/cac0600f/attachment.html>

From michael at snoyman.com  Thu Aug 28 06:31:41 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 09:31:41 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
Message-ID: <CAKA2JgKKV+rqyACbEYMCbt-U1TYFW+UQaHM5NMyDzpcQnX0ROg@mail.gmail.com>

 Well, I got it down to a case that depends on only base, and uses its own
local implementation of a minimal conduit:

http://lpaste.net/110126

But I'm not certain if this is still reproducing the original issue, or if
the list getting lifted out here is a different issue.


On Thu, Aug 28, 2014 at 8:56 AM, Michael Snoyman <michael at snoyman.com>
wrote:

> I actually just got to an interesting result: sink2 is a red herring.
> Consider the following program:
>
> import Control.Monad.IO.Class ( liftIO )
> import Data.Conduit.Internal (ConduitM (..), Pipe (..), (>+>), runPipe,
> awaitForever)
>
> main :: IO ()
> main = runPipe $
>     (HaveOutput (Done ()) (return ()) ()) >+>
>     awaitForever (\_ -> liftIO $ lengthM 0 [1..10000000 :: Int] >>= print)
>
> lengthM :: Monad m => Int -> [a] -> m Int
> lengthM cnt [] = return cnt
> lengthM cnt (_:xs) =
>     cnt' `seq` lengthM cnt' xs
>   where
>     cnt' = cnt + 1
>
>
> On my machine, it takes 375MB of memory. What appears to be the cause is
> that GHC is keeping the entire representation of `lengthM` in memory, which
> is clearly a pessimization. I still need to research this further, but I
> thought you'd want to see these results now. (Plus, maybe someone else has
> some other ideas.)
>
> In case anyone wants, the core for this code is available at:
>
> http://lpaste.net/110125
>
> Michael
>
>
> On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com>
> wrote:
>
>> Thanks for the interesting blog posts Michael.  I updated the example
>> project
>> [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
>> sink2
>> still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
>> each, while sink1 only uses about 8Mb.  I added sink3, which does the
>> same as
>> sink2 but uses fold from Conduit.List as you recommended, and that seems
>> to
>> work, using about 8Mb.
>>
>> Looking at the code for sink2 vs sink3, I don't understand what would be
>> occupying so much memory in sink2 even in the case of expensive monadic
>> binding, or exclusion from stream fusion.  I'm curious if sink2 adds
>> thunks to
>> the heap that sink3 doesn't, or if the GC is failing to clean up heap
>> objects
>> in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
>> chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
>> action function is expensive.
>>
>> In the real project that inspired this example I'm going to do some
>> cleanup,
>> replacing manual recursion with higher-level functions from Conduit.List,
>> as
>> that seems like an all around good idea.
>>
>>
>> Bryan Vicknair
>>
>> [1] https://bitbucket.org/bryanvick/conduit-mem
>> [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
>>
>>
>> On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
>> <snip>
>> > But looking at the code again with fresher eyes than last night: I
>> really
>> > don't understand why it had such abysmal performance. I'll look into
>> this a
>> > bit more, looks like it should be interesting.
>> >
>> >
>> > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
>> > wrote:
>> >
>> > > Michael, I don't see how your code sample for (3) is any different to
>> the
>> > > compiler than Roman's original sink2.
>> > >
>> > > I also don't see how the original sink2 creates a bad bind tree. I
>> presume
>> > > that the reason "fold" works is due to the streaming optimization
>> rule, and
>> > > not due to its implementation, which looks almost identical to (3).
>> > >
>> > > I worry about using fold in this case, which is only strict up to
>> WHNF,
>> > > and therefore wouldn't necessarily force the integers in the tuples;
>> > > instead it would create tons of integer thunks, wouldn't it? Roman's
>> > > hand-coded sink2 avoids this issue so I presume that's not what is
>> causing
>> > > his memory woes.
>> > >
>> > > -- Dan Burton
>> > >
>> > >
>> > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info>
>> wrote:
>> > >
>> > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
>> > >> > > The problem is the following Sink, which counts how many even/odd
>> > >> Tokens
>> > >> > > are
>> > >> > > seen:
>> > >> > >
>> > >> > >   type SinkState = (Integer, Integer)
>> > >> > >
>> > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
>> > >> > >   sink2 state@(!evenCount, !oddCount) = do
>> > >> > >     maybeToken <- await
>> > >> > >     case maybeToken of
>> > >> > >       Nothing     -> return state
>> > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
>> > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
>> > >> >
>> > >> > Wow, talk about timing! What you've run into here is expensive
>> monadic
>> > >> > bindings. As it turns out, this is exactly what my blog post from
>> last
>> > >> > week[1] covered. You have three options to fix this:
>> > >> >
>> > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours
>> ago, and
>> > >> > uses the codensity transform to avoid the problem. (I just tested
>> your
>> > >> > code; you get constant memory usage under conduit 1.2.0, seemingly
>> > >> without
>> > >> > any code change necessary.)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/f2304105/attachment.html>

From michael at snoyman.com  Thu Aug 28 06:37:45 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 09:37:45 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <20140828055826.GA14212@x220.att.net>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
Message-ID: <CAKA2Jg+9gk3R0yozCe-SBRCGOxou0hQB1V_K=DnFmV2LbeUOdw@mail.gmail.com>

Can you provide the output from +RTS -s, as well as the heap profile for
-hy?

I believe I'm now also reproducing the memory leak on conduit 1.2, so it
must have been a mistake in my testing last night when I thought 1.2 fixed
it.


On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com> wrote:

> Thanks for the interesting blog posts Michael.  I updated the example
> project
> [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
> sink2
> still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
> each, while sink1 only uses about 8Mb.  I added sink3, which does the same
> as
> sink2 but uses fold from Conduit.List as you recommended, and that seems to
> work, using about 8Mb.
>
> Looking at the code for sink2 vs sink3, I don't understand what would be
> occupying so much memory in sink2 even in the case of expensive monadic
> binding, or exclusion from stream fusion.  I'm curious if sink2 adds
> thunks to
> the heap that sink3 doesn't, or if the GC is failing to clean up heap
> objects
> in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
> chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
> action function is expensive.
>
> In the real project that inspired this example I'm going to do some
> cleanup,
> replacing manual recursion with higher-level functions from Conduit.List,
> as
> that seems like an all around good idea.
>
>
> Bryan Vicknair
>
> [1] https://bitbucket.org/bryanvick/conduit-mem
> [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
>
>
> On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
> <snip>
> > But looking at the code again with fresher eyes than last night: I really
> > don't understand why it had such abysmal performance. I'll look into
> this a
> > bit more, looks like it should be interesting.
> >
> >
> > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
> > wrote:
> >
> > > Michael, I don't see how your code sample for (3) is any different to
> the
> > > compiler than Roman's original sink2.
> > >
> > > I also don't see how the original sink2 creates a bad bind tree. I
> presume
> > > that the reason "fold" works is due to the streaming optimization
> rule, and
> > > not due to its implementation, which looks almost identical to (3).
> > >
> > > I worry about using fold in this case, which is only strict up to WHNF,
> > > and therefore wouldn't necessarily force the integers in the tuples;
> > > instead it would create tons of integer thunks, wouldn't it? Roman's
> > > hand-coded sink2 avoids this issue so I presume that's not what is
> causing
> > > his memory woes.
> > >
> > > -- Dan Burton
> > >
> > >
> > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> > >
> > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > >> > > The problem is the following Sink, which counts how many even/odd
> > >> Tokens
> > >> > > are
> > >> > > seen:
> > >> > >
> > >> > >   type SinkState = (Integer, Integer)
> > >> > >
> > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > >> > >   sink2 state@(!evenCount, !oddCount) = do
> > >> > >     maybeToken <- await
> > >> > >     case maybeToken of
> > >> > >       Nothing     -> return state
> > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> > >> >
> > >> > Wow, talk about timing! What you've run into here is expensive
> monadic
> > >> > bindings. As it turns out, this is exactly what my blog post from
> last
> > >> > week[1] covered. You have three options to fix this:
> > >> >
> > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago,
> and
> > >> > uses the codensity transform to avoid the problem. (I just tested
> your
> > >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> > >> without
> > >> > any code change necessary.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/213ffefd/attachment.html>

From nicola.gigante at gmail.com  Thu Aug 28 07:19:49 2014
From: nicola.gigante at gmail.com (Nicola Gigante)
Date: Thu, 28 Aug 2014 09:19:49 +0200
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <CAHYVw0yQtYQr=2P-tah29re+Vke0RCrrhnZuPhTe99wN3mAf6Q@mail.gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
 <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
 <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>
 <CAK-tuPakeOiC1cuHK57g1pA-pj3MhE1zKqi0B+2Yze2SK__QXw@mail.gmail.com>
 <CAHYVw0yQtYQr=2P-tah29re+Vke0RCrrhnZuPhTe99wN3mAf6Q@mail.gmail.com>
Message-ID: <0FF42CF4-B067-4B5A-83B7-559F29AF2219@gmail.com>


Il giorno 28/ago/2014, alle ore 01:33, Carter Schonwald <carter.schonwald at gmail.com> ha scritto:

> basically the problem is theres no one actively "owning" the brew formula for ghc or platform AND also famliar with haskell.  if someone was willing to be the "proactive owner" on the brew formula, i'm happy to help them when they hit tricky OS X issues, but baring that development, I avoid using Brew to manage GHC/Haskell platform like the plague, and advise others thusly. 
> 
> the Brew GHC formula is painfully out of date and kinda iffy .
> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/ghc.rb
> 
> It still defaults to 7.6 despite 7.6 being hosed on more modern build envs unless you install userland GCC  (which then in turn breaks any haskell package that assumes a suitable mac friendly / objective ), AND the GHC 7.8 version it provides is 7.8.2 which had many nasty bugs and is no .
> 
> Additionally, theres ZERO good reason to expose "build from source" option for the GHC formula.  AND that has a complicated bootstrap process owing to their focus on 7.6 support, which would go away if they switch to a "7.8 only" motif.
> 
> the GHC OS X build that Mark used for the newest haskell platform build will work with OS X 10.6-10.1. Doing a binary install of that bindist (./configure --prefix=$brewGHCprefix ; make install; link the executables into path) should be the full extent of the brew formula.
> 

So, If i can recall correctly:
- They could simplify a lot the process if they?d focus on ghc 7.8 only.
- Anyway, they should forget building from source and provide a formula that installs
  the binary distribution.

Am I correct?

Nicola

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/6f1ba423/attachment.html>

From simonpj at microsoft.com  Thu Aug 28 08:37:06 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 28 Aug 2014 08:37:06 +0000
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F3E87@DB3PRD3001MB020.064d.mgd.msft.net>

GHC is keeping the entire representation of `lengthM` in memory

Do you mean that?  lengthM is a function; its representation is just code.

Perhaps you mean that GHC is keeping the entire list [1..1000000] in memory?  Now that certainly makes sense? after all, doing so saves allocating (I# 4), (I# 5) etc for each call of the function passed to awaitForever.  Granted, it?s probably a bad idea in this case.

If that is your issue (still to be confirmed) the relevant ticket is https://ghc.haskell.org/trac/ghc/ticket/7206; could you add your example to that ticket, as further evidence that something should be done?

See also comment:9 in the ticket, which I have just added.

Simon


From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Michael Snoyman
Sent: 28 August 2014 06:57
To: Bryan Vicknair
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] Conduit+GHC high memory use for simple Sink

I actually just got to an interesting result: sink2 is a red herring. Consider the following program:

import Control.Monad.IO.Class ( liftIO )
import Data.Conduit.Internal (ConduitM (..), Pipe (..), (>+>), runPipe, awaitForever)

main :: IO ()
main = runPipe $
    (HaveOutput (Done ()) (return ()) ()) >+>
    awaitForever (\_ -> liftIO $ lengthM 0 [1..10000000 :: Int] >>= print)

lengthM :: Monad m => Int -> [a] -> m Int
lengthM cnt [] = return cnt
lengthM cnt (_:xs) =
    cnt' `seq` lengthM cnt' xs
  where
    cnt' = cnt + 1

On my machine, it takes 375MB of memory. What appears to be the cause is that GHC is keeping the entire representation of `lengthM` in memory, which is clearly a pessimization. I still need to research this further, but I thought you'd want to see these results now. (Plus, maybe someone else has some other ideas.)
In case anyone wants, the core for this code is available at:

http://lpaste.net/110125

Michael

On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com<mailto:bryanvick at gmail.com>> wrote:
Thanks for the interesting blog posts Michael.  I updated the example project
[1] to use conduit 1.2.  Unfortunately, on my machine [2], my original sink2
still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
each, while sink1 only uses about 8Mb.  I added sink3, which does the same as
sink2 but uses fold from Conduit.List as you recommended, and that seems to
work, using about 8Mb.

Looking at the code for sink2 vs sink3, I don't understand what would be
occupying so much memory in sink2 even in the case of expensive monadic
binding, or exclusion from stream fusion.  I'm curious if sink2 adds thunks to
the heap that sink3 doesn't, or if the GC is failing to clean up heap objects
in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
action function is expensive.

In the real project that inspired this example I'm going to do some cleanup,
replacing manual recursion with higher-level functions from Conduit.List, as
that seems like an all around good idea.


Bryan Vicknair

[1] https://bitbucket.org/bryanvick/conduit-mem
[2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64


On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
<snip>
> But looking at the code again with fresher eyes than last night: I really
> don't understand why it had such abysmal performance. I'll look into this a
> bit more, looks like it should be interesting.
>
>
> On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com<mailto:danburton.email at gmail.com>>
> wrote:
>
> > Michael, I don't see how your code sample for (3) is any different to the
> > compiler than Roman's original sink2.
> >
> > I also don't see how the original sink2 creates a bad bind tree. I presume
> > that the reason "fold" works is due to the streaming optimization rule, and
> > not due to its implementation, which looks almost identical to (3).
> >
> > I worry about using fold in this case, which is only strict up to WHNF,
> > and therefore wouldn't necessarily force the integers in the tuples;
> > instead it would create tons of integer thunks, wouldn't it? Roman's
> > hand-coded sink2 avoids this issue so I presume that's not what is causing
> > his memory woes.
> >
> > -- Dan Burton
> >
> >
> > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info<mailto:roma at ro-che.info>> wrote:
> >
> >> * Michael Snoyman <michael at snoyman.com<mailto:michael at snoyman.com>> [2014-08-27 23:48:06+0300]
> >> > > The problem is the following Sink, which counts how many even/odd
> >> Tokens
> >> > > are
> >> > > seen:
> >> > >
> >> > >   type SinkState = (Integer, Integer)
> >> > >
> >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> >> > >   sink2 state@(!evenCount, !oddCount) = do
> >> > >     maybeToken <- await
> >> > >     case maybeToken of
> >> > >       Nothing     -> return state
> >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> >> >
> >> > Wow, talk about timing! What you've run into here is expensive monadic
> >> > bindings. As it turns out, this is exactly what my blog post from last
> >> > week[1] covered. You have three options to fix this:
> >> >
> >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago, and
> >> > uses the codensity transform to avoid the problem. (I just tested your
> >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> >> without
> >> > any code change necessary.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/205877ba/attachment-0001.html>

From michael at snoyman.com  Thu Aug 28 08:49:45 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 11:49:45 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221F3E87@DB3PRD3001MB020.064d.mgd.msft.net>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221F3E87@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAKA2JgLK3zrwwgT5UV8C583E0GFvPrZQTe0ud+hWTH+Q1TSNOA@mail.gmail.com>

On Thu, Aug 28, 2014 at 11:37 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  GHC is keeping the entire representation of `lengthM` in memory
>
>
>
> Do you mean that?  lengthM is a function; its representation is just code.
>
>
>

At the time I wrote it, I did. What I was seeing in the earlier profiling
was that a large number of conduit constructors were being kept in memory,
and I initially thought something similar was happening with lengthM. It
*does* in fact seem like the memory problems with this later example are
simply the list being kept in memory. And in fact, there's a far simpler
version of this that demonstrates the problem:

main :: IO ()
main = printLen >> printLen

printLen :: IO ()
printLen = lengthM 0 [1..40000000 :: Int] >>= print

lengthM :: Monad m => Int -> [a] -> m Int
lengthM cnt [] = return cnt
lengthM cnt (_:xs) =
    cnt' `seq` lengthM cnt' xs
  where
    cnt' = cnt + 1

I'll add that as a comment to #7206.

This still doesn't answer what's going on in the original code. I'm
concerned that the issue may be the same, but I'm not seeing anything in
the core yet that's jumping out at me as being the problem. I'll try to
look at the code again with fresher eyes later today.

Michael


>  Perhaps you mean that GHC is keeping the entire list [1..1000000] in
> memory?  Now that certainly makes sense? after all, doing so saves
> allocating (I# 4), (I# 5) etc for each call of the function passed to
> awaitForever.  Granted, it?s probably a bad idea in this case.
>
>
>
> If that is your issue (still to be confirmed) the relevant ticket is
> https://ghc.haskell.org/trac/ghc/ticket/7206; could you add your example
> to that ticket, as further evidence that something should be done?
>
>
>
> See also comment:9 in the ticket, which I have just added.
>
>
>
> Simon
>
>
>
>
>
> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf
> Of *Michael Snoyman
> *Sent:* 28 August 2014 06:57
> *To:* Bryan Vicknair
> *Cc:* Haskell Cafe
> *Subject:* Re: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
>
>
>
> I actually just got to an interesting result: sink2 is a red herring.
> Consider the following program:
>
> import Control.Monad.IO.Class ( liftIO )
> import Data.Conduit.Internal (ConduitM (..), Pipe (..), (>+>), runPipe,
> awaitForever)
>
> main :: IO ()
> main = runPipe $
>     (HaveOutput (Done ()) (return ()) ()) >+>
>     awaitForever (\_ -> liftIO $ lengthM 0 [1..10000000 :: Int] >>= print)
>
> lengthM :: Monad m => Int -> [a] -> m Int
> lengthM cnt [] = return cnt
> lengthM cnt (_:xs) =
>     cnt' `seq` lengthM cnt' xs
>   where
>     cnt' = cnt + 1
>
>   On my machine, it takes 375MB of memory. What appears to be the cause
> is that GHC is keeping the entire representation of `lengthM` in memory,
> which is clearly a pessimization. I still need to research this further,
> but I thought you'd want to see these results now. (Plus, maybe someone
> else has some other ideas.)
>
> In case anyone wants, the core for this code is available at:
>
> http://lpaste.net/110125
>
>
>
> Michael
>
>
>
> On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com>
> wrote:
>
>  Thanks for the interesting blog posts Michael.  I updated the example
> project
> [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
> sink2
> still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
> each, while sink1 only uses about 8Mb.  I added sink3, which does the same
> as
> sink2 but uses fold from Conduit.List as you recommended, and that seems to
> work, using about 8Mb.
>
> Looking at the code for sink2 vs sink3, I don't understand what would be
> occupying so much memory in sink2 even in the case of expensive monadic
> binding, or exclusion from stream fusion.  I'm curious if sink2 adds
> thunks to
> the heap that sink3 doesn't, or if the GC is failing to clean up heap
> objects
> in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
> chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
> action function is expensive.
>
> In the real project that inspired this example I'm going to do some
> cleanup,
> replacing manual recursion with higher-level functions from Conduit.List,
> as
> that seems like an all around good idea.
>
>
> Bryan Vicknair
>
> [1] https://bitbucket.org/bryanvick/conduit-mem
> [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
>
>
> On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
> <snip>
>
> > But looking at the code again with fresher eyes than last night: I really
> > don't understand why it had such abysmal performance. I'll look into
> this a
> > bit more, looks like it should be interesting.
> >
> >
> > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
> > wrote:
> >
> > > Michael, I don't see how your code sample for (3) is any different to
> the
> > > compiler than Roman's original sink2.
> > >
> > > I also don't see how the original sink2 creates a bad bind tree. I
> presume
> > > that the reason "fold" works is due to the streaming optimization
> rule, and
> > > not due to its implementation, which looks almost identical to (3).
> > >
> > > I worry about using fold in this case, which is only strict up to WHNF,
> > > and therefore wouldn't necessarily force the integers in the tuples;
> > > instead it would create tons of integer thunks, wouldn't it? Roman's
> > > hand-coded sink2 avoids this issue so I presume that's not what is
> causing
> > > his memory woes.
> > >
> > > -- Dan Burton
> > >
> > >
> > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info>
> wrote:
> > >
> > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > >> > > The problem is the following Sink, which counts how many even/odd
> > >> Tokens
> > >> > > are
> > >> > > seen:
> > >> > >
> > >> > >   type SinkState = (Integer, Integer)
> > >> > >
> > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > >> > >   sink2 state@(!evenCount, !oddCount) = do
> > >> > >     maybeToken <- await
> > >> > >     case maybeToken of
> > >> > >       Nothing     -> return state
> > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> > >> >
> > >> > Wow, talk about timing! What you've run into here is expensive
> monadic
> > >> > bindings. As it turns out, this is exactly what my blog post from
> last
> > >> > week[1] covered. You have three options to fix this:
> > >> >
> > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago,
> and
> > >> > uses the codensity transform to avoid the problem. (I just tested
> your
> > >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> > >> without
> > >> > any code change necessary.)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/47b48a40/attachment.html>

From neto at netowork.me  Thu Aug 28 10:51:51 2014
From: neto at netowork.me (Ernesto Rodriguez)
Date: Thu, 28 Aug 2014 11:51:51 +0100
Subject: [Haskell-cafe] Call to arms for Haskell students
Message-ID: <CAG09Je1zSHrU=_5uGD0=399ySZUZB8N-10FPc6qinENAjetrmQ@mail.gmail.com>

Dear Haskellers,

My (previous) university is organizing one of the first university
hackathons in Europe. I am participating and would like to have a Haskell
team for the hackathon. However, I don't know any Haskellers around or who
can travel to Bremen. Let me know if anyone is interested to participate
and team up with me. If it helps there are quite inexpensive flights to
Bremen. The hackathon is only for students though. Quoted is the formal
invite.

Best regards,

Ernesto

It is about time to bring hackathons to European universities. A few
> students at Jacobs University are therefore organizing a hackathon that
> aims to bring people from different countries together to hack.
> jacobsHack?! is an international student-run hackathon in Bremen, Germany.
> Students will get 24 hours to hack on anything they like and have the
> chance to win prizes worth up to 2000?. Additionally they can make the
> first step in the direction of working with one of our sponsors Google?,
> SAP?, Microsoft?, and Entrepreneur First.
>
> More information at:
> https://jacobshack.com/
>
> Live long, #hackstrong
>

-- 
Ernesto Rodriguez

Masters Student
Computer Science
Utrecht University

www.netowork.me
github.com/netogallo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/e018bbf1/attachment.html>

From michael at snoyman.com  Thu Aug 28 13:43:53 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 16:43:53 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2JgLK3zrwwgT5UV8C583E0GFvPrZQTe0ud+hWTH+Q1TSNOA@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+6_A4nq72V7h-ORgYMXo1KYLyPzEr1QjYPs_CvCgHb8A@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221F3E87@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAKA2JgLK3zrwwgT5UV8C583E0GFvPrZQTe0ud+hWTH+Q1TSNOA@mail.gmail.com>
Message-ID: <CAKA2JgL4ZpTn9WJOWF1KmjQKYF1M8=YgYPGAShHr9mB=yEvZZA@mail.gmail.com>

On Thu, Aug 28, 2014 at 11:49 AM, Michael Snoyman <michael at snoyman.com>
wrote:

>
>
>
> On Thu, Aug 28, 2014 at 11:37 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>>  GHC is keeping the entire representation of `lengthM` in memory
>>
>>
>>
>> Do you mean that?  lengthM is a function; its representation is just code.
>>
>>
>>
>
> At the time I wrote it, I did. What I was seeing in the earlier profiling
> was that a large number of conduit constructors were being kept in memory,
> and I initially thought something similar was happening with lengthM. It
> *does* in fact seem like the memory problems with this later example are
> simply the list being kept in memory. And in fact, there's a far simpler
> version of this that demonstrates the problem:
>
> main :: IO ()
> main = printLen >> printLen
>
> printLen :: IO ()
> printLen = lengthM 0 [1..40000000 :: Int] >>= print
>
>
> lengthM :: Monad m => Int -> [a] -> m Int
> lengthM cnt [] = return cnt
> lengthM cnt (_:xs) =
>     cnt' `seq` lengthM cnt' xs
>   where
>     cnt' = cnt + 1
>
> I'll add that as a comment to #7206.
>
> This still doesn't answer what's going on in the original code. I'm
> concerned that the issue may be the same, but I'm not seeing anything in
> the core yet that's jumping out at me as being the problem. I'll try to
> look at the code again with fresher eyes later today.
>
>
Alright, I've opened up a GHC issue about this:

https://ghc.haskell.org/trac/ghc/ticket/9520

I'm going to continue trying to knock this down to a simpler test case, but
it seems that it's sufficient to call `action` twice to make the memory
usage high.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/d2951222/attachment.html>

From eir at cis.upenn.edu  Thu Aug 28 14:06:51 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 28 Aug 2014 10:06:51 -0400
Subject: [Haskell-cafe] "Hackathon"
Message-ID: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>

Hi Cafe,

In my experience, "hackathon" can refer to two very different sorts of events: hacking marathons (such as jacobsHack), where participants tend to work overnight to accomplish something amazing in a limited time; and hacker weekends (such as Hac Phi), where participants work on projects, socialize, and then (presumably) rest at night.

Both of these sorts of events have their place in the world, and I'm in no way suggesting one is "better" than the other. But, I do think it be good for all of us to name them differently, so folks know what they are signing up for. In particular, I'm worried that calling hacker weekends "hackathons" may discourage those of us with outside, inflexible commitments (e.g. kids; the need for 8 hours of sleep) from attending. Conversely, folks looking for the higher-energy environment of an all-night marathon might be disappointed to show up at a hacker weekend.

What do you think? Is this distinction pointless? Would being consistent about this difference help?

Here are some proposed new names for hacker weekends:
- Hacker weekend
- Hacker meetup
- Community Hack
- Weekend of Haskell

I personally favor reserving the term "hackathon" for the marathon events.

Richard

From allbery.b at gmail.com  Thu Aug 28 14:18:35 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 28 Aug 2014 10:18:35 -0400
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
Message-ID: <CAKFCL4Vu0bxUB2b_6iVtTXOjZUh2GDspwMHa=WuOQjsPooZUCw@mail.gmail.com>

On Thu, Aug 28, 2014 at 10:06 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> In my experience, "hackathon" can refer to two very different sorts of
> events: hacking marathons (such as jacobsHack), where participants tend to
> work overnight to accomplish something amazing in a limited time; and
> hacker weekends (such as Hac Phi), where participants work on projects,
> socialize, and then (presumably) rest at night.


I've noticed this as well; my boss likes to use it in your second meaning,
whereas I'm most familiar with the first meaning and tend to think of the
second as "hacker-con".

On the other hand, I have no answers to the questions (a) is there any
recognition of this, or conventions for this, in the wider programming
community; and (b) what makes more sense to other people.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/0a4814d8/attachment.html>

From alois.cochard at gmail.com  Thu Aug 28 14:19:28 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Thu, 28 Aug 2014 15:19:28 +0100
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
Message-ID: <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>

Hi Richard,

I'm not sure really, as a "hacker weekend" can easily transform into a
"proper" hackathon depending of the folks there and the enthusiast around
the projects.
The difference look very small to me, and I never seen the ambiguity as an
issue.

In fact Zurihack felt pretty much like a coding marathon, I'm not sure if
the "not sleeping" thing should be considered as part of the definition of
a hackathon...

Anyway, just my very personal way of thinking about such thing. I
understand your concern about people being discouraged, but maybe given a
more detailed explaination of the event really ease would help.



On 28 August 2014 15:06, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi Cafe,
>
> In my experience, "hackathon" can refer to two very different sorts of
> events: hacking marathons (such as jacobsHack), where participants tend to
> work overnight to accomplish something amazing in a limited time; and
> hacker weekends (such as Hac Phi), where participants work on projects,
> socialize, and then (presumably) rest at night.
>
> Both of these sorts of events have their place in the world, and I'm in no
> way suggesting one is "better" than the other. But, I do think it be good
> for all of us to name them differently, so folks know what they are signing
> up for. In particular, I'm worried that calling hacker weekends
> "hackathons" may discourage those of us with outside, inflexible
> commitments (e.g. kids; the need for 8 hours of sleep) from attending.
> Conversely, folks looking for the higher-energy environment of an all-night
> marathon might be disappointed to show up at a hacker weekend.
>
> What do you think? Is this distinction pointless? Would being consistent
> about this difference help?
>
> Here are some proposed new names for hacker weekends:
> - Hacker weekend
> - Hacker meetup
> - Community Hack
> - Weekend of Haskell
>
> I personally favor reserving the term "hackathon" for the marathon events.
>
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/0c28dca5/attachment.html>

From allbery.b at gmail.com  Thu Aug 28 14:23:30 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 28 Aug 2014 10:23:30 -0400
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
Message-ID: <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>

On Thu, Aug 28, 2014 at 10:19 AM, Alois Cochard <alois.cochard at gmail.com>
wrote:

> In fact Zurihack felt pretty much like a coding marathon, I'm not sure if
> the "not sleeping" thing should be considered as part of the definition of
> a hackathon...


IMO it's not; the difference is one of focus, more specifically is there
one or a small number of specific projects or is there a larger slate of
things that one can pick and choose from and which may well change their
form based on participation *plus* unorganized gatherings
(socialization/"hallway track"). My "hacker-con" take on the second form
implicitly recognizes that the "hallway track" may well be as continuous as
it is at many other conventions....

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/2a758347/attachment.html>

From carter.schonwald at gmail.com  Thu Aug 28 17:18:04 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Aug 2014 13:18:04 -0400
Subject: [Haskell-cafe] Haskell Platform 2014 build problems on OS X
In-Reply-To: <0FF42CF4-B067-4B5A-83B7-559F29AF2219@gmail.com>
References: <0CA43DA7-9528-439A-A182-DB4E7D1539FF@gmail.com>
 <CA++tqLbhQFtjbACXk8YEn3QXzwfy3t6MEeJ61fwDz_iGS-yZ3g@mail.gmail.com>
 <CB1813D7-2916-43F1-AB0B-14E56DC02265@gmail.com>
 <CAK-tuPakeOiC1cuHK57g1pA-pj3MhE1zKqi0B+2Yze2SK__QXw@mail.gmail.com>
 <CAHYVw0yQtYQr=2P-tah29re+Vke0RCrrhnZuPhTe99wN3mAf6Q@mail.gmail.com>
 <0FF42CF4-B067-4B5A-83B7-559F29AF2219@gmail.com>
Message-ID: <CAHYVw0z43Sc+U=y8UWQC-1URVaaueh8K6G5JPX7NeuDcgChCJA@mail.gmail.com>

Pretty much.  But not 7.8 generally, but >= 7.8.3 onwards.  There are some
nasty bugs in 7.8.2 that can bite if you're not careful.

On Thursday, August 28, 2014, Nicola Gigante <nicola.gigante at gmail.com>
wrote:

>
> Il giorno 28/ago/2014, alle ore 01:33, Carter Schonwald <
> carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> ha scritto:
>
> basically the problem is theres no one actively "owning" the brew formula
> for ghc or platform AND also famliar with haskell.  if someone was willing
> to be the "proactive owner" on the brew formula, i'm happy to help them
> when they hit tricky OS X issues, but baring that development, I avoid
> using Brew to manage GHC/Haskell platform like the plague, and advise
> others thusly.
>
> the Brew GHC formula is painfully out of date and kinda iffy .
> https://github.com/Homebrew/homebrew/blob/master/Library/Formula/ghc.rb
>
> It still defaults to 7.6 despite 7.6 being hosed on more modern build envs
> unless you install userland GCC  (which then in turn breaks any haskell
> package that assumes a suitable mac friendly / objective ), AND the GHC 7.8
> version it provides is 7.8.2 which had many nasty bugs and is no .
>
> Additionally, theres ZERO good reason to expose "build from source" option
> for the GHC formula.  AND that has a complicated bootstrap process owing to
> their focus on 7.6 support, which would go away if they switch to a "7.8
> only" motif.
>
> the GHC OS X build that Mark used for the newest haskell platform build
> will work with OS X 10.6-10.1. Doing a binary install of that bindist
> (./configure --prefix=$brewGHCprefix ; make install; link the executables
> into path) should be the full extent of the brew formula.
>
>
> So, If i can recall correctly:
> - They could simplify a lot the process if they?d focus on ghc 7.8 only.
> - Anyway, they should forget building from source and provide a formula
> that installs
>   the binary distribution.
>
> Am I correct?
>
> Nicola
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/ea7740d6/attachment.html>

From tikhon at jelv.is  Thu Aug 28 17:50:09 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Thu, 28 Aug 2014 10:50:09 -0700
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
 <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
Message-ID: <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>

I ran into this issue when telling people about Bay Hac. In college, at
least, "hackathon" has acquired a pretty specific meaning: a *competitive*
coding marathon, often with prizes. Bay Hac, on the other hand, was really
more like a mini-conference: talks, sessions and lots of socializing, but
no competitive aspect at all. (Personally, I like this quite a bit more
than a normal hackathon!) I didn't want to send the wrong impression, but I
also didn't know what else to call it except for "hackathon".

Even though BayHac had *some* aspects of a hackathon, I still don't think
it's a great description. If focuses on the wrong aspects. In my view, the
most important parts of BayHac were educational and social, and it was
incredibly valuable even if you didn't finish or even work on a project.
This is pretty much the opposite of most actual hackathons I see; even when
they have some focus on education, they still tend to be heavily
"getting-things-done" project oriented.

I'm really not sure what the best noun to use is, but I'm leaning towards
describing it as a mini convention or conference.


On Thu, Aug 28, 2014 at 7:23 AM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Thu, Aug 28, 2014 at 10:19 AM, Alois Cochard <alois.cochard at gmail.com>
> wrote:
>
>> In fact Zurihack felt pretty much like a coding marathon, I'm not sure if
>> the "not sleeping" thing should be considered as part of the definition of
>> a hackathon...
>
>
> IMO it's not; the difference is one of focus, more specifically is there
> one or a small number of specific projects or is there a larger slate of
> things that one can pick and choose from and which may well change their
> form based on participation *plus* unorganized gatherings
> (socialization/"hallway track"). My "hacker-con" take on the second form
> implicitly recognizes that the "hallway track" may well be as continuous as
> it is at many other conventions....
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/6ad6934d/attachment.html>

From bryanvick at gmail.com  Thu Aug 28 18:27:52 2014
From: bryanvick at gmail.com (Bryan Vicknair)
Date: Thu, 28 Aug 2014 11:27:52 -0700
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2Jg+9gk3R0yozCe-SBRCGOxou0hQB1V_K=DnFmV2LbeUOdw@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+9gk3R0yozCe-SBRCGOxou0hQB1V_K=DnFmV2LbeUOdw@mail.gmail.com>
Message-ID: <20140828182752.GA10078@dev-auto.pittsburg.pmi>

Michael,

When I was first digging into this bug, I also ran into the case where doing an
action twice would trigger a large increase in memory usage.  Also strange was
that doing 'sequence_ [action]' was causing the problem for me, but 'do action'
was not.

Strangely enough though, on my machine there is no memory difference between
running 'action' once or twice in your 1st example [1] in comment 4 of bug
#9520.  Whether action is done once or twice, the maximum resident memory as
reported by /usr/bin/time -v is about 1.1Mb.  I get roughly the same memory
usage from the second code example in that same comment.

Attached are the .prof and .hp files from running the 'mem' binary using sink2
on my machine.

Here is the output from the +RTS -s switch:

   2,191,403,328 bytes allocated in the heap
   4,269,946,560 bytes copied during GC
     528,829,096 bytes maximum residency (21 sample(s))
      21,830,752 bytes maximum slop
            1070 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      3826 colls,     0 par    0.37s    0.42s     0.0001s    0.0032s
  Gen  1        21 colls,     0 par    4.02s   14.98s     0.7131s    7.6060s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time    0.90s  (  6.22s elapsed)
  GC      time    2.74s  ( 11.04s elapsed)
  RP      time    0.00s  (  0.00s elapsed)
  PROF    time    1.65s  (  4.35s elapsed)
  EXIT    time    0.04s  (  0.05s elapsed)
  Total   time    5.33s  ( 17.31s elapsed)

  %GC     time      51.4%  (63.8% elapsed)

  Alloc rate    2,432,664,887 bytes per MUT second

  Productivity  17.6% of total user, 5.4% of total elapsed


Bryan Vicknair

[1] https://ghc.haskell.org/trac/ghc/ticket/9520#comment:4

On Thu, Aug 28, 2014 at 09:37:45AM +0300, Michael Snoyman wrote:
> Can you provide the output from +RTS -s, as well as the heap profile for
> -hy?
> 
> I believe I'm now also reproducing the memory leak on conduit 1.2, so it
> must have been a mistake in my testing last night when I thought 1.2 fixed
> it.
> 
> 
> On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com> wrote:
> 
> > Thanks for the interesting blog posts Michael.  I updated the example
> > project
> > [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
> > sink2
> > still uses about 500Mb of memory when processing 4 gzip files of about 5Mb
> > each, while sink1 only uses about 8Mb.  I added sink3, which does the same
> > as
> > sink2 but uses fold from Conduit.List as you recommended, and that seems to
> > work, using about 8Mb.
> >
> > Looking at the code for sink2 vs sink3, I don't understand what would be
> > occupying so much memory in sink2 even in the case of expensive monadic
> > binding, or exclusion from stream fusion.  I'm curious if sink2 adds
> > thunks to
> > the heap that sink3 doesn't, or if the GC is failing to clean up heap
> > objects
> > in sink2 that is cleans up in sink3.  I'm new at memory profiling, but the
> > chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that the
> > action function is expensive.
> >
> > In the real project that inspired this example I'm going to do some
> > cleanup,
> > replacing manual recursion with higher-level functions from Conduit.List,
> > as
> > that seems like an all around good idea.
> >
> >
> > Bryan Vicknair
> >
> > [1] https://bitbucket.org/bryanvick/conduit-mem
> > [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
> >
> >
> > On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
> > <snip>
> > > But looking at the code again with fresher eyes than last night: I really
> > > don't understand why it had such abysmal performance. I'll look into
> > this a
> > > bit more, looks like it should be interesting.
> > >
> > >
> > > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <danburton.email at gmail.com>
> > > wrote:
> > >
> > > > Michael, I don't see how your code sample for (3) is any different to
> > the
> > > > compiler than Roman's original sink2.
> > > >
> > > > I also don't see how the original sink2 creates a bad bind tree. I
> > presume
> > > > that the reason "fold" works is due to the streaming optimization
> > rule, and
> > > > not due to its implementation, which looks almost identical to (3).
> > > >
> > > > I worry about using fold in this case, which is only strict up to WHNF,
> > > > and therefore wouldn't necessarily force the integers in the tuples;
> > > > instead it would create tons of integer thunks, wouldn't it? Roman's
> > > > hand-coded sink2 avoids this issue so I presume that's not what is
> > causing
> > > > his memory woes.
> > > >
> > > > -- Dan Burton
> > > >
> > > >
> > > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info>
> > wrote:
> > > >
> > > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27 23:48:06+0300]
> > > >> > > The problem is the following Sink, which counts how many even/odd
> > > >> Tokens
> > > >> > > are
> > > >> > > seen:
> > > >> > >
> > > >> > >   type SinkState = (Integer, Integer)
> > > >> > >
> > > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > > >> > >   sink2 state@(!evenCount, !oddCount) = do
> > > >> > >     maybeToken <- await
> > > >> > >     case maybeToken of
> > > >> > >       Nothing     -> return state
> > > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> > > >> >
> > > >> > Wow, talk about timing! What you've run into here is expensive
> > monadic
> > > >> > bindings. As it turns out, this is exactly what my blog post from
> > last
> > > >> > week[1] covered. You have three options to fix this:
> > > >> >
> > > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours ago,
> > and
> > > >> > uses the codensity transform to avoid the problem. (I just tested
> > your
> > > >> > code; you get constant memory usage under conduit 1.2.0, seemingly
> > > >> without
> > > >> > any code change necessary.)
> >
-------------- next part --------------
JOB "mem /tmp/tcmsdb/src/471ecbb8d3e679fe0d2caf945edcd3f1.gz /tmp/tcmsdb/src/4bf2525ad7483b1938228ae25835beee.gz /tmp/tcmsdb/src/952afd64c15d57903dfa6958c382641d.gz /tmp/tcmsdb/src/980dfea7c997644e5bd256f7d4fea1b5.gz +RTS -p -s -hy"
DATE "Thu Aug 28 11:02 2014"
SAMPLE_UNIT "seconds"
VALUE_UNIT "bytes"
BEGIN_SAMPLE 0.00
END_SAMPLE 0.00
BEGIN_SAMPLE 0.08
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
Pipe	16
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
->ConduitM	24
->>>>>ConduitM	24
*	24
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
Pipe	32
->Pipe	32
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
->(#,#)	16
->*	16
->*	40
->Pipe	24
Pipe	24
IO	32
IO	32
->Pipe	16
->Pipe	16
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->Pipe	16
->>>Pipe	16
->*	80
Popper	40
Monad	24
->Pipe	16
->>>Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
ConduitM	32
Pipe	4431120
Integer	2954032
*	32
(,)	4431216
Sink	4504352
Sink	1403776
Pipe	64
Pipe	5908064
Pipe	4504352
Pipe	1403776
->Pipe	32
->Pipe	2954048
->Pipe	4431072
Pipe	24
*	24
->Pipe	80
->Pipe	80
BLACKHOLE	48
ForeignPtrContents	32
ByteString	120
ARR_WORDS	163712
END_SAMPLE 0.08
BEGIN_SAMPLE 0.17
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
->Pipe	16
ByteString	40
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
->Pipe	40
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
IO	32
IO	32
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->ConduitM	24
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
Pipe	16
Pipe	2444704
->Pipe	8413152
->Pipe	5608768
Pipe	8772832
Pipe	8413200
Pipe	11217504
*	32
Pipe	64
ForeignPtrContents	32
Integer	5608768
->Pipe	32
ConduitM	56
(,)	8413320
Sink	8772864
Sink	2444736
Pipe	24
*	24
Pipe	32
Pipe	24
ResourceT	16
BLACKHOLE	32
->Pipe	32
ARR_WORDS	163712
END_SAMPLE 0.17
BEGIN_SAMPLE 0.26
ThreadId	16
IO	80
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
BufferMode	24
FD	24
IO	32
->IO	16
->(,)	24
stg_ap_2_upd_info	32
*	24
stg_sel_upd	48
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
*	24
->>>Pipe	16
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
Handle__	272
STArray	40
IO	16
->IO	16
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
->Pipe	40
IO	32
IO	32
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
TextEncoding	64
Int32	16
IO	16
MonadResource	48
Finalizers	16
*	24
->>*	112
->*	24
ForeignPtrContents	16
->*	64
MonadIO	24
stg_sel_upd	48
->Pipe	16
->>ResourceT	16
*	32
->Pipe	16
->ResourceT	16
->*	24
->*	32
->ConduitM	16
->ResourceT	24
->ConduitM	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
->(#,#)	16
->*	16
PAP	168
ConduitM	32
->*	40
Pipe	32
->Pipe	24
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
Monad	40
->*	16
->*	80
->ConduitM	40
->>>>>ConduitM	24
->Pipe	72
*	24
->>*	24
*	24
Monad	24
->Pipe	16
Obj	16
ForeignPtrContents	144
->IO	16
Dynamic	24
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
Pipe	16
Pipe	3417024
->Pipe	12359376
->Pipe	8239584
Pipe	13062144
Pipe	12359424
Pipe	16479136
*	32
ConduitM	32
Pipe	64
Integer	8239584
Pipe	32
->Pipe	32
ConduitM	56
(,)	12359544
Sink	13062176
Sink	3417056
Pipe	32
*	40
Pipe	24
*	24
Pipe	32
Pipe	24
ResourceT	16
BLACKHOLE	32
->Pipe	32
ForeignPtrContents	32
ByteString	40
->IO	16
Maybe	64
ForeignPtr	96
*	32
Popper	40
ARR_WORDS	163712
END_SAMPLE 0.26
BEGIN_SAMPLE 0.35
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
->Pipe	16
ByteString	40
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
->Pipe	40
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
IO	32
IO	32
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->ConduitM	24
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
Pipe	16
Pipe	4371968
->Pipe	16011120
->Pipe	10674080
Pipe	16976192
Pipe	16011168
Pipe	21348128
*	32
Pipe	64
ForeignPtrContents	32
Integer	10674080
->Pipe	32
ConduitM	56
(,)	16011288
Sink	16976224
Sink	4372000
Pipe	24
*	24
Pipe	32
Pipe	24
ResourceT	16
BLACKHOLE	32
->Pipe	32
ARR_WORDS	163712
END_SAMPLE 0.35
BEGIN_SAMPLE 0.42
ThreadId	16
IO	80
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
->Pipe	16
ByteString	40
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
->Pipe	40
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
IO	32
IO	32
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->ConduitM	24
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
Pipe	16
Pipe	5284064
->Pipe	19532640
->Pipe	13021760
Pipe	20759456
Pipe	19532688
Pipe	26043488
*	32
Pipe	64
ForeignPtrContents	32
Integer	13021760
->Pipe	32
ConduitM	56
(,)	19532808
Sink	20759488
Sink	5284096
Pipe	24
*	24
Pipe	32
Pipe	24
ResourceT	16
BLACKHOLE	32
->Pipe	32
ARR_WORDS	163712
END_SAMPLE 0.42
BEGIN_SAMPLE 0.50
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
->ConduitM	24
->>>>>ConduitM	24
*	24
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
Pipe	32
->Pipe	32
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
->(#,#)	16
->*	16
->*	40
->Pipe	24
Pipe	24
IO	32
IO	32
->Pipe	16
->Pipe	16
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->Pipe	16
->>>Pipe	16
->*	80
Popper	40
Monad	24
->Pipe	16
->>>Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
ConduitM	32
Pipe	16
Pipe	22922448
Integer	15281584
*	32
(,)	22922544
Sink	24390560
Sink	6172672
Pipe	64
Pipe	30563168
Pipe	24390560
Pipe	6172672
->Pipe	32
->Pipe	15281600
->Pipe	22922400
Pipe	24
*	24
->Pipe	80
->Pipe	80
BLACKHOLE	48
ForeignPtrContents	32
ByteString	120
ARR_WORDS	163712
END_SAMPLE 0.50
BEGIN_SAMPLE 0.57
ThreadId	16
IO	80
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
->ConduitM	24
->>>>>ConduitM	24
*	24
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
Pipe	32
->Pipe	32
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
->(#,#)	16
->*	16
->*	40
->Pipe	24
Pipe	24
IO	32
IO	32
->Pipe	16
->Pipe	16
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->Pipe	16
->>>Pipe	16
->*	80
Popper	40
Monad	24
->Pipe	16
->>>Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
ConduitM	32
Pipe	16
Pipe	26276616
Integer	17517696
*	32
(,)	26276712
Sink	28008064
Sink	7027392
Pipe	64
Pipe	35035392
Pipe	28008064
Pipe	7027392
->Pipe	32
->Pipe	17517712
->Pipe	26276568
Pipe	24
*	24
->Pipe	80
->Pipe	80
BLACKHOLE	48
ForeignPtrContents	32
ByteString	120
ARR_WORDS	163712
END_SAMPLE 0.57
BEGIN_SAMPLE 0.65
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
Handle__	272
STArray	40
IO	16
->IO	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
->Pipe	16
ByteString	40
ForeignPtrContents	16
*	32
->IO	16
Dynamic	24
->[]	96
->>IO	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
Buffer	280
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
->Pipe	40
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
IO	32
IO	32
TextEncoding	64
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
ForeignPtr	96
->ConduitM	24
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
Obj	16
ForeignPtrContents	144
Maybe	64
MUT_VAR_CLEAN	288
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	4512
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
Pipe	16
Pipe	7879360
->Pipe	29587296
->Pipe	19724864
Pipe	31570368
Pipe	29587344
Pipe	39449696
*	32
Pipe	64
ForeignPtrContents	32
Integer	19724864
->Pipe	32
ConduitM	56
(,)	29587464
Sink	31570400
Sink	7879392
Pipe	24
*	24
Pipe	32
Pipe	24
ResourceT	16
BLACKHOLE	32
->Pipe	32
ARR_WORDS	163712
END_SAMPLE 0.65
BEGIN_SAMPLE 0.74
IO	32
->IO	16
->(,)	24
stg_ap_2_upd_info	32
->Pipe	16
*	24
->Pipe	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
*	24
->>>Pipe	16
->Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
->>>*	32
->>>*	32
->>>Pipe	24
*	24
->>>Pipe	16
->>>Pipe	16
BufferState	24
[]	192
BufferCodec	48
BufferList	24
STArray	40
IO	16
->IO	16
->ResourceT	16
->*	24
->*	32
->ConduitM	16
ForeignPtrContents	16
->*	64
->*	80
MonadIO	24
->>ResourceT	16
*	32
->ResourceT	24
->ConduitM	24
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
Monad	40
->*	16
->ConduitM	40
->>>>>ConduitM	24
->Pipe	72
*	24
->>*	24
*	24
Monad	24
Obj	16
->IO	16
Dynamic	24
->[]	96
->>IO	16
MUT_ARR_PTRS_CLEAN	552
C_FINALIZER_LIST	96
Handle	48
MVar	16
DEAD_WEAK	96
WEAK	192
->(#,#)	16
->Pipe	40
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
Int32	16
IO	16
MonadResource	48
Finalizers	16
*	24
->>*	112
->*	24
->*	16
PAP	168
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
->Pipe	40
ForeignPtrContents	168
Buffer	336
NewlineMode	48
Bool	48
stg_sel_upd	72
stg_sel_upd	72
BufferMode	48
MUT_VAR_CLEAN	368
FD	48
Handle__	408
MVAR	128
[]	4488
ThreadId	16
IO	120
IO	32
IO	32
MonadIO	24
MonadBase	48
TextEncoding	64
Pipe	32
Pipe	33667488
Integer	22444944
ConduitM	32
(,)	33667608
Sink	35482464
Sink	9407488
Pipe	32
->Pipe	32
ConduitM	56
Pipe	44889856
Pipe	35482464
Pipe	9407488
Pipe	32
*	40
BLACKHOLE	16
Pipe	24
*	24
Pipe	32
->Pipe	22444960
->Pipe	33667440
ForeignPtrContents	32
ByteString	40
->IO	16
Maybe	64
ForeignPtr	96
*	32
Popper	40
Pipe	64
*	32
ARR_WORDS	171888
END_SAMPLE 0.74
BEGIN_SAMPLE 0.81
IO	80
ThreadId	16
MonadIO	24
MonadBase	48
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
BufferCodec	48
BufferList	24
Handle__	272
STArray	40
IO	16
->IO	16
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
IO	32
IO	32
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
TextEncoding	64
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
ForeignPtrContents	16
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	3264
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
*	32
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
Maybe	64
->ConduitM	24
->Pipe	16
->>>Pipe	16
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
->>>Pipe	16
*	24
Obj	16
MUT_VAR_CLEAN	288
->IO	16
Dynamic	24
->>IO	16
ForeignPtr	96
Buffer	280
BufferState	24
ForeignPtrContents	144
->[]	96
[]	192
Pipe	32
Pipe	36667848
*	32
(,)	36667944
Sink	37403072
Sink	11487360
Pipe	64
Pipe	48890336
Pipe	37403072
Pipe	11487360
ByteString	80
ForeignPtrContents	32
->Pipe	32
->Pipe	24445200
->Pipe	36667800
ByteString	32
ConduitM	56
Pipe	24
*	24
->Pipe	80
->Pipe	80
BLACKHOLE	32
->Pipe	32
Integer	24445184
ARR_WORDS	163712
END_SAMPLE 0.81
BEGIN_SAMPLE 0.87
ThreadId	16
IO	80
NewlineMode	24
Bool	24
IO	32
BufferMode	24
FD	24
->IO	16
->(,)	24
->ResourceT	24
MonadIO	24
stg_sel_upd	48
stg_ap_2_upd_info	32
->ConduitM	40
->>ResourceT	16
*	32
*	24
stg_sel_upd	48
->*	24
->>*	24
->>ResourceT	16
*	24
->ResourceT	16
ConduitM	32
Monad	40
->*	16
->->Pipe	16
->(#,#)	16
->>IO	24
->IO	24
->Pipe	72
Pipe	32
*	24
->>*	24
*	24
*	24
->>>Pipe	16
Pipe	40
->IO	32
->>(#,#)	16
STRef	16
Pipe	32
*	40
->>>*	32
->>>*	32
->>>Pipe	24
BufferCodec	48
BufferList	24
Handle__	272
STArray	40
IO	16
->IO	16
ConduitM	32
->*	40
Pipe	32
->Pipe	24
Pipe	24
->Pipe	32
->Pipe	16
IO	32
->Pipe	16
->Pipe	16
->Pipe	32
->Pipe	32
->ResourceT	16
Int32	16
IO	16
MonadResource	48
*	24
Finalizers	16
->>*	112
->*	24
->*	64
ForeignPtrContents	16
MUT_ARR_PTRS_CLEAN	552
MVAR	96
C_FINALIZER_LIST	48
[]	3264
Handle	48
MVar	16
WEAK	192
->(#,#)	16
->*	16
*	32
->Pipe	16
->ResourceT	16
->*	24
->*	32
PAP	168
->ConduitM	16
->IO	16
Maybe	64
->ConduitM	24
->Pipe	16
->>>Pipe	16
->*	80
Popper	40
->>>>>ConduitM	24
Monad	24
->Pipe	16
->>>Pipe	16
*	24
Obj	16
MUT_VAR_CLEAN	288
->IO	16
Dynamic	24
->>IO	16
ForeignPtr	96
Buffer	280
BufferState	24
ForeignPtrContents	144
->[]	96
[]	192
IO	32
MonadIO	24
MonadBase	48
TextEncoding	64
Pipe	32
Pipe	38681160
*	32
(,)	38681256
Sink	38597856
Sink	12976992
Pipe	64
Pipe	51574752
Pipe	38597856
Pipe	12976992
ByteString	80
ForeignPtrContents	32
->Pipe	32
->Pipe	25787408
->Pipe	38681112
ByteString	32
ConduitM	56
Pipe	24
*	24
->Pipe	80
->Pipe	80
BLACKHOLE	32
->Pipe	32
Integer	25787392
ARR_WORDS	163712
END_SAMPLE 0.87
BEGIN_SAMPLE 0.94
END_SAMPLE 0.94
-------------- next part --------------
	Thu Aug 28 11:02 2014 Time and Allocation Profiling Report  (Final)

	   mem +RTS -p -s -hy -RTS /tmp/tcmsdb/src/471ecbb8d3e679fe0d2caf945edcd3f1.gz /tmp/tcmsdb/src/4bf2525ad7483b1938228ae25835beee.gz /tmp/tcmsdb/src/952afd64c15d57903dfa6958c382641d.gz /tmp/tcmsdb/src/980dfea7c997644e5bd256f7d4fea1b5.gz

	total time  =        1.10 secs   (1096 ticks @ 1000 us, 1 processor)
	total alloc = 1,510,912,856 bytes  (excludes profiling overheads)

COST CENTRE    MODULE    %time %alloc

action         Main       88.6   57.3
sink2          Main        6.7   34.4
token          Main        2.9    8.4
token.tokenize Main        1.8    0.0


                                                                     individual     inherited
COST CENTRE                MODULE                  no.     entries  %time %alloc   %time %alloc

MAIN                       MAIN                    140           0    0.0    0.0   100.0  100.0
 main                      Main                    281           0    0.0    0.0    93.5   65.6
  action                   Main                    291           4   88.6   57.3    93.5   65.6
   action.sink             Main                    311           0    0.0    0.0     0.2    0.0
    sink2                  Main                    312           0    0.2    0.0     0.2    0.0
   token                   Main                    309           0    2.9    8.4     4.7    8.4
    token.tokenize         Main                    310     1753770    1.8    0.0     1.8    0.0
  main.tryArgs             Main                    282           1    0.0    0.0     0.0    0.0
   parseArgs               Main                    283           1    0.0    0.0     0.0    0.0
    parseArgs.parse.ext    Main                    288           4    0.0    0.0     0.0    0.0
    parseArgs.parse        Main                    286           4    0.0    0.0     0.0    0.0
     parseArgs.parse.(...) Main                    287           4    0.0    0.0     0.0    0.0
 CAF:main1                 Main                    278           0    0.0    0.0     0.0    0.0
  main                     Main                    280           1    0.0    0.0     0.0    0.0
 CAF:parseArgs1            Main                    276           0    0.0    0.0     0.0    0.0
  parseArgs                Main                    284           0    0.0    0.0     0.0    0.0
 CAF:parseArgs2            Main                    275           0    0.0    0.0     0.0    0.0
  parseArgs                Main                    285           0    0.0    0.0     0.0    0.0
 CAF:lvl11_r8nQ            Main                    274           0    0.0    0.0     0.0    0.0
  parseArgs                Main                    289           0    0.0    0.0     0.0    0.0
   parseArgs.parse         Main                    290           0    0.0    0.0     0.0    0.0
 CAF:lvl9_r8nO             Main                    273           0    0.0    0.0     0.0    0.0
  action                   Main                    292           0    0.0    0.0     0.0    0.0
 CAF:lvl8_r8nN             Main                    272           0    0.0    0.0     0.0    0.0
  action                   Main                    293           0    0.0    0.0     0.0    0.0
 CAF:lvl7_r8nM             Main                    271           0    0.0    0.0     0.0    0.0
  action                   Main                    305           0    0.0    0.0     0.0    0.0
 CAF:lvl6_r8nJ             Main                    270           0    0.0    0.0     0.0    0.0
  action                   Main                    307           0    0.0    0.0     0.0    0.0
 CAF:lvl5_r8nI             Main                    269           0    0.0    0.0     3.3   18.6
  action                   Main                    294           0    0.0    0.0     3.3   18.6
   action.sink             Main                    300           0    0.0    0.0     3.3   18.6
    sink2                  Main                    301           0    3.3   18.6     3.3   18.6
 CAF:lvl4_r8nH             Main                    268           0    0.0    0.0     0.0    0.0
  action                   Main                    302           0    0.0    0.0     0.0    0.0
   token                   Main                    304           0    0.0    0.0     0.0    0.0
 CAF:ds1_r8nG              Main                    267           0    0.0    0.0     0.0    0.0
  action                   Main                    295           0    0.0    0.0     0.0    0.0
   action.sink             Main                    296           1    0.0    0.0     0.0    0.0
 CAF:lvl3_r8nF             Main                    266           0    0.0    0.0     3.2   15.8
  action                   Main                    297           0    0.0    0.0     3.2   15.8
   action.sink             Main                    298           0    0.0    0.0     3.2   15.8
    sink2                  Main                    299     1753746    3.2   15.8     3.2   15.8
 CAF:lvl2_r8nE             Main                    265           0    0.0    0.0     0.0    0.0
  action                   Main                    306           0    0.0    0.0     0.0    0.0
 CAF:lvl1_r8nD             Main                    264           0    0.0    0.0     0.0    0.0
  action                   Main                    308           0    0.0    0.0     0.0    0.0
 CAF:action6               Main                    263           0    0.0    0.0     0.0    0.0
 CAF:action11              Main                    262           0    0.0    0.0     0.0    0.0
 CAF:action7               Main                    260           0    0.0    0.0     0.0    0.0
 CAF:token1                Main                    251           0    0.0    0.0     0.0    0.0
  token                    Main                    303           1    0.0    0.0     0.0    0.0
 CAF:action8               Main                    249           0    0.0    0.0     0.0    0.0
 CAF                       GHC.Conc.Signal         183           0    0.0    0.0     0.0    0.0
 CAF                       GHC.IO.Encoding         178           0    0.0    0.0     0.0    0.0
 CAF                       GHC.IO.Encoding.Iconv   177           0    0.0    0.0     0.0    0.0
 CAF                       GHC.IO.Handle.FD        175           0    0.0    0.0     0.0    0.0
 CAF                       GHC.IO.FD               160           0    0.0    0.0     0.0    0.0

From gershomb at gmail.com  Thu Aug 28 18:30:59 2014
From: gershomb at gmail.com (Gershom B)
Date: Thu, 28 Aug 2014 14:30:59 -0400
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
 <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
 <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
Message-ID: <etPan.53ff7572.216231b.6c87@rm01-hl0fwz1.mhe.mhc>

On August 28, 2014 at 1:50:40 PM, Tikhon Jelvis (tikhon at jelv.is) wrote:

> I'm really not sure what the best noun to use is, but I'm leaning towards
> describing it as a mini convention or conference.

I agree that hackathon has come to mean something else. But mini-convention or conference doesn?t really capture the semi-spontaneous character of it, and something like ?community hack? or ?meetup? or ?hacker weekend? doesn?t capture that really lots of people do just show up and code all weekend long. ?unconference and skillshare? maybe, but that?s sort of goofy?

perhaps ?community hackathon? to capture both the ground-up unstructured character, and the fact that it centers around (no matter what else is going on) lots of people with computers, talking about and writing code in small groups?

-g



From alois.cochard at gmail.com  Thu Aug 28 18:39:59 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Thu, 28 Aug 2014 20:39:59 +0200
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
 <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
 <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
Message-ID: <CAJHA+woNCAp65iQdV01B5vK+kSqM3-o-tp6gH4R=uYbC5Af7oQ@mail.gmail.com>

I didn't realize there is such a competitive aspect in a "real" hackathon
(which, to be clear I never attended).

>From what I experienced at ZuriHac, I had the feeling there was two side to
the event. Certain persons where pretty much in the "getting-things-done",
taking the opportunity to be together and achieve great things in a small
amount of time.

Definitely not for the competitive aspect (at least I never felt it that
way), but more for getting things done.
There was other folks like me who actually didn't wrote much code, but
spend time discussing/socializing/helping/...

So I understand it's not sticly a hackathon, I think it would be nice to
have the word "community" in it as it's really what is at the core of such
event.



On 28 August 2014 19:50, Tikhon Jelvis <tikhon at jelv.is> wrote:

> I ran into this issue when telling people about Bay Hac. In college, at
> least, "hackathon" has acquired a pretty specific meaning: a *competitive*
> coding marathon, often with prizes. Bay Hac, on the other hand, was really
> more like a mini-conference: talks, sessions and lots of socializing, but
> no competitive aspect at all. (Personally, I like this quite a bit more
> than a normal hackathon!) I didn't want to send the wrong impression, but I
> also didn't know what else to call it except for "hackathon".
>
> Even though BayHac had *some* aspects of a hackathon, I still don't think
> it's a great description. If focuses on the wrong aspects. In my view, the
> most important parts of BayHac were educational and social, and it was
> incredibly valuable even if you didn't finish or even work on a project.
> This is pretty much the opposite of most actual hackathons I see; even when
> they have some focus on education, they still tend to be heavily
> "getting-things-done" project oriented.
>
> I'm really not sure what the best noun to use is, but I'm leaning towards
> describing it as a mini convention or conference.
>
>
> On Thu, Aug 28, 2014 at 7:23 AM, Brandon Allbery <allbery.b at gmail.com>
> wrote:
>
>> On Thu, Aug 28, 2014 at 10:19 AM, Alois Cochard <alois.cochard at gmail.com>
>> wrote:
>>
>>> In fact Zurihack felt pretty much like a coding marathon, I'm not sure
>>> if the "not sleeping" thing should be considered as part of the definition
>>> of a hackathon...
>>
>>
>> IMO it's not; the difference is one of focus, more specifically is there
>> one or a small number of specific projects or is there a larger slate of
>> things that one can pick and choose from and which may well change their
>> form based on participation *plus* unorganized gatherings
>> (socialization/"hallway track"). My "hacker-con" take on the second form
>> implicitly recognizes that the "hallway track" may well be as continuous as
>> it is at many other conventions....
>>
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/ef13efa6/attachment.html>

From tikhon at jelv.is  Thu Aug 28 19:00:12 2014
From: tikhon at jelv.is (Tikhon Jelvis)
Date: Thu, 28 Aug 2014 12:00:12 -0700
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <CAJHA+woNCAp65iQdV01B5vK+kSqM3-o-tp6gH4R=uYbC5Af7oQ@mail.gmail.com>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
 <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
 <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
 <CAJHA+woNCAp65iQdV01B5vK+kSqM3-o-tp6gH4R=uYbC5Af7oQ@mail.gmail.com>
Message-ID: <CAJN5CV+hDU2u3EXDwebhGG8cWZ89xuGhCi7UtVfksF7UbWnSXA@mail.gmail.com>

The meaning has narrowed in certain circles. Just like "meme" has come to
mean "picture with white text" to certain people, "hackathon" refers to a
more specific sort of event among college students (that I'm familiar
with). Many US universities have had small scale competitive hackathons in
the past, and now, after the success of PenApps, have adopted *very*
similar models for their events. So now that's what "hackathon" refers to:
working on a brand new project in a set time with little/no sleep followed
by some sort of presentations and judging. Pretty structured and
self-contained. And very different from the Haskell events!

It's also a bit tricky because the *Hac events are pretty different from
each other. BayHac and Hac ? felt similar in 2013, but both were very
different from BayHac 2014 (which I enjoyed the most of the three). Perhaps
it doesn't even make sense to use the same term for all of them, but then
I'm really not sure what to do!


On Thu, Aug 28, 2014 at 11:39 AM, Alois Cochard <alois.cochard at gmail.com>
wrote:

> I didn't realize there is such a competitive aspect in a "real" hackathon
> (which, to be clear I never attended).
>
> From what I experienced at ZuriHac, I had the feeling there was two side
> to the event. Certain persons where pretty much in the
> "getting-things-done", taking the opportunity to be together and achieve
> great things in a small amount of time.
>
> Definitely not for the competitive aspect (at least I never felt it that
> way), but more for getting things done.
> There was other folks like me who actually didn't wrote much code, but
> spend time discussing/socializing/helping/...
>
> So I understand it's not sticly a hackathon, I think it would be nice to
> have the word "community" in it as it's really what is at the core of such
> event.
>
>
>
> On 28 August 2014 19:50, Tikhon Jelvis <tikhon at jelv.is> wrote:
>
>> I ran into this issue when telling people about Bay Hac. In college, at
>> least, "hackathon" has acquired a pretty specific meaning: a *competitive*
>> coding marathon, often with prizes. Bay Hac, on the other hand, was really
>> more like a mini-conference: talks, sessions and lots of socializing, but
>> no competitive aspect at all. (Personally, I like this quite a bit more
>> than a normal hackathon!) I didn't want to send the wrong impression, but I
>> also didn't know what else to call it except for "hackathon".
>>
>> Even though BayHac had *some* aspects of a hackathon, I still don't think
>> it's a great description. If focuses on the wrong aspects. In my view, the
>> most important parts of BayHac were educational and social, and it was
>> incredibly valuable even if you didn't finish or even work on a project.
>> This is pretty much the opposite of most actual hackathons I see; even when
>> they have some focus on education, they still tend to be heavily
>> "getting-things-done" project oriented.
>>
>> I'm really not sure what the best noun to use is, but I'm leaning towards
>> describing it as a mini convention or conference.
>>
>>
>> On Thu, Aug 28, 2014 at 7:23 AM, Brandon Allbery <allbery.b at gmail.com>
>> wrote:
>>
>>> On Thu, Aug 28, 2014 at 10:19 AM, Alois Cochard <alois.cochard at gmail.com
>>> > wrote:
>>>
>>>> In fact Zurihack felt pretty much like a coding marathon, I'm not sure
>>>> if the "not sleeping" thing should be considered as part of the definition
>>>> of a hackathon...
>>>
>>>
>>> IMO it's not; the difference is one of focus, more specifically is there
>>> one or a small number of specific projects or is there a larger slate of
>>> things that one can pick and choose from and which may well change their
>>> form based on participation *plus* unorganized gatherings
>>> (socialization/"hallway track"). My "hacker-con" take on the second form
>>> implicitly recognizes that the "hallway track" may well be as continuous as
>>> it is at many other conventions....
>>>
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates
>>> allbery.b at gmail.com
>>> ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
>
> --
> *?\ois*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/9b969e0f/attachment-0001.html>

From michael at snoyman.com  Thu Aug 28 20:09:55 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Thu, 28 Aug 2014 23:09:55 +0300
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <20140828182752.GA10078@dev-auto.pittsburg.pmi>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+9gk3R0yozCe-SBRCGOxou0hQB1V_K=DnFmV2LbeUOdw@mail.gmail.com>
 <20140828182752.GA10078@dev-auto.pittsburg.pmi>
Message-ID: <CAKA2JgK2RngN4bu6kp-jhiA14YRnr6W7s-PfUHGj=hyyq=F20g@mail.gmail.com>

I just added a comment onto that issue. I forgot to mention that that
memory problem only occurs with optimizations turned on (-O or -O2). Can
you test it out with one of those flags and let me know what happens?

Your heap profile looks pretty similar to what I've been seeing as well,
thanks for providing it.


On Thu, Aug 28, 2014 at 9:27 PM, Bryan Vicknair <bryanvick at gmail.com> wrote:

> Michael,
>
> When I was first digging into this bug, I also ran into the case where
> doing an
> action twice would trigger a large increase in memory usage.  Also strange
> was
> that doing 'sequence_ [action]' was causing the problem for me, but 'do
> action'
> was not.
>
> Strangely enough though, on my machine there is no memory difference
> between
> running 'action' once or twice in your 1st example [1] in comment 4 of bug
> #9520.  Whether action is done once or twice, the maximum resident memory
> as
> reported by /usr/bin/time -v is about 1.1Mb.  I get roughly the same memory
> usage from the second code example in that same comment.
>
> Attached are the .prof and .hp files from running the 'mem' binary using
> sink2
> on my machine.
>
> Here is the output from the +RTS -s switch:
>
>    2,191,403,328 bytes allocated in the heap
>    4,269,946,560 bytes copied during GC
>      528,829,096 bytes maximum residency (21 sample(s))
>       21,830,752 bytes maximum slop
>             1070 MB total memory in use (0 MB lost due to fragmentation)
>
>                                     Tot time (elapsed)  Avg pause  Max
> pause
>   Gen  0      3826 colls,     0 par    0.37s    0.42s     0.0001s
> 0.0032s
>   Gen  1        21 colls,     0 par    4.02s   14.98s     0.7131s
> 7.6060s
>
>   INIT    time    0.00s  (  0.00s elapsed)
>   MUT     time    0.90s  (  6.22s elapsed)
>   GC      time    2.74s  ( 11.04s elapsed)
>   RP      time    0.00s  (  0.00s elapsed)
>   PROF    time    1.65s  (  4.35s elapsed)
>   EXIT    time    0.04s  (  0.05s elapsed)
>   Total   time    5.33s  ( 17.31s elapsed)
>
>   %GC     time      51.4%  (63.8% elapsed)
>
>   Alloc rate    2,432,664,887 bytes per MUT second
>
>   Productivity  17.6% of total user, 5.4% of total elapsed
>
>
> Bryan Vicknair
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/9520#comment:4
>
> On Thu, Aug 28, 2014 at 09:37:45AM +0300, Michael Snoyman wrote:
> > Can you provide the output from +RTS -s, as well as the heap profile for
> > -hy?
> >
> > I believe I'm now also reproducing the memory leak on conduit 1.2, so it
> > must have been a mistake in my testing last night when I thought 1.2
> fixed
> > it.
> >
> >
> > On Thu, Aug 28, 2014 at 8:58 AM, Bryan Vicknair <bryanvick at gmail.com>
> wrote:
> >
> > > Thanks for the interesting blog posts Michael.  I updated the example
> > > project
> > > [1] to use conduit 1.2.  Unfortunately, on my machine [2], my original
> > > sink2
> > > still uses about 500Mb of memory when processing 4 gzip files of about
> 5Mb
> > > each, while sink1 only uses about 8Mb.  I added sink3, which does the
> same
> > > as
> > > sink2 but uses fold from Conduit.List as you recommended, and that
> seems to
> > > work, using about 8Mb.
> > >
> > > Looking at the code for sink2 vs sink3, I don't understand what would
> be
> > > occupying so much memory in sink2 even in the case of expensive monadic
> > > binding, or exclusion from stream fusion.  I'm curious if sink2 adds
> > > thunks to
> > > the heap that sink3 doesn't, or if the GC is failing to clean up heap
> > > objects
> > > in sink2 that is cleans up in sink3.  I'm new at memory profiling, but
> the
> > > chart I get with '+RTS -h' or '+RTS -hr' basically just tells me that
> the
> > > action function is expensive.
> > >
> > > In the real project that inspired this example I'm going to do some
> > > cleanup,
> > > replacing manual recursion with higher-level functions from
> Conduit.List,
> > > as
> > > that seems like an all around good idea.
> > >
> > >
> > > Bryan Vicknair
> > >
> > > [1] https://bitbucket.org/bryanvick/conduit-mem
> > > [2] GHC 7.8.3, Arch Linux 3.16.1 kernel x86-64
> > >
> > >
> > > On Thu, Aug 28, 2014 at 07:00:41AM +0300, Michael Snoyman wrote:
> > > <snip>
> > > > But looking at the code again with fresher eyes than last night: I
> really
> > > > don't understand why it had such abysmal performance. I'll look into
> > > this a
> > > > bit more, looks like it should be interesting.
> > > >
> > > >
> > > > On Thu, Aug 28, 2014 at 1:39 AM, Dan Burton <
> danburton.email at gmail.com>
> > > > wrote:
> > > >
> > > > > Michael, I don't see how your code sample for (3) is any different
> to
> > > the
> > > > > compiler than Roman's original sink2.
> > > > >
> > > > > I also don't see how the original sink2 creates a bad bind tree. I
> > > presume
> > > > > that the reason "fold" works is due to the streaming optimization
> > > rule, and
> > > > > not due to its implementation, which looks almost identical to (3).
> > > > >
> > > > > I worry about using fold in this case, which is only strict up to
> WHNF,
> > > > > and therefore wouldn't necessarily force the integers in the
> tuples;
> > > > > instead it would create tons of integer thunks, wouldn't it?
> Roman's
> > > > > hand-coded sink2 avoids this issue so I presume that's not what is
> > > causing
> > > > > his memory woes.
> > > > >
> > > > > -- Dan Burton
> > > > >
> > > > >
> > > > > On Wed, Aug 27, 2014 at 2:55 PM, Roman Cheplyaka <roma at ro-che.info
> >
> > > wrote:
> > > > >
> > > > >> * Michael Snoyman <michael at snoyman.com> [2014-08-27
> 23:48:06+0300]
> > > > >> > > The problem is the following Sink, which counts how many
> even/odd
> > > > >> Tokens
> > > > >> > > are
> > > > >> > > seen:
> > > > >> > >
> > > > >> > >   type SinkState = (Integer, Integer)
> > > > >> > >
> > > > >> > >   sink2 :: (Monad m) => SinkState -> Sink Token m SinkState
> > > > >> > >   sink2 state@(!evenCount, !oddCount) = do
> > > > >> > >     maybeToken <- await
> > > > >> > >     case maybeToken of
> > > > >> > >       Nothing     -> return state
> > > > >> > >       (Just Even) -> sink2 (evenCount + 1, oddCount    )
> > > > >> > >       (Just Odd ) -> sink2 (evenCount    , oddCount + 1)
> > > > >> >
> > > > >> > Wow, talk about timing! What you've run into here is expensive
> > > monadic
> > > > >> > bindings. As it turns out, this is exactly what my blog post
> from
> > > last
> > > > >> > week[1] covered. You have three options to fix this:
> > > > >> >
> > > > >> > 1. Just upgrade to conduit 1.2.0, which I released a few hours
> ago,
> > > and
> > > > >> > uses the codensity transform to avoid the problem. (I just
> tested
> > > your
> > > > >> > code; you get constant memory usage under conduit 1.2.0,
> seemingly
> > > > >> without
> > > > >> > any code change necessary.)
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/e45bc6e1/attachment.html>

From haskell at with-h.at  Thu Aug 28 20:40:00 2014
From: haskell at with-h.at (Dominik Peteler)
Date: Thu, 28 Aug 2014 22:40:00 +0200
Subject: [Haskell-cafe] Problem finding rewrite rules
Message-ID: <20140828204000.GA4552@fuckup>

Dear Cafe,

I'm currently looking at the optimization GHC is doing and I cannot find
the rewrite rules it fires. When I run my test code with

    ghc -O2 -ddump-simpl-stats -ddump-rule-firings Main.hs

GHC shows the rules which are fired:

    ...
    Rule fired: Class op +
    ...
    Rule fired: +##
    ...

and so on. Nothing new, nothing special.
However, where do I find the definitions of these rules ?
I grepped[1] the GHC code base and found nothing so far. I didn't find any
documentation on it either.

Can anyone point me to some place where I can find further information ?

Thank you folks and have a nice day

Dominik

PS.: Since I'm working on numerical stable code with directed rounding
I'm only interested in these two particular rules. I suspect them to
break parts of my code.

[1] http://jamie-wong.com/2013/07/12/grep-test
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/7fe0a554/attachment.sig>

From mail at joachim-breitner.de  Thu Aug 28 21:34:43 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Aug 2014 14:34:43 -0700
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
Message-ID: <1409261683.9897.1.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 28.08.2014, 10:06 -0400 schrieb Richard Eisenberg:
> What do you think? Is this distinction pointless? Would being
> consistent about this difference help?

TBH, my impression is that this thread is searching for a shed to
color...


These events are all different anyways and people will have to look at
description to find out what _exactly_ they entail. Just leave it to the
organizer to name it however they want to.

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://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/8867431e/attachment.sig>

From carter.schonwald at gmail.com  Thu Aug 28 21:43:03 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Aug 2014 17:43:03 -0400
Subject: [Haskell-cafe] Problem finding rewrite rules
In-Reply-To: <20140828204000.GA4552@fuckup>
References: <20140828204000.GA4552@fuckup>
Message-ID: <CAHYVw0yXOjZi3y4=oGPH+9NrAEK8GjNHTv9qs973f1ca-PmgMQ@mail.gmail.com>

GHC has certain rules builtin for simplifying expressions wrt various
primops


On Thu, Aug 28, 2014 at 4:40 PM, Dominik Peteler <haskell at with-h.at> wrote:

> Dear Cafe,
>
> I'm currently looking at the optimization GHC is doing and I cannot find
> the rewrite rules it fires. When I run my test code with
>
>     ghc -O2 -ddump-simpl-stats -ddump-rule-firings Main.hs
>
> GHC shows the rules which are fired:
>
>     ...
>     Rule fired: Class op +
>     ...
>     Rule fired: +##
>     ...
>
> and so on. Nothing new, nothing special.
> However, where do I find the definitions of these rules ?
> I grepped[1] the GHC code base and found nothing so far. I didn't find any
> documentation on it either.
>
> Can anyone point me to some place where I can find further information ?
>
> Thank you folks and have a nice day
>
> Dominik
>
> PS.: Since I'm working on numerical stable code with directed rounding
> I'm only interested in these two particular rules. I suspect them to
> break parts of my code.
>
> [1] http://jamie-wong.com/2013/07/12/grep-test
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140828/6f72a8a9/attachment.html>

From ok at cs.otago.ac.nz  Thu Aug 28 22:37:29 2014
From: ok at cs.otago.ac.nz (Richard A. O'Keefe)
Date: Fri, 29 Aug 2014 10:37:29 +1200
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <etPan.53ff7572.216231b.6c87@rm01-hl0fwz1.mhe.mhc>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <CAJHA+wqkR6mU=nPqNthyEkE6scSkTsd1p0BU2-OLDiRa_Hk9+Q@mail.gmail.com>
 <CAKFCL4Xe-RvB=pmutMv9EVY+Ti6ZSoYL5kbBQg+wBOXkfAnoBw@mail.gmail.com>
 <CAJN5CVJGFctYJuh1_mv6qu0==nRppE555HguoCLisPufcLMMWg@mail.gmail.com>
 <etPan.53ff7572.216231b.6c87@rm01-hl0fwz1.mhe.mhc>
Message-ID: <055CBC31-3C23-4079-8E9E-AD0C60DB8230@cs.otago.ac.nz>


On 29/08/2014, at 6:30 AM, Gershom B wrote:

> On August 28, 2014 at 1:50:40 PM, Tikhon Jelvis (tikhon at jelv.is) wrote:
> 
>> I'm really not sure what the best noun to use is, but I'm leaning towards
>> describing it as a mini convention or conference.
> 
> I agree that hackathon has come to mean something else. But mini-convention or conference doesn?t really capture the semi-spontaneous character of it, and something like ?community hack? or ?meetup? or ?hacker weekend? doesn?t capture that really lots of people do just show up and code all weekend long. ?unconference and skillshare? maybe, but that?s sort of goofy?

Is this a "code retreat"?

I've never been to one, and have wondered how they work out.


From bryanvick at gmail.com  Thu Aug 28 23:06:15 2014
From: bryanvick at gmail.com (Bryan Vicknair)
Date: Thu, 28 Aug 2014 16:06:15 -0700
Subject: [Haskell-cafe] Conduit+GHC high memory use for simple Sink
In-Reply-To: <CAKA2JgK2RngN4bu6kp-jhiA14YRnr6W7s-PfUHGj=hyyq=F20g@mail.gmail.com>
References: <20140827181937.GA28786@dev-auto.pittsburg.pmi>
 <CAKA2Jg+9qxJvawaFk_cuRJoTOb4SOPGHqy7XFP4G7NX_6uy6kg@mail.gmail.com>
 <20140827215516.GA2678@sniper>
 <CALSygwfE-JAT1op+z9tSfp5sTDLaT30n6LymAh11MFybe8NqNA@mail.gmail.com>
 <CAKA2JgKLus0JR4SYUakLz=DDZL5hHrxwyCdJ-o=g5JjQZa3QcA@mail.gmail.com>
 <20140828055826.GA14212@x220.att.net>
 <CAKA2Jg+9gk3R0yozCe-SBRCGOxou0hQB1V_K=DnFmV2LbeUOdw@mail.gmail.com>
 <20140828182752.GA10078@dev-auto.pittsburg.pmi>
 <CAKA2JgK2RngN4bu6kp-jhiA14YRnr6W7s-PfUHGj=hyyq=F20g@mail.gmail.com>
Message-ID: <20140828230615.GB23700@dev-auto.pittsburg.pmi>

On Thu, Aug 28, 2014 at 11:09:55PM +0300, Michael Snoyman wrote:
> I just added a comment onto that issue. I forgot to mention that that
> memory problem only occurs with optimizations turned on (-O or -O2). Can
> you test it out with one of those flags and let me know what happens?

Wow, quite a large difference appears when using -O.  4Mb when the action is
run only once vs 789Mb when it is run twice.  What's interesting is that the
bytes allocated in the heap seems to grow by a reasonable amount when action is
run twice, but the total resident memory explodes.

The results when action is run only once:


   1,440,041,040 bytes allocated in the heap
         465,368 bytes copied during GC
          35,992 bytes maximum residency (2 sample(s))
          21,352 bytes maximum slop
               1 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      2756 colls,     0 par    0.01s    0.01s     0.0000s    0.0006s
  Gen  1         2 colls,     0 par    0.00s    0.00s     0.0001s    0.0001s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time    0.19s  (  0.19s elapsed)
  GC      time    0.01s  (  0.01s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time    0.20s  (  0.20s elapsed)

  %GC     time       6.0%  (5.3% elapsed)

  Alloc rate    7,563,673,522 bytes per MUT second

  Productivity  93.6% of total user, 93.5% of total elapsed

        Command being timed: "./foo +RTS -s"
        User time (seconds): 0.16
        System time (seconds): 0.03
        Percent of CPU this job got: 98%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.20
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 4024
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 338
        Voluntary context switches: 1
        Involuntary context switches: 21
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0


The results when action is run twice:


   2,080,041,040 bytes allocated in the heap
   1,346,503,136 bytes copied during GC
     389,736,000 bytes maximum residency (11 sample(s))
       8,871,312 bytes maximum slop
             768 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0      3968 colls,     0 par    0.28s    0.28s     0.0001s    0.0009s
  Gen  1        11 colls,     0 par    0.57s    0.57s     0.0519s    0.2668s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time    0.32s  (  0.32s elapsed)
  GC      time    0.85s  (  0.85s elapsed)
  EXIT    time    0.03s  (  0.03s elapsed)
  Total   time    1.20s  (  1.21s elapsed)

  %GC     time      71.0%  (70.7% elapsed)

  Alloc rate    6,553,280,639 bytes per MUT second

  Productivity  29.0% of total user, 28.8% of total elapsed

        Command being timed: "./foo +RTS -s"
        User time (seconds): 0.91
        System time (seconds): 0.28
        Percent of CPU this job got: 99%
        Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.20
        Average shared text size (kbytes): 0
        Average unshared data size (kbytes): 0
        Average stack size (kbytes): 0
        Average total size (kbytes): 0
        Maximum resident set size (kbytes): 789432
        Average resident set size (kbytes): 0
        Major (requiring I/O) page faults: 0
        Minor (reclaiming a frame) page faults: 196760
        Voluntary context switches: 1
        Involuntary context switches: 47
        Swaps: 0
        File system inputs: 0
        File system outputs: 0
        Socket messages sent: 0
        Socket messages received: 0
        Signals delivered: 0
        Page size (bytes): 4096
        Exit status: 0

From eir at cis.upenn.edu  Fri Aug 29 03:11:24 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 28 Aug 2014 23:11:24 -0400
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <1409261683.9897.1.camel@joachim-breitner.de>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <1409261683.9897.1.camel@joachim-breitner.de>
Message-ID: <BBE14557-5A8B-40F3-904C-72DEE929E916@cis.upenn.edu>


On Aug 28, 2014, at 5:34 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> TBH, my impression is that this thread is searching for a shed to
> color...

Though I started the thread, I agree somewhat with this conclusion. Of course all events are different and participants need to read the fine (or not-so-fine) print to learn more.

But, branding matters. I attended Hac NYC and Hac Boston over the past few months and enjoyed both a great deal. However, when I told non-Haskell friends that I attended "Haskell hackathons", I got several responses of the form "... and how many women were at these events?" It just got me thinking.

Anyway, it seems a fair conclusion to draw from these responses is that I should just do what I want -- there's no consensus to diverge from!

Thanks,
Richard

From jon at jonmsterling.com  Fri Aug 29 04:31:54 2014
From: jon at jonmsterling.com (Jon Sterling)
Date: Thu, 28 Aug 2014 21:31:54 -0700
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <BBE14557-5A8B-40F3-904C-72DEE929E916@cis.upenn.edu>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <1409261683.9897.1.camel@joachim-breitner.de>
 <BBE14557-5A8B-40F3-904C-72DEE929E916@cis.upenn.edu>
Message-ID: <1409286714.3706390.158062085.2DEC196E@webmail.messagingengine.com>

For what it's worth, I get super turned off at the first mention of
"hackathons" or even "hacking". Which is a shame, since the few
Haskell-related events I have been to which were billed as such were
really nothing of the sort, and were instead quite good! Just a few days
ago, I learned about Day convolution during a "hacking session", for
instance.

Kind regards,
Jon

On Thu, Aug 28, 2014, at 08:11 PM, Richard Eisenberg wrote:
> 
> On Aug 28, 2014, at 5:34 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > 
> > TBH, my impression is that this thread is searching for a shed to
> > color...
> 
> Though I started the thread, I agree somewhat with this conclusion. Of
> course all events are different and participants need to read the fine
> (or not-so-fine) print to learn more.
> 
> But, branding matters. I attended Hac NYC and Hac Boston over the past
> few months and enjoyed both a great deal. However, when I told
> non-Haskell friends that I attended "Haskell hackathons", I got several
> responses of the form "... and how many women were at these events?" It
> just got me thinking.
> 
> Anyway, it seems a fair conclusion to draw from these responses is that I
> should just do what I want -- there's no consensus to diverge from!
> 
> Thanks,
> Richard
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From stefan.wehr at gmail.com  Fri Aug 29 07:34:08 2014
From: stefan.wehr at gmail.com (Stefan Wehr)
Date: Fri, 29 Aug 2014 09:34:08 +0200
Subject: [Haskell-cafe] ANN: HacBerlin - Haskell Hackathon in Berlin,
	26-28 Sep 2014
Message-ID: <CAJAdMdFunfPM21WeKp-A47sDmdfFw13fvo=xTh6VUxeMwghgeA@mail.gmail.com>

Hi everyone,

this is just a quick reminder: The Haskell Hackathon in Berlin is
coming soon and there are still some places left. Please register now:
http://goo.gl/aLfnWu

The first keynote is also fixed; it will be given by Andres L?h
(http://www.andres-loeh.de/). Thanks, Andres!

Where: Berlin, Germany
When:  Fri 26 - Sun 28 September 2014

Meet in Berlin, discuss, hack together and improve the Haskell
infrastructure. We welcome all programmers interested in Haskell,
beginners and experts!

For all details, visit our wiki page
(http://www.haskell.org/haskellwiki/HacBerlin2014) and make sure to
register now!

Cheers,
Stefan

From ivan.perez at keera.co.uk  Fri Aug 29 09:33:30 2014
From: ivan.perez at keera.co.uk (Ivan Perez)
Date: Fri, 29 Aug 2014 11:33:30 +0200
Subject: [Haskell-cafe] ANN: Yampa 0.9.6
Message-ID: <540048EA.40306@keera.co.uk>

Hi Caf?,

I'm happy to announce that a new version of the Arrowized Functional 
Reactive Programming (FRP) library Yampa has been released.

This new version includes a lot of haddock documentation, finally 
addressing the old issue of having to browse a large collection of 
papers and the code to find information about the API. We would like to 
encourage users to submit issues on github if they find this 
documentation insufficient, unclear or otherwise unsuitable in any way.

There are no changes to the API itself, so this version remains 
backwards compatible. Future releases will seek to improve the 
documentation and introduce new optimisations as mandated by users' 
needs. As you may have heard, the current version is now working on 
Android, so we expect new releases to be published relatively soon.

Additionally, Henrik Nilsson will give a tutorial on Declarative Game 
Programming at PPDP 2014, which will take place in Canterbury (UK) on 
September 8-10 (http://users-cs.au.dk/danvy/ppdp14/). We would like to 
encourage everyone to attend (see PPDP web page for instructions, venue, 
etc.).

Links and more:

  *

    Hackage package: http://hackage.haskell.org/package/Yampa-0.9.6.

  *

    Github project page: https://github.com/ivanperez-keera/Yampa

  *

    Haskell Wiki page (examples, papers):
    http://www.haskell.org/haskellwiki/Yampa

  * Official announcement:
    http://fplab.bitbucket.org/posts/2014-08-29-yampa-0_9_6-released.html
  *

    (Another) Release announcement:
    http://keera.co.uk/blog/2014/08/29/new-version-yampa-0-9-6.

Cheers

Ivan

-- 
Facebook: https://www.facebook.com/keerastudios
Twitter: https://twitter.com/KeeraStudios
Web: http://www.keera.co.uk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140829/5a3e1618/attachment.html>

From konstantin.saveljev at gmail.com  Fri Aug 29 13:45:54 2014
From: konstantin.saveljev at gmail.com (Konstantin Saveljev)
Date: Fri, 29 Aug 2014 16:45:54 +0300
Subject: [Haskell-cafe] Master's thesis topic and mentor
Message-ID: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>

Hello,

*short summary*:

I am looking for someone who might have a topic for Master's thesis and
will be interested in mentoring me along the way (giving pointers, helping
here and there but not doing everything for me)

*more detailed*:

I have been introduced to Haskell about a year ago. It's been a slow ride,
but I am gaining knowledge step by step. I am having some difficulty in
finding a topic for my Master's degree and thought it would benefit me to
try doing something Haskell related (be it a library, some part of a
project or something similar). Unfortunately I do not believe I am able to
pick something up by myself. Therefore I am looking for someone out there
who might just have something to do they would be interested in delegating
to somebody else and helping a bit throughout that work (and it cannot be
something too easy, as there are some expectations from the work done for
Master's degree) . It might be a long shot but I believe it is worth
trying. Thank you for your time.

Best regards,
Konstantin Saveljev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140829/1cb37c94/attachment.html>

From alexander at plaimi.net  Fri Aug 29 14:18:42 2014
From: alexander at plaimi.net (Alexander Berntsen)
Date: Fri, 29 Aug 2014 16:18:42 +0200
Subject: [Haskell-cafe] Master's thesis topic and mentor
In-Reply-To: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
References: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
Message-ID: <54008BC2.9050509@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 29/08/14 15:45, Konstantin Saveljev wrote:
> I am looking for someone who might have a topic for Master's thesis
> and will be interested in mentoring me along the way (giving
> pointers, helping here and there but not doing everything for me)
Hallo Konstantin. I was in a similar position as you when I did my
Master Thesis. I made a game in Haskell & C++, and compared them. The
Thesis is available on GitHub[0].

The main point of my thesis was investigating the use of Haskell (or,
more generally, purely functional programming) for games (or, more
generally, programs traditionally associated with lots of state).

If you want to base your work on mine, I would be happy to help you.
It would be very cool to see more work on Haskell game programming.


[0]  <https://github.com/alexander-b/master-thesis>

- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlQAi8IACgkQRtClrXBQc7XG5wD+IMdgroTnyXuhhEvJHwtLLWny
RJpz4mNiGNqGw01cCuIA/AzkZZXKUFUE0G/AF3ezu0kEmUeugqR3cvMQZA5L3dSy
=GL6j
-----END PGP SIGNATURE-----

From ky3 at atamo.com  Fri Aug 29 14:43:39 2014
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Fri, 29 Aug 2014 21:43:39 +0700
Subject: [Haskell-cafe] Does web-based email harm mailman lists?
In-Reply-To: <20140801102544.GA6094@x60s.casa>
References: <CAPY+ZdQt0pCrGeWpT7dGanBG+KAXP1OBUXEpSYxMeiEP+RUvpA@mail.gmail.com>
 <20140801102544.GA6094@x60s.casa>
Message-ID: <CAPY+ZdTSOZZ6-aW9gPZJszwJw7-tDXdrk5v2-8J2TxVLk1iymg@mail.gmail.com>

Just to close the loop on this topic: In addition to the public email
below, I received another private one that suggests the same reservation
about being public and eternally archived on a public forum.

Notwithstanding the contrarieties of that position, the nays have it. Rest
assured status quo prevails.

On Fri, Aug 1, 2014 at 5:25 PM, Francesco Ariis <fa-ml at ariis.it> wrote:

> Yes, I am worried about private replies broadcast to the world (and
> archived
> on gmane, etc.).
>


-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140829/0c4293ff/attachment.html>

From horstmey at Mathematik.Uni-Marburg.de  Fri Aug 29 16:42:28 2014
From: horstmey at Mathematik.Uni-Marburg.de (Thomas Horstmeyer)
Date: Fri, 29 Aug 2014 18:42:28 +0200
Subject: [Haskell-cafe] Problem finding rewrite rules
In-Reply-To: <20140828204000.GA4552@fuckup>
References: <20140828204000.GA4552@fuckup>
Message-ID: <5400AD74.3080004@informatik.uni-marburg.de>

Grepping for "Class op" brought up a candidate for the first rule:

./compiler/basicTypes/MkId.lhs-313-
     -- This is the built-in rule that goes
     -- 	    op (dfT d1 d2) --->  opT d1 d2


A few other greps let me think that the other rule is probably one of 
those generated by the function primOpRules in 
./compiler/prelude/PrelRules.lhs which is called from 
./compiler/basicTypes/MkId.lhs:911
The following comment can be found in the file:

"Note [Constant folding]
~~~~~~~~~~~~~~~~~~~~~~~
primOpRules generates a rewrite rule for each primop
These rules do what is often called "constant folding"
E.g. the rules for +# might say
         4 +# 5 = 9
Well, of course you'd need a lot of rules if you did it
like that, so we use a BuiltinRule instead, so that we
can match in any two literal values.  So the rule is really
more like
         (Lit x) +# (Lit y) = Lit (x+#y)
where the (+#) on the rhs is done at compile time

That is why these rules are built in here."


Hope this helps,
Thomas


Am 28.08.2014 um 22:40 schrieb Dominik Peteler:
> Dear Cafe,
>
> I'm currently looking at the optimization GHC is doing and I cannot find
> the rewrite rules it fires. When I run my test code with
>
>      ghc -O2 -ddump-simpl-stats -ddump-rule-firings Main.hs
>
> GHC shows the rules which are fired:
>
>      ...
>      Rule fired: Class op +
>      ...
>      Rule fired: +##
>      ...
>
> and so on. Nothing new, nothing special.
> However, where do I find the definitions of these rules ?
> I grepped[1] the GHC code base and found nothing so far. I didn't find any
> documentation on it either.
>
> Can anyone point me to some place where I can find further information ?
>
> Thank you folks and have a nice day
>
> Dominik
>
> PS.: Since I'm working on numerical stable code with directed rounding
> I'm only interested in these two particular rules. I suspect them to
> break parts of my code.
>
> [1] http://jamie-wong.com/2013/07/12/grep-test
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

From alpmestan at gmail.com  Fri Aug 29 17:51:56 2014
From: alpmestan at gmail.com (Alp Mestanogullari)
Date: Fri, 29 Aug 2014 19:51:56 +0200
Subject: [Haskell-cafe] Master's thesis topic and mentor
In-Reply-To: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
References: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
Message-ID: <CADZnDvAKmYZaA4x0QEM7EanjKCK3cgQf9Bkn0zbpzueZ4CPKkg@mail.gmail.com>

Hello Konstantin!

I don't know what exactly you're looking for, but since you seem quite
open-minded about that... I may have something that could be of interest to
you. I don't know if you've heard about Accelerate [1], but my project
would use it. So if you're interested in working on haskell libraries that
generate smoking fast code to be run on GPUs (extending the accelerate
ecosystem, so to speak), shoot me an email (at the very same address this
email is coming from) :-)


[1] http://hackage.haskell.org/package/accelerate


On Fri, Aug 29, 2014 at 3:45 PM, Konstantin Saveljev <
konstantin.saveljev at gmail.com> wrote:

> Hello,
>
> *short summary*:
>
> I am looking for someone who might have a topic for Master's thesis and
> will be interested in mentoring me along the way (giving pointers, helping
> here and there but not doing everything for me)
>
> *more detailed*:
>
> I have been introduced to Haskell about a year ago. It's been a slow ride,
> but I am gaining knowledge step by step. I am having some difficulty in
> finding a topic for my Master's degree and thought it would benefit me to
> try doing something Haskell related (be it a library, some part of a
> project or something similar). Unfortunately I do not believe I am able to
> pick something up by myself. Therefore I am looking for someone out there
> who might just have something to do they would be interested in delegating
> to somebody else and helping a bit throughout that work (and it cannot be
> something too easy, as there are some expectations from the work done for
> Master's degree) . It might be a long shot but I believe it is worth
> trying. Thank you for your time.
>
> Best regards,
> Konstantin Saveljev
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140829/42b63eec/attachment.html>

From hjgtuyl at chello.nl  Fri Aug 29 21:27:24 2014
From: hjgtuyl at chello.nl (Henk-Jan van Tuyl)
Date: Fri, 29 Aug 2014 23:27:24 +0200
Subject: [Haskell-cafe] Master's thesis topic and mentor
In-Reply-To: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
References: <CAKncEjqU6=vm_oPZwog9eD8rE7WgaAj1hn5pwLQj_1+4x8U01Q@mail.gmail.com>
Message-ID: <op.xldhv2g0pz0j5l@alquantor>

On Fri, 29 Aug 2014 15:45:54 +0200, Konstantin Saveljev  
<konstantin.saveljev at gmail.com> wrote:

> I am looking for someone who might have a topic for Master's thesis

You can find suggestions for software to develop at:
  - http://www.reddit.com/r/haskell_proposals/
  -  
https://ghc.haskell.org/trac/summer-of-code/query?status=new&status=reopened&group=topic&order=priority&type=proposed-project&row=description

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 haskell at with-h.at  Fri Aug 29 22:16:12 2014
From: haskell at with-h.at (Dominik Peteler)
Date: Sat, 30 Aug 2014 00:16:12 +0200
Subject: [Haskell-cafe] Problem finding rewrite rules
In-Reply-To: <5400AD74.3080004@informatik.uni-marburg.de>
References: <20140828204000.GA4552@fuckup>
 <5400AD74.3080004@informatik.uni-marburg.de>
Message-ID: <20140829221612.GA20964@fuckup>

Hello Thomas,

thank you very much !
This is exactly what I was looking for.
Apparently I missed the match in MkId.hs.

Regards

Dominik



On Fri 2014-08-29 18:42, Thomas Horstmeyer wrote:
> Grepping for "Class op" brought up a candidate for the first rule:
> 
> ./compiler/basicTypes/MkId.lhs-313-
>     -- This is the built-in rule that goes
>     -- 	    op (dfT d1 d2) --->  opT d1 d2
> 
> 
> A few other greps let me think that the other rule is probably one of those
> generated by the function primOpRules in ./compiler/prelude/PrelRules.lhs
> which is called from ./compiler/basicTypes/MkId.lhs:911
> The following comment can be found in the file:
> 
> "Note [Constant folding]
> ~~~~~~~~~~~~~~~~~~~~~~~
> primOpRules generates a rewrite rule for each primop
> These rules do what is often called "constant folding"
> E.g. the rules for +# might say
>         4 +# 5 = 9
> Well, of course you'd need a lot of rules if you did it
> like that, so we use a BuiltinRule instead, so that we
> can match in any two literal values.  So the rule is really
> more like
>         (Lit x) +# (Lit y) = Lit (x+#y)
> where the (+#) on the rhs is done at compile time
> 
> That is why these rules are built in here."
> 
> 
> Hope this helps,
> Thomas
> 
> 
> Am 28.08.2014 um 22:40 schrieb Dominik Peteler:
> >Dear Cafe,
> >
> >I'm currently looking at the optimization GHC is doing and I cannot find
> >the rewrite rules it fires. When I run my test code with
> >
> >     ghc -O2 -ddump-simpl-stats -ddump-rule-firings Main.hs
> >
> >GHC shows the rules which are fired:
> >
> >     ...
> >     Rule fired: Class op +
> >     ...
> >     Rule fired: +##
> >     ...
> >
> >and so on. Nothing new, nothing special.
> >However, where do I find the definitions of these rules ?
> >I grepped[1] the GHC code base and found nothing so far. I didn't find any
> >documentation on it either.
> >
> >Can anyone point me to some place where I can find further information ?
> >
> >Thank you folks and have a nice day
> >
> >Dominik
> >
> >PS.: Since I'm working on numerical stable code with directed rounding
> >I'm only interested in these two particular rules. I suspect them to
> >break parts of my code.
> >
> >[1] http://jamie-wong.com/2013/07/12/grep-test
> >
> >
> >
> >_______________________________________________
> >Haskell-Cafe mailing list
> >Haskell-Cafe at haskell.org
> >http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/0d1c6e47/attachment.sig>

From jays at panix.com  Fri Aug 29 23:42:44 2014
From: jays at panix.com (Jay Sulzberger)
Date: Fri, 29 Aug 2014 19:42:44 -0400 (EDT)
Subject: [Haskell-cafe] "Hackathon"
In-Reply-To: <BBE14557-5A8B-40F3-904C-72DEE929E916@cis.upenn.edu>
References: <5FB8B636-3B77-47E9-B5EB-D8E73D8CF9A2@cis.upenn.edu>
 <1409261683.9897.1.camel@joachim-breitner.de>
 <BBE14557-5A8B-40F3-904C-72DEE929E916@cis.upenn.edu>
Message-ID: <Pine.NEB.4.64.1408291939310.2218@panix3.panix.com>




On Thu, 28 Aug 2014, Richard Eisenberg <eir at cis.upenn.edu> wrote:

>
> On Aug 28, 2014, at 5:34 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>
>> TBH, my impression is that this thread is searching for a shed to
>> color...
>
> Though I started the thread, I agree somewhat with this
> conclusion. Of course all events are different and participants
> need to read the fine (or not-so-fine) print to learn more.
>
> But, branding matters. I attended Hac NYC and Hac Boston over
> the past few months and enjoyed both a great deal. However,
> when I told non-Haskell friends that I attended "Haskell
> hackathons", I got several responses of the form "... and how
> many women were at these events?" It just got me thinking.
>
> Anyway, it seems a fair conclusion to draw from these responses
> is that I should just do what I want -- there's no consensus to
> diverge from!
>
> Thanks,
> Richard

Traditionally in New York City some people call the gathering
without hard agenda a "Hack Fest".

oo--JS.

From nikoamia at gmail.com  Sat Aug 30 07:44:45 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Sat, 30 Aug 2014 11:44:45 +0400
Subject: [Haskell-cafe] Using 'lens' for "over"-like computation in Monad
Message-ID: <CA+waHKU1CqFB_6uzi8Hujn+ZqO-WDW6HE37WO=-wouPNyTCXMg@mail.gmail.com>

Hello Cafe,

I'm trying to wrap my head around 'lens' library. My current exercise is to
modify something using Lens in monad. Say,

("Hello", "World") & _1 `myOp` (\a -> putStrLn a >> return a)

in IO, where myOp would be of type:

myOp :: Monad m => Lens s t a b -> (a -> m b) -> s -> m t

Of course I can write it myself, using combination of "view" and "set":

myOp lens f v = f (view lens v) >>= flip (set lens) v

(have not checked this, but something like that should do), but is there a
more elegant way?

Nikolay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/b8c0d61b/attachment.html>

From nikoamia at gmail.com  Sat Aug 30 08:30:01 2014
From: nikoamia at gmail.com (Nikolay Amiantov)
Date: Sat, 30 Aug 2014 12:30:01 +0400
Subject: [Haskell-cafe] Using 'lens' for "over"-like computation in Monad
In-Reply-To: <CALpAkBNMFc_hzZCDew51BgC509K+=HSU=+jRwVKDNHfa6RVNLg@mail.gmail.com>
References: <CA+waHKU1CqFB_6uzi8Hujn+ZqO-WDW6HE37WO=-wouPNyTCXMg@mail.gmail.com>
 <CALpAkBNMFc_hzZCDew51BgC509K+=HSU=+jRwVKDNHfa6RVNLg@mail.gmail.com>
Message-ID: <CA+waHKWV2ecuJvdrf74MdLPc1ovEM+T9CKQq4egxYe0n6Rn=rQ@mail.gmail.com>

Thank you! I'm still lost in the forest of all lens functions and
generality, and haven't expected this signature. Can someone recommend good
reading on all the lens-related types and classes,  what they represent and
how can they be used? (interested not only in "how", but also "why")
30 ???. 2014 ?. 11:20 ???????????? "Benno F?nfst?ck" <
benno.fuenfstueck at gmail.com> ???????:

> The lens operator that does this is %%~, also called `traverseOf`:
>
> ?: ("Hello", "World") & _1 %%~ (\a -> putStrLn a >> return a)
> Hello
> ("Hello","World")
>
> Also see the documentation:
> http://hackage.haskell.org/package/lens-4.4.0.1/docs/Control-Lens-Traversal.html#v:traverseOf
>
> --
> Benno
>
>
> 2014-08-30 9:44 GMT+02:00 Nikolay Amiantov <nikoamia at gmail.com>:
>
>> Hello Cafe,
>>
>> I'm trying to wrap my head around 'lens' library. My current exercise is
>> to modify something using Lens in monad. Say,
>>
>> ("Hello", "World") & _1 `myOp` (\a -> putStrLn a >> return a)
>>
>> in IO, where myOp would be of type:
>>
>> myOp :: Monad m => Lens s t a b -> (a -> m b) -> s -> m t
>>
>> Of course I can write it myself, using combination of "view" and "set":
>>
>> myOp lens f v = f (view lens v) >>= flip (set lens) v
>>
>> (have not checked this, but something like that should do), but is there
>> a more elegant way?
>>
>> Nikolay.
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/971fc2bf/attachment.html>

From roma at ro-che.info  Sat Aug 30 10:24:22 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sat, 30 Aug 2014 13:24:22 +0300
Subject: [Haskell-cafe] ICFP pre-party
Message-ID: <20140830102422.GA8335@sniper>

We're having a small unofficial ICFP pre-party today in Gothenburg. All
haskell-cafe readers that happen to be in Gothenburg are welcome :-)

The plan is to meet at The Bishop's Arms (Kungsportsavenyen 36) at 19.00.

NOTE: there are three Bishop's Arms in Gothenburg, so mind the address.

Feel free to text me at +380662285780.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/276a37f4/attachment.sig>

From carter.schonwald at gmail.com  Sat Aug 30 11:10:49 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 30 Aug 2014 07:10:49 -0400
Subject: [Haskell-cafe] ICFP pre-party
In-Reply-To: <20140830102422.GA8335@sniper>
References: <20140830102422.GA8335@sniper>
Message-ID: <CAHYVw0xLqbREmgwkodxrvZxyF0ZeAeByfp4D1FD=9xi+JM0dWQ@mail.gmail.com>

I'm at icfp now. Don't have local texting setup yet though.

On Saturday, August 30, 2014, Roman Cheplyaka <roma at ro-che.info> wrote:

> We're having a small unofficial ICFP pre-party today in Gothenburg. All
> haskell-cafe readers that happen to be in Gothenburg are welcome :-)
>
> The plan is to meet at The Bishop's Arms (Kungsportsavenyen 36) at 19.00.
>
> NOTE: there are three Bishop's Arms in Gothenburg, so mind the address.
>
> Feel free to text me at +380662285780.
>
> Roman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/33c86ab3/attachment.html>

From alois.cochard at gmail.com  Sat Aug 30 13:50:06 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Sat, 30 Aug 2014 15:50:06 +0200
Subject: [Haskell-cafe] ICFP pre-party
In-Reply-To: <CAHYVw0xLqbREmgwkodxrvZxyF0ZeAeByfp4D1FD=9xi+JM0dWQ@mail.gmail.com>
References: <20140830102422.GA8335@sniper>
 <CAHYVw0xLqbREmgwkodxrvZxyF0ZeAeByfp4D1FD=9xi+JM0dWQ@mail.gmail.com>
Message-ID: <CAJHA+woUCEoLjFT3hTwqD6qwin3JfGzgjHQtPh1CyXP2uD4haw@mail.gmail.com>

Funnily enough, I'm already drinking beer and writing Haskell code in that
pub!

See you later


On 30 August 2014 13:10, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I'm at icfp now. Don't have local texting setup yet though.
>
>
> On Saturday, August 30, 2014, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>> We're having a small unofficial ICFP pre-party today in Gothenburg. All
>> haskell-cafe readers that happen to be in Gothenburg are welcome :-)
>>
>> The plan is to meet at The Bishop's Arms (Kungsportsavenyen 36) at 19.00.
>>
>> NOTE: there are three Bishop's Arms in Gothenburg, so mind the address.
>>
>> Feel free to text me at +380662285780.
>>
>> Roman
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/2147752f/attachment.html>

From carter.schonwald at gmail.com  Sat Aug 30 14:24:12 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 30 Aug 2014 10:24:12 -0400
Subject: [Haskell-cafe] ICFP pre-party
In-Reply-To: <CAJHA+woUCEoLjFT3hTwqD6qwin3JfGzgjHQtPh1CyXP2uD4haw@mail.gmail.com>
References: <20140830102422.GA8335@sniper>
 <CAHYVw0xLqbREmgwkodxrvZxyF0ZeAeByfp4D1FD=9xi+JM0dWQ@mail.gmail.com>
 <CAJHA+woUCEoLjFT3hTwqD6qwin3JfGzgjHQtPh1CyXP2uD4haw@mail.gmail.com>
Message-ID: <CAHYVw0wDK3WNvGQYAh=EaV+KWifKuZwVXZNkKcD7Gc87cARgFw@mail.gmail.com>

hah, well, i have a local sim now, so I can wander and not get lost!
i might be meeting other folks this evening though, but i'll be around!


On Sat, Aug 30, 2014 at 9:50 AM, Alois Cochard <alois.cochard at gmail.com>
wrote:

> Funnily enough, I'm already drinking beer and writing Haskell code in that
> pub!
>
> See you later
>
>
> On 30 August 2014 13:10, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> I'm at icfp now. Don't have local texting setup yet though.
>>
>>
>> On Saturday, August 30, 2014, Roman Cheplyaka <roma at ro-che.info> wrote:
>>
>>> We're having a small unofficial ICFP pre-party today in Gothenburg. All
>>> haskell-cafe readers that happen to be in Gothenburg are welcome :-)
>>>
>>> The plan is to meet at The Bishop's Arms (Kungsportsavenyen 36) at 19.00.
>>>
>>> NOTE: there are three Bishop's Arms in Gothenburg, so mind the address.
>>>
>>> Feel free to text me at +380662285780.
>>>
>>> Roman
>>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> *?\ois*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/c69b897a/attachment.html>

From iricanaycan at gmail.com  Sat Aug 30 14:36:54 2014
From: iricanaycan at gmail.com (Aycan iRiCAN)
Date: Sat, 30 Aug 2014 16:36:54 +0200
Subject: [Haskell-cafe] ICFP pre-party
In-Reply-To: <20140830102422.GA8335@sniper>
References: <20140830102422.GA8335@sniper>
Message-ID: <CAA23_nrn0VEm-SUbmB=mxvsAg6kgaPnU-LhgvE3Zr4ft9Ci7rw@mail.gmail.com>

This is my first time in ICFP and I really want to attend your pre-party.
On Aug 30, 2014 12:24 PM, "Roman Cheplyaka" <roma at ro-che.info> wrote:

> We're having a small unofficial ICFP pre-party today in Gothenburg. All
> haskell-cafe readers that happen to be in Gothenburg are welcome :-)
>
> The plan is to meet at The Bishop's Arms (Kungsportsavenyen 36) at 19.00.
>
> NOTE: there are three Bishop's Arms in Gothenburg, so mind the address.
>
> Feel free to text me at +380662285780.
>
> Roman
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/8b2031c6/attachment.html>

From alois.cochard at gmail.com  Sat Aug 30 15:23:24 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Sat, 30 Aug 2014 17:23:24 +0200
Subject: [Haskell-cafe] [ANN] codex 0.1.0.4
Message-ID: <CAJHA+woa3Jk3nTy7QbxhKfK-+XgmYGKm+x-f2XyRmZq4NAmGSw@mail.gmail.com>

Hi Cafe,

I just wanted to let you know that I have just released a new version of
`codex` on hackage.

There is *no new features* in this version, but thanks for the help from
Hubert Behaghel I was able to investigate issues with MacOS.

So basically this version now work with MacOS, if you had give a try before
please delete your "~/.codex" configuration file before installing the new
version.

Cheers

-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/6bc0629e/attachment.html>

From timotej.tomandl at gmail.com  Sat Aug 30 18:28:34 2014
From: timotej.tomandl at gmail.com (Timotej Tomandl)
Date: Sat, 30 Aug 2014 20:28:34 +0200
Subject: [Haskell-cafe] Fwd: Linear regions ("Linear Regions Are All You
 Need") as the only way of encapsulation of impure state
In-Reply-To: <CAEQuBgDaLOe7LsuJeXKmjzp167LoeuKraqrf0ajKw4G5qxdTQQ@mail.gmail.com>
References: <CAEQuBgDaLOe7LsuJeXKmjzp167LoeuKraqrf0ajKw4G5qxdTQQ@mail.gmail.com>
Message-ID: <CAEQuBgBQdXerB=jkY4XR_pKaZ+-pjLF4dCxm+t72zh-3Q55nGA@mail.gmail.com>

I was thinking for a while about if other kinds of handling of impure state
have any advantages over linear regions. So I thought it will be nice to
open the discussion  about how does it compare with monads, linear types,
uniqueness typing and monadic regions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/2ff95ac6/attachment.html>

From timotej.tomandl at gmail.com  Sat Aug 30 19:36:41 2014
From: timotej.tomandl at gmail.com (Timotej Tomandl)
Date: Sat, 30 Aug 2014 12:36:41 -0700 (PDT)
Subject: [Haskell-cafe] Monads vs Linear regions
Message-ID: <79b9f15c-c667-4dae-b617-b1564e552c82@googlegroups.com>

How do they compare? Can Linear regions handle all uses of monads or does 
they lack some applications?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140830/4d35acaa/attachment.html>

From redneb8888 at gmail.com  Sun Aug 31 04:45:28 2014
From: redneb8888 at gmail.com (Marios Titas)
Date: Sun, 31 Aug 2014 05:45:28 +0100
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
Message-ID: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>

I am trying to run cabal sdist on a package where one of exposed
modules does not exists because it is automatically generated by
setup.hs. cabal refuses to do that because it cannot find the file
corresponding to that module. Is there a solution to that problem? The
package builds just fine.

From fuuzetsu at fuuzetsu.co.uk  Sun Aug 31 13:50:28 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 31 Aug 2014 14:50:28 +0100
Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0,
	haddock-library-1.1.1
Message-ID: <54032824.103@fuuzetsu.co.uk>

Hello,

I'd like to announce the release of Haddock 2.15.0. Before we dive in,
I'd like to announce that Haddock development has moved out of the GHC
tree and is now done against the latest compiler release. If in the past
you wanted to contribute but were intimidated by having to make sure it
works against GHC HEAD then here's your chance. Additionally, it now
should also work with GHC 7.8.2 so if for whatever reason you're forced
to use that, you can now get the latest Haddock features.

If you want to contribute then please let us know, we're understaffed!
Come chat at #haddock or send us an e-mail.

If you have been using 2.14.x, you should be good to simply ?cabal
install haddock?.

Now the changes:

This is an API-breaking bugfix release so any tickets originally
scheduled for 2.15.0 were pushed towards 2.16. Perhaps the biggest
change is that ?cabal install haddock? will now only give you the
Haddock binary. To use Haddock API, please depend on ?haddock-api? from
now on. I have sent out an e-mail about this couple of weeks in advance
to any reverse dependencies of ?haddock?. This is to workaround cabal's
inability to pass flags to dependencies from the cabal file.

?haddock-library? only got a minor bump, 1.1.0 ? 1.1.1 improving its
output. The Monoid instance for DocH is gone however as it was
ill-formed to begin with.

Changes in version 2.15.0

 * Always read in prologue files as UTF8 (#286 and Cabal #1721)

 * parser: don't wrap headers in DocParagraph (#307)

 * parser: don't mangle append order for nested lists (pandoc #1346)

 * parser: preserve list ordering in certain scenarios (#313)

 * parser: update the attoparsec version used internally giving slight
   parsing performance boost.

 * Move development to be against latest GHC release and not GHC HEAD.

 * Further split up the package to separate the executable from the
   library, necessary by things like GHCJS. We now have
   ?haddock-library? which are the parts that don't use GHC API,
   ?haddock-api? which are (some of) the parts that do use GHC API and
   ?haddock? which merely provides the executable.

 * Export few extra functions in the API.

 * Add compatibility with GHC 7.8.2.

 * Omit unnecessary ?forall?s (#315 and #86)

 * Remove some files which were really old or did not belong in the
   repository in the first place.


Once again, we'd love to have more people on board be it for the HTML
backend, refactoring, LaTeX/Hoogle backend, parser improvements, test
writing, new feature implementation or bug fixing. Our issue tracker[1]
is up to date if you are interested.

Thanks!

[1]: https://github.com/haskell/haddock/issues

-- 
Mateusz K.

From fuuzetsu at fuuzetsu.co.uk  Sun Aug 31 13:57:57 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 31 Aug 2014 14:57:57 +0100
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
In-Reply-To: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>
References: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>
Message-ID: <540329E5.3020300@fuuzetsu.co.uk>

On 08/31/2014 05:45 AM, Marios Titas wrote:
> I am trying to run cabal sdist on a package where one of exposed
> modules does not exists because it is automatically generated by
> setup.hs. cabal refuses to do that because it cannot find the file
> corresponding to that module. Is there a solution to that problem? The
> package builds just fine.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 


Does touch missingmodule.hs not do it for you?

-- 
Mateusz K.

From allbery.b at gmail.com  Sun Aug 31 14:11:39 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 31 Aug 2014 10:11:39 -0400
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
In-Reply-To: <540329E5.3020300@fuuzetsu.co.uk>
References: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>
 <540329E5.3020300@fuuzetsu.co.uk>
Message-ID: <CAKFCL4VS3hWQ9bFqNSzA4m9Te4gM6Z+uaRziRK7bR25j3JL3nw@mail.gmail.com>

On Sun, Aug 31, 2014 at 9:57 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> On 08/31/2014 05:45 AM, Marios Titas wrote:
> > I am trying to run cabal sdist on a package where one of exposed
> > modules does not exists because it is automatically generated by
> > setup.hs. cabal refuses to do that because it cannot find the file
> > corresponding to that module. Is there a solution to that problem? The
> > package builds just fine.
>
> Does touch missingmodule.hs not do it for you?
>

Sounds like a bad idea, it would mean instead of generating the module it
would take the empty file as the generated module and probably fail to
build?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140831/91d643af/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Sun Aug 31 14:13:25 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 31 Aug 2014 15:13:25 +0100
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
In-Reply-To: <CAKFCL4VS3hWQ9bFqNSzA4m9Te4gM6Z+uaRziRK7bR25j3JL3nw@mail.gmail.com>
References: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>	<540329E5.3020300@fuuzetsu.co.uk>
 <CAKFCL4VS3hWQ9bFqNSzA4m9Te4gM6Z+uaRziRK7bR25j3JL3nw@mail.gmail.com>
Message-ID: <54032D85.2050801@fuuzetsu.co.uk>

On 08/31/2014 03:11 PM, Brandon Allbery wrote:
> On Sun, Aug 31, 2014 at 9:57 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
> wrote:
> 
>> On 08/31/2014 05:45 AM, Marios Titas wrote:
>>> I am trying to run cabal sdist on a package where one of exposed
>>> modules does not exists because it is automatically generated by
>>> setup.hs. cabal refuses to do that because it cannot find the file
>>> corresponding to that module. Is there a solution to that problem? The
>>> package builds just fine.
>>
>> Does touch missingmodule.hs not do it for you?
>>
> 
> Sounds like a bad idea, it would mean instead of generating the module it
> would take the empty file as the generated module and probably fail to
> build?
> 

Presumably setup.hs would take care to delete the ?fake? file with the
actual generated file at build time.

-- 
Mateusz K.

From redneb8888 at gmail.com  Sun Aug 31 14:16:54 2014
From: redneb8888 at gmail.com (Marios Titas)
Date: Sun, 31 Aug 2014 15:16:54 +0100
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
In-Reply-To: <54032D85.2050801@fuuzetsu.co.uk>
References: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>
 <540329E5.3020300@fuuzetsu.co.uk>
 <CAKFCL4VS3hWQ9bFqNSzA4m9Te4gM6Z+uaRziRK7bR25j3JL3nw@mail.gmail.com>
 <54032D85.2050801@fuuzetsu.co.uk>
Message-ID: <CAAdM647tfLqnKDkt0bfM272SxygyxDesaEQBjA82X8OGz0-vLQ@mail.gmail.com>

Yes, including an empty (or dummy) file causes cabal build to fail
because it apparently prefers that file over the generated one in the
autogen directory.

On Sun, Aug 31, 2014 at 3:13 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 08/31/2014 03:11 PM, Brandon Allbery wrote:
>> On Sun, Aug 31, 2014 at 9:57 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
>> wrote:
>>
>>> On 08/31/2014 05:45 AM, Marios Titas wrote:
>>>> I am trying to run cabal sdist on a package where one of exposed
>>>> modules does not exists because it is automatically generated by
>>>> setup.hs. cabal refuses to do that because it cannot find the file
>>>> corresponding to that module. Is there a solution to that problem? The
>>>> package builds just fine.
>>>
>>> Does touch missingmodule.hs not do it for you?
>>>
>>
>> Sounds like a bad idea, it would mean instead of generating the module it
>> would take the empty file as the generated module and probably fail to
>> build?
>>
>
> Presumably setup.hs would take care to delete the ?fake? file with the
> actual generated file at build time.
>
> --
> Mateusz K.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

From fuuzetsu at fuuzetsu.co.uk  Sun Aug 31 14:17:15 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 31 Aug 2014 15:17:15 +0100
Subject: [Haskell-cafe] [ANN] igrf-0.2
In-Reply-To: <CACruqwS4CBMmt9Nt4=kUs6741wyJGYFgR9uSy=hMc+F8O6+G8g@mail.gmail.com>
References: <CACruqwS4CBMmt9Nt4=kUs6741wyJGYFgR9uSy=hMc+F8O6+G8g@mail.gmail.com>
Message-ID: <54032E6B.5080107@fuuzetsu.co.uk>

On 08/25/2014 12:35 AM, Douglas McClean wrote:
> igrf is a library that provides an implementation of the International
> Geomagnetic Reference Field, which is just what it sounds like.
> 
> I've tested it against NOAA's online calculator, but use it at your own
> risk. Note that the input is in geocentric and not geodetic coordinates.
> 
> There is haddock documentation, I'm working on figuring out why it isn't on
> hackage and how to fix it.
> 
> -Doug McClean
> 

[1] and its follow-up post may be of use to you or you can skip ahead
and just use the script at [2] to upload your own docs.

[1]:
http://fuuzetsu.co.uk/blog/posts/2014-01-06-Fix-your-Hackage-documentation.html
[2]: https://gist.github.com/Fuuzetsu/8276421
-- 
Mateusz K.

From sergueyz at gmail.com  Sun Aug 31 14:55:09 2014
From: sergueyz at gmail.com (Serguey Zefirov)
Date: Sun, 31 Aug 2014 18:55:09 +0400
Subject: [Haskell-cafe] RTS options to control name of eventlog file.
Message-ID: <CABFQQ=CkAaBjHdCKn1u4FNr+TG32r-8ubS3QLhZJkSNY77kxtw@mail.gmail.com>

Is there any?

Because when running and profiling two same programs they will write into
same eventlog file. Not a good situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140831/f0cc75eb/attachment.html>

From mail at nh2.me  Sun Aug 31 16:09:52 2014
From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=)
Date: Sun, 31 Aug 2014 18:09:52 +0200
Subject: [Haskell-cafe] ANNOUNCE: hemokit 0.6.3 - Now with OpenVibe
	compatibility
Message-ID: <540348D0.6020004@nh2.me>

Heya,

out is Hemokit 0.6.3, which can now be connected to the OpenVibe EEG
framework.

OpenVibe allows fancy stuff like spelling words with your mind:
  Video: https://www.youtube.com/watch?v=08GNE6OdNcs
  Docs: http://openvibe.inria.fr/coadapt-p300-stimulator-tutorial

There is a new tutorial on how to set up Hemokit+OpenVibe at:
  https://github.com/nh2/hemokit/wiki/OpenVibe

If you set up something cool with that, don't forget to tell me about it!

Grab Hemokit:
  https://hackage.haskell.org/package/hemokit

Stand-alone Linux and Windows binaries are also available:
  https://github.com/nh2/hemokit/releases

From redneb8888 at gmail.com  Sun Aug 31 16:28:06 2014
From: redneb8888 at gmail.com (Marios Titas)
Date: Sun, 31 Aug 2014 17:28:06 +0100
Subject: [Haskell-cafe] cabal sdist and auto-generated modules
In-Reply-To: <CAAdM647tfLqnKDkt0bfM272SxygyxDesaEQBjA82X8OGz0-vLQ@mail.gmail.com>
References: <CAAdM645ERgdNSu-g4KmGbJZKUzBQtsSmBmKzBeS1zpETEpX7pQ@mail.gmail.com>
 <540329E5.3020300@fuuzetsu.co.uk>
 <CAKFCL4VS3hWQ9bFqNSzA4m9Te4gM6Z+uaRziRK7bR25j3JL3nw@mail.gmail.com>
 <54032D85.2050801@fuuzetsu.co.uk>
 <CAAdM647tfLqnKDkt0bfM272SxygyxDesaEQBjA82X8OGz0-vLQ@mail.gmail.com>
Message-ID: <CAAdM646JoO1EL31ryfqVw0wn3hEHcRCZ2-EZJdiADUJinaGVwg@mail.gmail.com>

Also, isn't this a bad practice? I think setup.hs should not modify
the source tree in any way, it should only create/modify files in the
dist/ directory.

On Sun, Aug 31, 2014 at 3:16 PM, Marios Titas <redneb8888 at gmail.com> wrote:
> Yes, including an empty (or dummy) file causes cabal build to fail
> because it apparently prefers that file over the generated one in the
> autogen directory.
>
> On Sun, Aug 31, 2014 at 3:13 PM, Mateusz Kowalczyk
> <fuuzetsu at fuuzetsu.co.uk> wrote:
>> On 08/31/2014 03:11 PM, Brandon Allbery wrote:
>>> On Sun, Aug 31, 2014 at 9:57 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
>>> wrote:
>>>
>>>> On 08/31/2014 05:45 AM, Marios Titas wrote:
>>>>> I am trying to run cabal sdist on a package where one of exposed
>>>>> modules does not exists because it is automatically generated by
>>>>> setup.hs. cabal refuses to do that because it cannot find the file
>>>>> corresponding to that module. Is there a solution to that problem? The
>>>>> package builds just fine.
>>>>
>>>> Does touch missingmodule.hs not do it for you?
>>>>
>>>
>>> Sounds like a bad idea, it would mean instead of generating the module it
>>> would take the empty file as the generated module and probably fail to
>>> build?
>>>
>>
>> Presumably setup.hs would take care to delete the ?fake? file with the
>> actual generated file at build time.
>>
>> --
>> Mateusz K.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

From fuuzetsu at fuuzetsu.co.uk  Sun Aug 31 20:04:21 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sun, 31 Aug 2014 21:04:21 +0100
Subject: [Haskell-cafe] LFM for Haskell bittorrent effort
Message-ID: <54037FC5.7020101@fuuzetsu.co.uk>

Hi,

For this or another reason, no bittorrent libraries/clients available
today seem to suit my needs: they are either too slow, too memory
inefficient, bundled with a client which often can't run in a headless
environment or broken in some other way or don't implement all the
common BEPs. I came to the conclusion that I'll probably have to write
one. Happily, whenever I mentioned the topic in #haskell, there was
quite a bit of interest each time so I'm looking to recruit people to
join me in this effort.

First a brief overlook of what's already available in the Haskell
environment:

* Combinatorrent[1] ? a rather old client, no longer maintained with the
last Hackage upload in 2010. Only supports few BEPs and was not able to
load in the .torrent file provided by Ubuntu. I have spoken to jlouis
who wrote this, you can read the conversation at [2]. He himself says
that nowadays you can do better performance wise with available
libraries. Additionally, this comes with a client on top rather than
just being a library.

* conjure ? not touched since 2008

* bittorrent ? seems to be the closest to what I'd like but it is still
incomplete and the library is in limbo. There is a lot of stuff that
does not work or is commented out and for various reasons the maintainer
is unavailable to help out. I have spoken to the maintainer and he
himself would like to redesign the library.


That's about it. There seem to be a few related tools for bencoding &c
but nothing huge. I think the best way to go about this is to learn from
Combinatorrent and bittorrent and start something fresh.

I'll outline the goals I personally am looking for even though they
might be obvious:

* efficient, scalable ? the library needs to be able to handle tens of
thousands of active (announcing, not necessarily downloading) torrents
at once. For reference, libtorrent-rakshasa + rtorrent is able to run
about ~10k torrents in about 1GB of memory with low CPU usage. The
downside is that the library crashes like no tomorrow and the client
itself sucks. A slow library is useless to me but so is a fast but
unstable one.

* implements all the common BEPs ? no use for a library if it doesn't
work for a lot of cases. It needs to implement everything from [3] maybe
except BEP 8.

* sane interface ? in the end we need to be able to build clients on
top. Fortunately we can leverage Haskell's types to do this whereas the
existing C/C++ bittorrent libraries seems to suffer badly here.

* resilient ? if I wanted a fast library which crashes every ten minutes
I'd stick with libtorrent

Basically, I'm looking to build a fully usable bittorrent library.
Notably, I'm not looking for people to help to write a client (yet!).

I plan to start as soon as time allows but it'd be great if there was
more than just myself on board. Let me know one way another if you're
interested in contributing. If you're just interested in the final
product then that's fine too, I could always use more motivation!

[1]: https://github.com/jlouis/combinatorrent
[2]:
http://ircbrowse.net/browse/haskell?id=18701612&timestamp=1406738464#t1406738464
[3]: http://www.bittorrent.org/beps/bep_0000.html

-- 
Mateusz K.