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
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 c
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
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
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
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 requi
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
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 lo
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 mai
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 i
Hello Taral,
Wednesday, March 22, 2006, 2:14:17 AM, you wrote:
T> On 3/18/06, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote:
>> Of course, the caller could invoke addmul using a bang patterns, as in
>>
>> let ( !s, !p ) = addmul x y
>> in ...
>>
>> but that's quite different to statically
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 res
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
___
Haskell-pr
<>From: "Simon Marlow" <[EMAIL PROTECTED]>
<>After some thought, I find myself with a similar view to John. Strict
<>tuples are starting to feel like real language bloat, one tiny
addition
<>too much.
<>
<>Remember, every addition we make to the core syntax is multiplied
by a
14 matches
Mail list logo