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
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 = Test
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 maydw...@gmail.com het volgende
geschreven:
Hi all.
What's the best indentation-aware parser at the moment?
I
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 doai...@uu.nl wrote:
The uulib package provides combinators for dealing with the Haskell offside
rule. Is that what you are looking
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 magicloud.magiclo...@gmail.com
Hi,
Assuming this:
run :: Monad IO a - IO
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 yves.pa...@gmail.com wrote:
run :: Monad IO a - IO a
Actually this type is wrong. Monad has to appear as a class constraint, for
instance :
run :: Monad
On Thu, May 3, 2012 at 11:11 PM, Paolo Capriotti p.caprio...@gmail.com 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
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
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.(++)
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
On 05/04/2012 04:56 AM, Thomas DuBuisson wrote:
On May 3, 2012 5:49 PM, Ertugrul Söylemez e...@ertes.de mailto:e...@ertes.de
wrote:
Thomas DuBuisson thomas.dubuis...@gmail.com
mailto:thomas.dubuis...@gmail.com wrote:
I can't really tell whether the first two points are true.
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 malcolm.wall...@me.com:
On 4 May 2012, at 10:02, Alberto G. Corona wrote:
Restrict (++) String - String - String
that locally
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
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
distracted
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
Vincent uses gcc header files to get the AES instructions:
Header files of:
#include wmmintrin.h
#include tmmintrin.h
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
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
On Fri, May 4, 2012 at 10:11 AM, Vincent Hanquez t...@snarc.org 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
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
On 05/04/2012 03:05 PM, Thomas DuBuisson wrote:
Vincent uses gcc header files to get the AES instructions:
Header files of:
#includewmmintrin.h
#includetmmintrin.h
And later calls of:
x = _mm_aesenc_si128(m, K1);
But currently you must know you have AESNI and use a flag:
On 05/04/2012 03:18 PM, Brandon Allbery wrote:
On Fri, May 4, 2012 at 10:11 AM, Vincent Hanquez t...@snarc.org
mailto:t...@snarc.org 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
Oops, forgot to reply-all again...
-- Forwarded message --
From: Chris Smith cdsm...@gmail.com
Date: Fri, May 4, 2012 at 8:46 AM
Subject: Re: [Haskell-cafe] Problem with forall type in type declaration
To: Magicloud Magiclouds magicloud.magiclo...@gmail.com
On Fri, May 4, 2012
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
destroy
On Fri, May 4, 2012 at 9:40 AM, Michael Snoyman mich...@snoyman.com 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
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
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
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
-
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:
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
29 matches
Mail list logo
