static code generation and open Accs

[Manuel M T Chakravarty]

Hi Rami,

>>> The other two aspects of the approach which are not clear to me at the moment are:
>>> 
>>> 1) Would using lazy lists preclude a backend from using static memory allocation?  Allocating memory on the heap and performing GC for list elements may be too slow (since each element is a frame - they are likely to be large).
>> 
>> The GHC storage manager already handles large objects specially; in particular, large arrays of unboxed values —which is what we have got here— are not scanned during GC.  The GC'ed list in the heap just contains a pointer to each array, not the array itself.  In my experience, it is usually best to let the storage manager do its job unless there is concrete evidence that its policies are not appropriate for a particular program (and then there are many options with which it can be tuned).
> 
> Thanks for the clarification - makes sense.  Will the user using operations like "head( head( head( lazy_list) ) )" ... to access an element at an arbitrary depth, lead to potentially large amounts of memory usage?

The consumer would recursively consume the resulting lazy list.  It is important that that is done using tail recursion (the last call in the function is the recursive call).  Then, GHC's tail call optimisation ensures that memory is used efficiently.  This is a common idiom in Haskell.

Cheers,
Manuel