unfold and flattening

[Stephen Weeks]

> In  the  old  code,  what  is  the +? infix function?  

No overflow detection.  :-).  I think I agree with you guys and most of those
will go away.

> Also what is the array
> function, which only takes a size argument and not an  element  to  fill  the
> resulting  array  with? 

That's the primitive providied by the runtime.

> Also  I'm  surprised that you use the basis curried
> List.foldl.

This is in the basis code so that's all that's around.  Maybe everything should
be rewritten with a sane library at the core and the standard basis as a thin
veneer on top of that, but that would be a lot of work.

> Also you optimize the case where the list has a single  element  in  the  old
> code  and  you  optimize  the  case where the list has no elements in the new
> code.  Why the change?
> 
> Actually, is the singleton optimization legal?  For immutable  objects  sure,
> but for mutable ones it seems clearly incorrect.

You are right.  It probably came from vector code, where it's OK.  I'll add a
(compile-time) test for whether or not it's ok to avoid the copy.

> It  is  a  bit  ugly either way.  The real problem is that you would like the
> control flow to be controlled by the  generator  of  the  elements,  not  the
> consumer.  Then you could avoid the extra test per loop.

Yeah, but then you would need the bounds check (which should be optimized away
given the current formulation).  I'm not sure that you can do better than two
tests per loop (one for the source and one for the dest).

> More  seriously,  optimizing  away the tuple construction is really important
> especially if you use fold/unfold a lot.  Then you end up tupling things  all
> the time.

Yes, I'm putting that on my stack above overflow detection and bounds check
elimination.