In case someone cares - after some battles with functions that are less lazy than expected, I have written a tutorial on how to get functions lazy and how to test, whether they are actually lazy: http://www.haskell.org/haskellwiki/Maintaining_laziness I found it especially enlightening, that one can avoid a 'force' function in a lazy parser by making the possibility of a parser failure explicit in its type. I.e. a parser that cannot fail, need no 'force'. (I learnt that in polyparse the 'force' function is hidden in 'apply': http://hackage.haskell.org/packages/archive/polyparse/1.1/doc/html/Text-Pars... )
Henning Thielemann wrote:
In case someone cares - after some battles with functions that are less lazy than expected, I have written a tutorial on how to get functions lazy and how to test, whether they are actually lazy: http://www.haskell.org/haskellwiki/Maintaining_laziness
This is excellent. Thank you for writing this! - Jake
Henning Thielemann wrote:
I found it especially enlightening, that one can avoid a 'force' function in a lazy parser by making the possibility of a parser failure explicit in its type. I.e. a parser that cannot fail, need no 'force'. (I learnt that in polyparse the 'force' function is hidden in 'apply':
I'm curious, what is the difference between using a force function and using lazy pattern matching? - Jake
Jake McArthur schrieb:
Henning Thielemann wrote:
I found it especially enlightening, that one can avoid a 'force' function in a lazy parser by making the possibility of a parser failure explicit in its type. I.e. a parser that cannot fail, need no 'force'. (I learnt that in polyparse the 'force' function is hidden in 'apply':
I'm curious, what is the difference between using a force function and using lazy pattern matching?
Erm, nothing? Because 'force' is implemented by lazy pattern matching.
Seems useful. BTW, why on earth should "inits undefined" be "undefined" instead of "[]:undefined"? I mean, come on, we all know that "inits anything" starts with []! On 29 Dec 2008, at 20:41, Henning Thielemann wrote:
In case someone cares - after some battles with functions that are less lazy than expected, I have written a tutorial on how to get functions lazy and how to test, whether they are actually lazy: http://www.haskell.org/haskellwiki/Maintaining_laziness
I found it especially enlightening, that one can avoid a 'force' function in a lazy parser by making the possibility of a parser failure explicit in its type. I.e. a parser that cannot fail, need no 'force'. (I learnt that in polyparse the 'force' function is hidden in 'apply': http://hackage.haskell.org/packages/archive/polyparse/1.1/doc/html/Text-Pars... ) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Henning Thielemann -
Henning Thielemann -
Jake McArthur -
Miguel Mitrofanov