haskell - Strict Maybe in data definitions -
i have seen many talks / read blog posts should have strict fields in data
avoid various performance issues, e.g.:
data person = person { personname :: !text , personbirthday :: !utctime }
this makes total sense me. functions operation on data lazy, composability isn't sacrificed.
yet if add maybe
field:
data person = person { personname :: !text , personbirthday :: !utctime , personaddress :: !(maybe address) }
i'm introducing lazyness data structure, after maybe
control structure. can't unevaluated thunk hide behind just
constructor?
however, there strict maybe
in strict
or thru strict-base-types
. according reverse dependencies (strict, strict-base-types) aren't used.
so question: why 1 should or shouldn't use strict maybe
in not-control data definitions?
reasons use strict either/maybe/tuple types:
if profile code , notice space leak, way plug leak
strict data types regarded useful thing high-performance code, even latest ghc 8.0 language extensions
other people doing (those strict packages might not popular, exist reason – argue kind of applications need strict packages wouldn't uploaded hackage)
reasons not:
not in prelude, it's package
you're not writing high-performance code
your program won't faster because pushed bang inward 1 level
if writing high-performance code, force evaluation on thunk inside
maybe
manually anyway
overall don't think there's dogma going 1 way or another. it's matter of convenience.
Comments
Post a Comment