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:

overall don't think there's dogma going 1 way or another. it's matter of convenience.


Comments

Popular posts from this blog

ruby - Trying to change last to "x"s to 23 -

jquery - Clone last and append item to closest class -

c - Unrecognised emulation mode: elf_i386 on MinGW32 -