On 9/4/08, Jake Mcarthur <[EMAIL PROTECTED]> wrote:
> I'm no master either, but how about these simple examples?
>
> data Stream a = Cons !a (Stream a)
> data Vector3 a = Vector3 !a !a !a
>
> The compiler will certainly be able to infer the strictness itself in
> most uses, so obviously the purpose for these annotations is not for
> optimization, but I still would find these annotations useful. This is
> much like explicitly giving the type for a function. It guides the
> reader of the program, and just happens to also assist the compiler a
> little bit.
>
But why not write your types like:
data Stream a = Cons a <Stream a>
data Vector3 a = Vector3 a a a
in a hypothetical call-by-value language where the <> annotation
denotes a lazily evaluated data structure? Does it matter? If it does,
then why? If it doesn't, then what would you conclude about whether a
language should encourage laziness or strictness?
> If optimization is the only reason to worry about strictness, then
> default laziness really _is_ treacherous. Luckily this is not the
> case. Laziness is not useful without strictness, otherwise there would
> never be any evaluation. Understanding how to apply laziness and
> strictness in different situations is critical to writing efficient
> but meaningful code in Haskell.
True, but both laziness and strictness exist in strict languages, as
well. What if, as a thought experiment, you tried substituting
"laziness" for "strictness" in that paragraph of your essay?
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"The Internet wasn't created for mockery, it was created to help
researchers at different universities share data sets." -- Homer
Simpson
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
