On 21 March 2006 23:51, isaac jones wrote:
Concurrency is summarized here:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
y
I have updated the concurrency page with a skeleton proposal.
Cheers,
Simon
___
On Mon, 20 Mar 2006, Claus Reinke wrote:
variant A: I never understood why parameters of a class declaration
are limited to variables. the instance parameters just have
to match the class parameters, so let's assume we didn't
have that variables-only
Hello Wolfgang,
Wednesday, March 22, 2006, 1:29:24 AM, you wrote:
you said WHAT you think but not said WHY? my motivation is to be able
to use myriads of already implemented algorithms on new datatypes
as i said, shebang patterns allow only to specify that IMPLEMENTATION
of some function is
Hello ,
about this - i'm almost sure that current widely used libraries
(NewBinary) is not as good as my own one
(http://freearc.narod.ru/Streams.tar.gz) is not ever used and even
still not documented, so it is not easy to make right choice :)
--
Best regards,
Bulat
I'd like to put a me too on that one. This part of the class
hierarchy is currently a bit inexpressive. I've been annoyed by the
fact that if I want to express in the type signature of a function
that a monad has a failure mechanism, I'm forced to go all the way up
to MonadPlus, which makes it
On 3/22/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
ghc uses unboxed tuples just for such sort of optimizations. instead
of returning possibly-unevaluated pair with possibly-unevaluated
elements it just return, say, two doubles in registers - a huge win
I have no doubt of this. My comment
class Graph (g e v) where
src :: e - g e v - v
tgt :: e - g e v - v
we associate edge and node types with a graph type by
making them parameters, and extract them by matching.
If I understand correctly, this requires
John Meacham wrote:
ghc's strictness analyzer is pretty darn good, If
something is subtle enough for the compiler not to catch it, then the
programmer probably won't right off the bat either.
Even the best strictness analyzer can't determine that a function is strict
when it really isn't. The
Bulat Ziganshin wrote:
Taral wrote:
T I don't see that more optimization follows from the availability
T of information regarding the strictness of a function result's
T subcomponents.
ghc uses unboxed tuples just for such sort of optimizations. instead
of returning possibly-unevaluated pair
Taral:
On 3/22/06, Bulat Ziganshin [EMAIL PROTECTED] wrote:
ghc uses unboxed tuples just for such sort of optimizations. instead
of returning possibly-unevaluated pair with possibly-unevaluated
elements it just return, say, two doubles in registers - a huge win
I have no doubt of this.
On 3/22/06, Manuel M T Chakravarty [EMAIL PROTECTED] wrote:
It does happen...sometimes! The trouble is that for certain types of
programs (eg, numeric intensive ones), you absolutely need that
optimisation to happen. Without strict tuples, this means, you have to
dump the intermediate code
Simon Marlow:
On 21 March 2006 23:51, isaac jones wrote:
Concurrency is summarized here:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/Concurrenc
y
I have updated the concurrency page with a skeleton proposal.
Yes, good plan.
Manuel
12 matches
Mail list logo
