lazy-evaluation

问题 Am I right understanding that def is evaluated every time it gets accessed lazy val is evaluated once it gets accessed val is evaluated once it gets into the execution scope? 回答1: Yes, though for the 3rd one I would say "when that statement is executed", because, for example: def foo() { new { val a: Any = sys.error("b is " + b) val b: Any = sys.error("a is " + a) } } This gives "b is null" . b is never evaluated and its error is never thrown. But it is in scope as soon as control enters the

问题 I tried the following in Clojure, expecting to have the class of a non-lazy sequence returned: (.getClass (doall (take 3 (repeatedly rand)))) However, this still returns clojure.lang.LazySeq . My guess is that doall does evaluate the entire sequence, but returns the original sequence as it's still useful for memoization. So what is the idiomatic means of creating a non-lazy sequence from a lazy one? 回答1: doall is all you need. Just because the seq has type LazySeq doesn't mean it has pending

问题 UPDATE: Heavily revised after @usr pointed out I'd incorrectly assumed Lazy<T> 's default thread safety mode was LazyThreadSafetyMode.PublicationOnly ... I want to lazily compute a value via an async Factory Method (i.e. it returns Task<T> ) and have it cached upon success. On exception, I want to have that be available to me. I do not however, want to fall prey to the exception caching behavior that Lazy<T> has in its default mode ( LazyThreadSafetyMode.ExecutionAndPublication ) Exception

问题 Following example is based on discussion about using expand.grid with large data. As you can see it ends up with error. I guess this is due to possible combinations which is according to mentioned page 68.7 billions: > v1 <- c(1:8) > v2 <- c(1:8) > v3 <- c(1:8) > v4 <- c(1:8) > v5 <- c(1:8) > v6 <- c(1:8) > v7 <- c(1:8) > v8 <- c(1:8) > v9 <- c(1:8) > v10 <- c(1:8) > v11 <- c(1:8) > v12 <- c(1:8) > expand.grid(v1, v2, v3, v4, v5, v6, v7, v8, v9, v10, v11, v12) Error in rep.int(rep.int(seq_len

问题 I've generally heard that production code should avoid using Lazy I/O. My question is, why? Is it ever OK to use Lazy I/O outside of just toying around? And what makes the alternatives (e.g. enumerators) better? 回答1: Lazy IO has the problem that releasing whatever resource you have acquired is somewhat unpredictable, as it depends on how your program consumes the data -- its "demand pattern". Once your program drops the last reference to the resource, the GC will eventually run and release

问题 Here's one that has me perplexed. I'm trying to implement a basic Hibernate DAO structure, but am having a problem. Here's the essential code: int startingCount = sfdao.count(); sfdao.create( sf ); SecurityFiling sf2 = sfdao.read( sf.getId() ); sfdao.delete( sf ); int endingCount = sfdao.count(); assertTrue( startingCount == endingCount ); assertTrue( sf.getId().longValue() == sf2.getId().longValue() ); assertTrue( sf.getSfSubmissionType().equals( sf2.getSfSubmissionType() ) ); assertTrue( sf

问题 In the past few days, I have researched LazyEvaluation, in performance aspect mostly, wondering from where the performance advantage of LazyEvalutaion emerges . It's been so unclear to me reading various articles but a very few including What are the advantages of Lazy Evaluation? This refers to the evaluation of a syntax tree . If you evaluate a syntax tree lazily (i.e. when the value it represents is needed), you must carry it through the preceeding steps of your computation in its entirety

问题 I am trying to show the importance of lazy-sequences or lazy-evaluation to the non-FP programmers. I have written this implementation of prime-generation to show the concept: (defn primes-gen [sieve] (if-not (empty? sieve) (let [prime (first sieve)] (cons prime (lazy-seq (primes-gen (filter (fn [x] (not= 0 (mod x prime))) (rest sieve)))))))) ;;;;; --------- TO SHOW ABOUT THE LAZY-THINGS ;; (take 400 (primes-gen (iterate inc 2))) ;; (take 400 (primes-gen (range 2 1000000000000N))) However, i

问题 In a design of the public interface of a library, is it legitimate to return an instance of Lazy<T> in a property, if I want lazy initialization? Or is it better to always hide the usage of Lazy<T> by means of encapsulation or other techniques? 回答1: For the following I'm assumim you mean a Lazy Property. It depends on the purpose of your interface. Is it an important detail that the consumer knows that it is lazy ? Or is it just a technical detail which should not change the behavior for the

问题 // Member Variable private static readonly object _syncLock = new object(); // Now inside a static method foreach (var lazyObject in plugins) { if ((string)lazyObject.Metadata["key"] = "something") { lock (_syncLock) { // It seems the `IsValueCreated` is not up-to-date if (!lazyObject.IsValueCreated) lazyObject.value.DoSomething(); } return lazyObject.value; } } Here I need synchronized access per loop. There are many threads iterating this loop and based on the key they are looking for, a