Re: Re[2]: Strict tuples
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 refers to the idea that somehow such strictness annotations are (a) required at the type level and (b) required at all to enable such optimization. I believe the optimization happens without any annotation from the user, and it should stay that way. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Strict tuples
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. My comment refers to the idea that somehow such strictness annotations are (a) required at the type level and (b) required at all to enable such optimization. I believe the optimization happens without any annotation from the user, and it should stay that way. 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 of the compiler and inspect it by hand to see whether the optimisation happens. If not, you have to tweak the source to nudge the compiler into recognising that it can optimise. Of course, all your efforts may be wasted when the next version of the compiler is released or when you have to change your code. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Strict tuples
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 of the compiler and inspect it by hand to see whether the optimisation happens. If not, you have to tweak the source to nudge the compiler into recognising that it can optimise. Of course, all your efforts may be wasted when the next version of the compiler is released or when you have to change your code. That kind of tweaking isn't required to simulate this. a `seq` b `seq` (a, b) is perfectly sufficient, and is quite commonly seen in such programs. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Re[2]: Strict tuples
On 20 March 2006 12:26, Bulat Ziganshin wrote: 2) to allow changing of strictness inside existing ADTs, i propose to copy strictness annotations on type arguments to the type declaration bodies: data List a = Nil | Cons (List a) a type StrictElements a = List !a is equal to the: data StrictElements a = Nil | Cons (List a) !a So, in fact StrictElements is not compatible with the List type at all (that is, you can't pass a value of type (StrictElements Int) to a function expecting (List Int)). I can envisage that this might be a sound extension, and imlementable, but is it what you mean? I don't think so. I imagine you want a lot of automatic conversion back and forth bewteen strict and lazy types. This is where it gets a *lot* trickier, starting with the type system. i.e. it's the same list but each element is strict. using strictness annotation on type constructor itself should mean strictifying of all other (non-type-variable) fields: type StrictList a = !List a = data StrictList a = !Nil | !Cons !(List a) a I don't know what !Nil or !Cons mean. of course, i don't mean introducing new incompatible types - that is a compiler responsibility (sorry, Simon :) Well, you haven't told me what type system I need to implement, so it's not just an implementation issue. And it seems to me that you *are* introducing incompatible types. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
