You’re being hit by filter‘s laziness. Change (filter …) to (doall (filter …)) in your recur form and the problem should go away. A more in-depth explanation: The call to filter returns a lazy seq, which materialises actual elements of the filtered seq as required. As written, your code stacks filter upon filter upon filter…, … Read more
Call-by-name arguments are called every time you ask for them. Lazy vals are called the first time and then the value is stored. If you ask for it again, you’ll get the stored value. Thus, a pattern like def foo(x: => Expensive) = { lazy val cache = x /* do lots of stuff with … Read more
I think most of the trouble with “strictness leaks” happens because people don’t have a good conceptual model. Haskellers without a good conceptual model tend to have and propagate the superstition that stricter is better. Perhaps this intuition comes from their results from toying with small examples & tight loops. But it is incorrect. It’s … Read more
This can be accomplished with defaultdict, too. It is instantiated with a callable which is then called when a nonexisting element is accessed. from collections import defaultdict d = defaultdict(noisy_default) d[1] # noise d[1] # no noise The caveat with defaultdict is that the callable gets no arguments, so you can not derive the default … Read more
Because (,) is a constructor, the difference makes no difference to Haskell’s semantics (:sprint gives access to internal thunk implementation details so doesn’t count.) So this is a question of which optimizations and trade-offs GHC does when compiling (x,x) in different positions. Someone else may know the precise reason in these cases.
This is a self-referential, lazy data structure, where “later” parts of the structure refer to earlier parts by name. Initially, the structure is just a computation with unevaluated pointers back to itself. As it is unfolded, values are created in the structure. Later references to already-computed parts of the structure are able to find the … Read more
A lazy-seq call just executes the body once the first time it is accessed, then caches and returns the same result whenever it is called again in the future. If you want to use this to build long (or even infinite) sequences, then you need to recursively nest other lazy-seq calls in the returned sequence. … Read more
I Couldn’t get the above to work, but here is my implementation, i’ve tested it on c:\users on a “Win7” box, because if has all these “nasty” dirs: SafeWalk.EnumerateFiles(@”C:\users”, “*.jpg”, SearchOption.AllDirectories).Take(10) Class: public static class SafeWalk { public static IEnumerable<string> EnumerateFiles(string path, string searchPattern, SearchOption searchOpt) { try { var dirFiles = Enumerable.Empty<string>(); if(searchOpt == … Read more
You’re right, from a modern POV this doesn’t really make sense. What is true is that lazy-by-default would make reasoning about side-effectful code a nightmare, so lazyness does require purity – but not the other way around. What does require lazyness though is the way Haskell in versions 1.0–1.2, following its predecessor Miranda, emulated IO … Read more