[Haskell-cafe] Indent aware parser

Hi all. What's the best indentation-aware parser at the moment? I see three when I look in cabal: lyndon@pugno:~ » cabal list indent * IndentParser Synopsis: Combinators for parsing indentation based syntatic structures Default available version: 0.2.1 Installed versions: [ Not inst

[Haskell-cafe] Problem with forall type in type declaration

Hi, Assuming this: run :: Monad IO a -> IO a data Test = Test { f } Here I'd like to set f to run, like "Test run". Then what is the type of f? The confusing (me) part is that, the argument pass to f is not fixed on return type, like "f1 :: Monad IO ()", "f2 :: Monad IO Int". So "data Test a

Re: [Haskell-cafe] Indent aware parser

The uulib package provides combinators for dealing with the Haskell offside rule. Is that what you are looking for? Doaitse Op 4 mei 2012 om 09:02 heeft Lyndon Maydwell het volgende geschreven: > Hi all. > > What's the best indentation-aware parser at the moment? > > > I see three when

Re: [Haskell-cafe] Indent aware parser

I'm not parsing Haskell, so the offside rule won't be required. I'm looking at doing a more general Cassius parser. On Fri, May 4, 2012 at 3:50 PM, S D Swierstra wrote: > The uulib package provides combinators for dealing with the Haskell offside > rule. Is that what you are looking for? > >  D

Re: [Haskell-cafe] Problem with forall type in type declaration

run :: Monad IO a -> IO a Actually this type is wrong. Monad has to appear as a class constraint, for instance : run :: Monad m => m a -> IO a Are you trying to make: run :: IO a -> IO a ?? 2012/5/4 Magicloud Magiclouds > Hi, > Assuming this: > run :: Monad IO a -> IO a > data Test = Test {

Re: [Haskell-cafe] Problem with forall type in type declaration

Sorry, it was just a persudo code. This might be more clear: run :: (Monad m) => m IO a -> IO a On Fri, May 4, 2012 at 4:32 PM, Yves Parès wrote: > run :: Monad IO a -> IO a > > Actually this type is wrong. Monad has to appear as a class constraint, for > instance : > > run :: Monad m => m a ->

Re: [Haskell-cafe] conduit: Finalize field in PipeM

On Thu, May 3, 2012 at 11:11 PM, Paolo Capriotti wrote: > Hi, > I'm trying to write a function to convert a conduit to a Pipe (from > pipes-core), and I'm having trouble understanding why the `Finalize` > field in a `PipeM` constructor returns `r`. This makes it impossible > to create it from the

Re: [Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

Thinking aloud, I dónt know if the transition to more abstract type signatures can be aleviated using language directives. Someting like: Restrict (++) String -> String -> String that locally would restrict the type within the module. Althoug it does not avoid breaking the old code, It permits

Re: [Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

On 4 May 2012, at 10:02, Alberto G. Corona wrote: > Restrict (++) String -> String -> String > > that locally would restrict the type within the module. import qualified Prelude import Prelude hiding ((++)) (++) :: String -> String -> String (++) = Prelude.(++) __

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 01:35 AM, Thomas DuBuisson wrote: Vincent has done great work for Haskell+Crypto so I think he knows I mean nothing personal when I say cprng-aes has the right idea done the wrong way. Why a new effort vs Vincent's package? 1. cprng-aes is painfully slow. when using the haskell A

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 04:56 AM, Thomas DuBuisson wrote: On May 3, 2012 5:49 PM, "Ertugrul Söylemez" mailto:e...@ertes.de>> wrote: Thomas DuBuisson mailto:thomas.dubuis...@gmail.com>> wrote: I can't really tell whether the first two points are true. Feel free to investigate it yourself, I've

Re: [Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

Fine ;) So the transition should not be so problematic. An OldPrelude.hs may be created easily with this. Once again, thinking aloud. 2012/5/4 Malcolm Wallace : > > On 4 May 2012, at 10:02, Alberto G. Corona wrote: > >> Restrict (++)  String -> String -> String >> >> that locally would restrict

Re: [Haskell-cafe] Annoyed at System.Random

> > 1. cprng-aes is painfully slow. >> > when using the haskell AES implementation yes. with AESNI it fly, and even > more when > i'll have time to chunk the generation to bigger blocks (says 128 AES > block at a time) One data-point -- in "intel-aes" I needed to do bigger blocks to get decent pe

Re: [Haskell-cafe] Annoyed at System.Random

> > My end goal is to have the user use transparently the fastest > implementation available to their architecture/cpu providing they use the > high level module. I've uploaded the cpu package which allows me to detect > at runtime the aes instruction (and the architecture), but i've been > distrac

Re: [Haskell-cafe] Problem with forall type in type declaration

If one parameter is not enough, you always can add more: Test m a b = Test { f :: m IO a -> IO b } This way, if run :: m IO a -> IO a then Test run :: Test m a a But for other type for your run function run' :: m IO a -> IO b you get Test run' :: Test m a b So you can have different types

Re: [Haskell-cafe] Annoyed at System.Random

Vincent uses gcc header files to get the AES instructions: Header files of: #include #include And later calls of: x = _mm_aesenc_si128(m, K1); But currently you must know you have AESNI and use a flag: cabal install cryptocipher -faesni But if you are wrong: Illegal i

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 02:37 PM, Ryan Newton wrote: My end goal is to have the user use transparently the fastest implementation available to their architecture/cpu providing they use the high level module. I've uploaded the cpu package which allows me to detect at runtime the aes instruc

Re: [Haskell-cafe] Annoyed at System.Random

On Fri, May 4, 2012 at 10:11 AM, Vincent Hanquez wrote: > For the language, i think assembly is a no-no with cabal, as such it need > to be embedded in gcc inline assembly if you want to have something that > works (unless there's a secret way to run assembler in a portable fashion > in cabal). >

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 02:33 PM, Ryan Newton wrote: 1. cprng-aes is painfully slow. when using the haskell AES implementation yes. with AESNI it fly, and even more when i'll have time to chunk the generation to bigger blocks (says 128 AES block at a time) One data-point -- in "

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 03:05 PM, Thomas DuBuisson wrote: Vincent uses gcc header files to get the AES instructions: Header files of: #include #include And later calls of: x = _mm_aesenc_si128(m, K1); But currently you must know you have AESNI and use a flag: cabal install crypto

Re: [Haskell-cafe] Annoyed at System.Random

On 05/04/2012 03:18 PM, Brandon Allbery wrote: On Fri, May 4, 2012 at 10:11 AM, Vincent Hanquez > wrote: For the language, i think assembly is a no-no with cabal, as such it need to be embedded in gcc inline assembly if you want to have something that works (un

[Haskell-cafe] Fwd: Problem with forall type in type declaration

Oops, forgot to reply-all again... -- Forwarded message -- From: Chris Smith Date: Fri, May 4, 2012 at 8:46 AM Subject: Re: [Haskell-cafe] Problem with forall type in type declaration To: Magicloud Magiclouds On Fri, May 4, 2012 at 2:34 AM, Magicloud Magiclouds wrote: > Sorry,

Re: [Haskell-cafe] Problem with forall type in type declaration

Sorry to use Monad as the example, I meant this one: run :: MonadTrans m => m IO a -> IO a And Daniel, I do not think adding another type "b" a good idea. Since "run" could actually return any inside type (depending on another function that passed to it). Even simple as different tuples would des

Re: [Haskell-cafe] conduit: Finalize field in PipeM

On Fri, May 4, 2012 at 9:40 AM, Michael Snoyman wrote: > I think the underlying point of distinction between conduit and > pipes-core here is that, is conduit, a Pipe of type `Pipe i o m r` is > *required* to provide an `r` value ultimately. If I understand > correctly, this is not the case in pip

[Haskell-cafe] Haskell and arrays

I'm a bit confused on what the standard is when it comes to arrays and performance in Haskell. Say I have a function that takes an n dimensional array. The array only contains some primitive type. The function mutates the array in an deterministic but chaotic pattern. The new value of an eleme

Re: [Haskell-cafe] Haskell and arrays

Hi Morten, If speed is really important I would go with the vector package. It has a more modern API and better performance. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: meta-par, meta-par-accelerate and friends -- heterogeneous parallel programming

Hi all, I'm happy to announce a release of meta-par, a parallel programming library that is a successor to monad-par. - http://hackage.haskell.org/package/abstract-par - http://hackage.haskell.org/package/monad-par - http://hackage.haskell.org/package/meta-par - http://hackage.haskell

[Haskell-cafe] MonadError vs Control.Exception

Hi, guys, I'm interested in best practices in using of each approach. Personally I like MonadError because it is more explicit and Control.Exception-s becomes really ugly in complex scenarios. Here an example to illustrate my idea: http://hackage.haskell.org/packages/archive/network-conduit/0.4.0/

Re: [Haskell-cafe] Generalizing (++) for monoids instead of using (<>)

In the context of string-like types ++ seems quite sensible because the Monoid instances concat the strings. However, not all Monoid instances imply concatenation. A Monoid instance might provide choice. For example, we could define a parser, > module Main where > > import Data.Monoid > > newtype