<!-- 
RSS generated by JIRA (4.4#649-r158309) at Tue Jun 18 17:52:12 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/si/jira.issueviews:issue-xml/CLJ-1119/CLJ-1119.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Clojure JIRA</title>
    <link>http://dev.clojure.org/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>4.4</version>
        <build-number>649</build-number>
        <build-date>25-07-2011</build-date>
    </build-info>

<item>
            <title>[CLJ-1119] inconsistent behavior of lazy-seq w/ macro &amp; closure on excptions</title>
                <link>http://dev.clojure.org/jira/browse/CLJ-1119</link>
                <project id="10010" key="CLJ">Clojure</project>
                        <description>&lt;p&gt;lazy-seq seems to evaluate inconsistently when body includes a macro and throws and exception. 1st evalutation throws the exceptions, subsequent ones return empty sequence.&lt;/p&gt;

&lt;p&gt;demo code:&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (let [coll &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;]&lt;br/&gt;
    (lazy-seq&lt;br/&gt;
      (when-let &lt;span class=&quot;error&quot;&gt;&amp;#91;s (seq coll)&amp;#93;&lt;/span&gt;&lt;br/&gt;
        (throw (Exception.))))))&lt;/p&gt;

&lt;p&gt;(def lazy (gen-lazy))&lt;/p&gt;

&lt;p&gt;(try&lt;br/&gt;
  (println &quot;lazy:&quot; lazy)&lt;br/&gt;
  (catch Exception ex&lt;br/&gt;
    (println ex)))&lt;/p&gt;

&lt;p&gt;(try&lt;br/&gt;
  (println &quot;lazy, again:&quot; lazy)&lt;br/&gt;
  (catch Exception ex&lt;br/&gt;
    (println ex)))&lt;/p&gt;

&lt;p&gt;It should throw an exception both times but only does on 1st. Generally speaking an expression shouldn&apos;t evaluate to different things depending on whether it&apos;s been evaluated before.&lt;/p&gt;

&lt;p&gt;When removing the closure ...&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (lazy-seq&lt;br/&gt;
    (when-let [s (seq &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;)]&lt;br/&gt;
      (throw (Exception.)))))&lt;/p&gt;

&lt;p&gt;... or removing the when-let macro ...&lt;/p&gt;

&lt;p&gt;(defn gen-lazy []&lt;br/&gt;
  (let [coll &lt;span class=&quot;error&quot;&gt;&amp;#91;1 2 3&amp;#93;&lt;/span&gt;]&lt;br/&gt;
    (lazy-seq&lt;br/&gt;
      (seq coll)&lt;br/&gt;
      (throw (Exception.)))))&lt;/p&gt;

&lt;p&gt;It works i.e. consistently throws the exception, so seems to be some interaction between the closure and the macro at work here. This particular combination is used in the &apos;map&apos; function.&lt;/p&gt;

&lt;p&gt;See also: &lt;a href=&quot;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z3EiBUQ7Inc&quot;&gt;https://groups.google.com/forum/?fromgroups=#!topic/clojure/Z3EiBUQ7Inc&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
            <key id="15869">CLJ-1119</key>
            <summary>inconsistent behavior of lazy-seq w/ macro &amp; closure on excptions</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="4" iconUrl="http://dev.clojure.org/jira/images/icons/priority_minor.gif">Minor</priority>
                    <status id="1" iconUrl="http://dev.clojure.org/jira/images/icons/status_open.gif">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                                <assignee username="-1">Unassigned</assignee>
                                <reporter username="hank">Hank</reporter>
                        <labels>
                    </labels>
                <created>Mon, 3 Dec 2012 03:00:15 -0600</created>
                <updated>Sun, 16 Dec 2012 04:06:49 -0600</updated>
                                    <version>Release 1.4</version>
                                                        <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30147" author="hank" created="Mon, 3 Dec 2012 04:26:02 -0600"  >&lt;p&gt;N.B. The primary use case I have for this, in case it matters, is interrupting the evaluation of a &apos;map&apos; expression in which the mapped fn is slow to evaluate (throwing an InterruptedException), because I am not interested in its result any more. Then later I re-evaluate it because I am interested in the result after all, however with above bug the lazy sequence terminates instead of recommencing where it left off.&lt;/p&gt;

&lt;p&gt;(UPDATE: This use case is similar to the kind of ersatz continuations that Jetty does (RetryRequest runtime exception) or even Clojure itself when barging STM transactions with the RetryEx exception.)&lt;/p&gt;</comment>
                    <comment id="30149" author="hank" created="Mon, 3 Dec 2012 08:45:27 -0600"  >&lt;p&gt;Related to &lt;a href=&quot;http://dev.clojure.org/jira/browse/CLJ-457&quot; title=&quot;lazy recursive definition giving incorrect results&quot;&gt;CLJ-457&lt;/a&gt; according to Christophe. His patch fixes this,too.&lt;/p&gt;</comment>
                    <comment id="30172" author="hank" created="Tue, 4 Dec 2012 05:02:32 -0600"  >&lt;p&gt;Sorry Christophe&apos;s patch doesn&apos;t work for me here. It avoids evaluating the LazySeq a second time by prematurely throwing an exception. However a LazySeq might evaluate properly the second time around b/c the situation causing the exception was transient. As per comment above an evaluation might get interrupted, throwing InterruptedException the first time around but not the second time.&lt;/p&gt;

&lt;p&gt;Also the observation with the closure and macro need explanation IMHO.&lt;/p&gt;</comment>
                    <comment id="30189" author="hank" created="Sat, 8 Dec 2012 03:51:04 -0600"  >&lt;p&gt;further insight: &apos;delay&apos; exhibits the same behavior and is a more simple case to examine. the macro suspicion is a red herring: as demoed below it is actually the closed over variable magically turns to nil, the when-let macro simply turned that into a nil for the whole expression.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def delayed
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (delay
      (print &lt;span class=&quot;code-quote&quot;&gt;&quot;a=&quot;&lt;/span&gt; a)
      (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.)))))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 1:&quot;&lt;/span&gt;)
  (force delayed)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 2:&quot;&lt;/span&gt;)
  (force delayed)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;prints:&lt;/p&gt;

&lt;p&gt;delayed 1:a= true#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
delayed 2:a= nil#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;/p&gt;</comment>
                    <comment id="30193" author="hank" created="Sun, 9 Dec 2012 01:31:54 -0600"  >&lt;p&gt;The above leads to dodgy outcomes such as: The following expression leads to an Exception on 1st evaluation and to &quot;w00t!&quot; on subsequent ones.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def delayed
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (delay
      (&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; a
        (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.))
        &lt;span class=&quot;code-quote&quot;&gt;&quot;w00t!&quot;&lt;/span&gt;))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Try it like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 1:&quot;&lt;/span&gt; )
  (println (force delayed))
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;delayed 2:&quot;&lt;/span&gt;)
  (println (force delayed))
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Results in:&lt;br/&gt;
delayed 1:#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
delayed 2:w00t!&lt;/p&gt;

&lt;p&gt;This code shows that the problem is tied to the :once flag as suspected.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(def test-once
  (let [a &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;]
    (^{:once &lt;span class=&quot;code-keyword&quot;&gt;true&lt;/span&gt;} fn* foo []
	    (println &lt;span class=&quot;code-quote&quot;&gt;&quot;a=&quot;&lt;/span&gt; a)
	    (&lt;span class=&quot;code-keyword&quot;&gt;throw&lt;/span&gt; (Exception.)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Invoking the fn twice will show &apos;a&apos; turning from &apos;true&apos; to &apos;nil&apos;, try it like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;test-once 1:&quot;&lt;/span&gt;)
  (test-once)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))

(&lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt;
  (print &lt;span class=&quot;code-quote&quot;&gt;&quot;test-once 2:&quot;&lt;/span&gt;)
  (test-once)
  (&lt;span class=&quot;code-keyword&quot;&gt;catch&lt;/span&gt; Exception ex (println ex)))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Results in:&lt;br/&gt;
test-once 1:a= true&lt;br/&gt;
#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;br/&gt;
test-once 2:a= nil&lt;br/&gt;
#&amp;lt;Exception java.lang.Exception&amp;gt;&lt;/p&gt;

&lt;p&gt;That doesn&apos;t happen when the ^{:once true} is removed. Now one could argue that above fn is invoked twice, which is exactly what one is not supposed to do when decorated with the :once flag, but I argue that an unsuccessful call doesn&apos;t count as invocation towards the :once flag. The delay and lazy-seq macros agree with me there as the resulting objects are not considered realized (as per realized? function) if the evaluation of the body throws an exception, and realization/evaluation of the body is therefore repeated on re-evaluation of the delay/lazy-seq.&lt;/p&gt;

&lt;p&gt;Try this using &lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(realized? delayed)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt; after the first evaluation in the code above. In the implementation this can be seen e.g. &lt;a href=&quot;https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/jvm/clojure/lang/Delay.java#L33&quot;&gt;here for clojure.lang.Delay&lt;/a&gt; (similarly for LazySeq), the body-fn is set to null (meaning realized) after the invocation returns &lt;b&gt;successfully&lt;/b&gt; only.&lt;/p&gt;

&lt;p&gt;The :once flag affects &lt;a href=&quot;https://github.com/clojure/clojure/blob/d0c380d9809fd242bec688c7134e900f0bbedcac/src/jvm/clojure/lang/Compiler.java#L4701&quot;&gt;this part of the compiler only&lt;/a&gt;. Some field is set to nil there in the course of a function invocation, for the good reason of letting the garbage compiler collect objects, however this should to be done after the function successfully completes only. Can this be changed?&lt;/p&gt;</comment>
                    <comment id="30240" author="hank" created="Sun, 16 Dec 2012 04:02:08 -0600"  >&lt;p&gt;A workaround for the case of the &apos;map&apos; function as described in the 1st comment, works as this: The original map function, if you take out the cases for several colls, the performance enhancements for chunked seqs and forcing the coll argument to a seq, looks like this:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defn map [f s]
  (lazy-seq
    (cons (f (first s)) (map f (&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; s)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;In my workaround I evaluate f &lt;b&gt;twice&lt;/b&gt;:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;(defn map [f s]
  (lazy-seq
    (f (first s))
    (cons (f (first s)) (map f (&lt;span class=&quot;code-keyword&quot;&gt;rest&lt;/span&gt; s)))))&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Because the downstream functions that are slow to evaluate are all of the deref kind that cache their result (more lazy-seqs, delays, futures, promises), the InterruptedException can only happen during the 1st evaluation, while the tail call optimization that sets closed-over variables to nil (it pays to read this here: &lt;a href=&quot;http://clojure.org/lazy&quot;&gt;http://clojure.org/lazy&lt;/a&gt;) only happens on the second call. The first still creates an fn that captures the head of the sequence &apos;s&apos;, however this is not being held onto as it is not returned.&lt;/p&gt;

&lt;p&gt;I use this special version of map (and other, similarly rewritten functions based on lazy-seq such as iterate) when I want interruptible, restartable seq evaluations.&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                                                                                            </customfields>
    </item>
</channel>
</rss>