extending bang proposal Re: strict Haskell dialect
Hello Ketil, Monday, February 06, 2006, 4:06:35 PM, you wrote:
foo :: !Int -> !Int
KM> (Is the second ! actually meaningful?) yes! it means that the function is strict in its result - i.e. can't return undefined value when strict arguments are given. this sort of knowledge should help a compiler to "propagate" strictness and figure out the parts of program that can be compiled as strict code. really, i think ghc is able to figure functions with strict result just like it is able to figure strict function arguments KM> Personally, I think is much nicer than sprinkling seq's around, and KM> generally sufficient. However, there could perhaps be disambiguities? btw, it's just implemented in the GHC HEAD KM> Last time this came up, I think examples resembling these were brought KM> up: KM> foo :: [!a] -> ![a] -> a yes, i remember this SPJ's question :) "[!a]" means that list elements are strict, it's the same as defining new list type with strict elements and using it here. "![a]" means "strict list", it is the same as defining list with "next" field strict: data List1 a = Nil1 | List1 !a (List1 a) data List2 a = Nil2 | List2 a !(List2 a) data List3 a = Nil3 | List3 !a !(List3 a) the type List3 is a simple strict list, like in any strict programming language. foo :: [!a] -> ![a] -> ![!a] -> a translates to foo :: List1 a -> List2 a -> List3 a -> a KM> foo' :: Map !Int String -> Int -> String that means that keys in this map saved as strict values. for example, the following definition type Map a b = [(a,b)] will be instantiated to Map !Int String ==> [(!Int, String)] KM> Anyway, if a reasonable semantics can be formulated, I think KM> strictness type annotations would be a great, useful, and KM> relatively non-intrusive (AFAICT, entirely backwards compatible) KM> addtion to Haskell'. such proposal already exists and supported by implementing this in GHC HEAD -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Feb 6, 2006, at 9:19 AM, Bulat Ziganshin wrote:
Hello Ketil,
Monday, February 06, 2006, 4:06:35 PM, you wrote:
foo :: !Int -> !Int
KM> (Is the second ! actually meaningful?)
yes! it means that the function is strict in its result - i.e. can't return undefined value when strict arguments are given. this sort of knowledge should help a compiler to "propagate" strictness and figure out the parts of program that can be compiled as strict code. really, i think ghc is able to figure functions with strict result just like it is able to figure strict function arguments
KM> Personally, I think is much nicer than sprinkling seq's around, and KM> generally sufficient. However, there could perhaps be disambiguities?
btw, it's just implemented in the GHC HEAD
Actually, I think strict _patterns_ are implemented. You are talking about strict _type annotations_, which is rather different. As I understand it, strict patterns are just sugar for putting 'seq' in the right places. There has been some work dealing with folding strictness and totality information into types systems; I find the resulting type systems pretty ugly, and I think they'd be pretty hard to bolt onto an HM base. Robert Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG
Hello Robert, Monday, February 06, 2006, 8:40:11 PM, you wrote:
foo :: !Int -> !Int btw, it's just implemented in the GHC HEAD
RD> Actually, I think strict _patterns_ are implemented. You are talking RD> about strict _type annotations_, which is rather different. yes, i was wrong RD> There has been some work dealing with folding strictness and totality RD> information into types systems; I find the resulting type systems RD> pretty ugly, and I think they'd be pretty hard to bolt onto an HM base. i'm not a professor, just a programmer who needs to optimize some code :) so, that can be really hard or impossible to implement. what i mean: given expression "a*b+c" and know that a/b/c is strict Int values, GHC can determine that whole expression is strict. how it is fone? i don't know. but i think that strictness annotation on result type should say compiler just about this -- Best regards, Bulat mailto:bulatz@HotPOP.com
participants (2)
-
Bulat Ziganshin -
Robert Dockins