* Kyle Hanson [2013-08-20 18:23:48-0700]
> So I am not entirely clear on how to optimize for performance for lazy
> bytestrings.
>
> Currently I have a (Lazy) Map that contains large BSON values (more than
> 1mb when serialized each). I can serialize BSON documents to Lazy
> ByteStrings using Dat
Abjad, which is a Python library, is probably worth study here for its
integration and general re-embrace of Lilypond as a compositional tool.
http://www.projectabjad.org/
Note that in Lilypond one can define a Scheme function over for example a
set of notes.
Al Matthews
-- http://fatmilktv.com
The paper is very interesting:
http://www.cs.indiana.edu/~sabry/papers/exteff.pdf
It seems that the approach is mature enough and it is better in every way
than monad transformers, while at the same time the syntax may become
almost identical to MTL for many uses.
I only expect to see the librar
To be honest I'm not so sure about these "effects"... Simply the fact that
the Member class needs -XOverlappingInstances means that we cannot have
duplicate or polymorphic effects. It will arbitrarily pick the first match
in the former and fail to compile in the latter case.
Furthermore I don't re
For the open union used in extensible effects, apart from using the
Typeable mechanism, is there a more protected way to implement
the open sum type?
I managed to modified the Member class given in the paper, but
ended up having to use the vague OverlappingInstance. That's not
quite what I hope. I
I've just read the post "Destroying Performance with Strictness" by Neil
Mitchell [1].
One of the comments from an Anonymous says:
How hard would it be to lift strictness annotations to type-level? E.g.
instead of
f :: Int -> Int
f !x = x + 1
write
f :: !Int -> Int
f x = x + 1
which would have th
On Thu, Aug 22, 2013 at 12:51:24PM -0300, Thiago Negri wrote:
> How hard would it be to lift strictness annotations to type-level? E.g.
> instead of
> f :: Int -> Int
> f !x = x + 1
> write
> f :: !Int -> Int
> f x = x + 1
> which would have the same effect. At least it would be transparent to the
I think Scala has this optional laziness too.
The problem with default-strictness is that libraries that are built with
no laziness in mind turn up to be too strict.
Going from lazy to strict is possible in the client side, but the other way
is impossible.
2013/8/22 Tom Ellis
> On Thu, Aug 22,
I had an idea for |instance Alternative ZipList|, which doesn't seem to
exist so far. Maybe there just is no need for it. Please tell me what you
think.
After giving the instance definition I will add some intuition on why this
might be useful. Then some words on laws and other conceivable instanc
On 2013-08-22 18:19, Thiago Negri wrote:
> I think Scala has this optional laziness too.
Indeed, but it's _not_ apparent in types (which can be an issue).
Due to the somewhat weird constructor semantics of the JVM it also means
you can have immutable values which start out(!) as null and end up
b
Hi,
I noticed Hayoo appears as a link in the toolbox of
http://hackage.haskell.org and also that Hayoo seems to display better
results than Hoogle. For example, if you search for 'PublicKey' in
Hayoo, you will get several results from Hackage libraries, such as,
'crypto-pubkey' and 'crypto-api'.
On 22/08/13 19:30, jabolo...@google.com wrote:
> Hi,
>
> I noticed Hayoo appears as a link in the toolbox of
> http://hackage.haskell.org and also that Hayoo seems to display better
> results than Hoogle. For example, if you search for 'PublicKey' in
> Hayoo, you will get several results from Hac
Or, if there are no such definitions, where would be a good place to add
them?
Petr
Dne 08/20/2013 06:55 PM, Petr Pudlák napsal(a):
Dear Haskellers,
are these monoids defined somewhere?
|import Control.Applicative
import Data.Monoid
newtype AppMonoid m a =AppMonoid (m a)
instance (M
13 matches
Mail list logo