* Kyle Hanson hanoo...@gmail.com [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
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
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
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'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 the
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
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
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
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 Hackage
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
13 matches
Mail list logo
