<div>I doubt this is a problem with the compiler as you state; </div>
<div>&nbsp;</div>
<div>It&#39;s not immediately obvious by looking at your code what the problem is; the code is really dense and&nbsp;it&#39;s not&nbsp;immediately obvious what you are trying to accomplish.&nbsp; I suspect that&nbsp;either you have a&nbsp;bug, or you are pattern-matching&nbsp;against something you are depending on,&nbsp;which will force it to evaluate to weak-head normal form so that&nbsp;it can be matched against.
</div>
<div>&nbsp;</div>
<div>Take a look at the section titled &quot;Lazy Patterns&quot;&nbsp;for an example of how to solve that problem: <a href="http://www.cs.auckland.ac.nz/references/haskell/haskell-intro-html/patterns.html">http://www.cs.auckland.ac.nz/references/haskell/haskell-intro-html/patterns.html
</a><br>&nbsp;</div>
<div>I don&#39;t understand what you are saying about &quot;promises pushed onto the stack&quot;.&nbsp; A boxed value&nbsp;can either be a thunk (unevaluated promise) or the evaluated result of that thunk.&nbsp; Calls to functions just push pointers to the boxes onto the stack.&nbsp; When the result is needed the thunk&nbsp;gets evaluated; if it somehow ends up depending on itself the thunk will get called recursively which will eventually end up in a stack overflow.
</div>
<div>&nbsp;</div>
<div>&nbsp; -- ryan</div>
<div>&nbsp;</div>
<div><span class="gmail_quote">On 6/11/07, <b class="gmail_sendername">Michael Speer</b> &lt;<a href="mailto:knomenet@gmail.com">knomenet@gmail.com</a>&gt; wrote:</span></div>
<div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The code I reference is located at :<br><br><a href="http://michaelspeer.blogspot.com/2007/06/impossible-is-only-possible-sometimes.html">
http://michaelspeer.blogspot.com/2007/06/impossible-is-only-possible-sometimes.html</a><br><br>In the code I am building a parser for regular expressions.&nbsp;&nbsp;I know it<br>is possible with ghc to have a function that accepts its own output as
<br>its input so long as it does not utilize that piece of output in<br>generating itself.<br><br>E.g.<br>test x y = ( &quot;World&quot; , x , x ++ &quot; &quot; ++ y )<br>main = let ( a , b , c ) = test &quot;Hello&quot; a
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in do<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print $ ( a , b , c )<br><br>-- emits (&quot;World&quot;,&quot;Hello&quot;,&quot;Hello World&quot;)<br><br>This contrived example works properly.&nbsp;&nbsp;A more complex example can be<br>found in the linked-to function `aexn&#39; ( and-extracted-nodes ).
<br><br>It seems though, if you try this same trick with two different<br>functions that rely on each others input and output, that the compiler<br>will generate code, but the generated program causes the stack to<br>overflow as each function tries to force the other one to evaluate
<br>first and neither bows out releasing an output of promises so that the<br>two functions can resolve.&nbsp;&nbsp;They seem to encounter a lack of laziness.<br>Well, more a duplication of effort.&nbsp;&nbsp;I specifically refer to the<br>linked function `oexn&#39; ( or-extracted-function-nodes ) that performs
<br>this feat.&nbsp;&nbsp;Or would if the program worked after being compiled.<br><br>If the compiler were forced to only make the function call once and<br>mark all variables generated by it immediately with either proper<br>values or promises than the second functions call would receive the
<br>promises in place of the empty variables it feels the need to call the<br>original function to fill.<br><br>Are the promises added to the stack before or after the call?&nbsp;&nbsp;If<br>after, then putting them on before may resolve this.&nbsp;&nbsp;It would likely
<br>make the implementation slower to do so however.<br><br>Is this a known problem that will one day be resolved, or is it<br>considered beyond the scope of the language?<br><br>As I only use ghc, I am unfamiliar if one of the other implementations
<br>could handle this.&nbsp;&nbsp;I have seen nothing referring to it though out my<br>searches regarding the matter.<br><br>- michael speer<br>_______________________________________________<br>Haskell mailing list<br><a href="mailto:Haskell@haskell.org">
Haskell@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/haskell">http://www.haskell.org/mailman/listinfo/haskell</a><br></blockquote></div><br>