[m-rev.] for review: Added cord.condense/2

[Peter Wang]

On Tue, 2 Jul 2013 11:00:44 +1000, Paul Bone <paul at bone.id.au> wrote:
> On Tue, Jul 02, 2013 at 06:57:57AM +1000, Zoltan Somogyi wrote:
> > On 01-Jul-2013, Julien Fischer <jfischer at opturion.com> wrote:
> > > Having the state variable transformation also depend upon argument types
> > > would be ugly.  (And probably fairly difficult to implement.)
> > 
> > Yes, it would, mainly because state variable expansion now happens during the
> > creation of the HLDS from the parse tree, way before the type checking phase.
> > 
> > Paul's idea requires knowing the type of the state variable, which (if it
> > is a local variable) is known only during type checking. Delaying state
> > variable expansion until that time would require expanding the HLDS to allow
> > it to represent unexpanded state variables, and teaching all compiler phases
> > until and including type checking to handle the new parts of the HLDS.
> > This would be a HUGE amount of work, and I don't think the result would be
> > worth that much even for people who like the idea of type-dependent expansions.
> 
> My argument against my own idea was that it may be more complicated to use,
> with strage edge cases for programmers to try to understand.  The complexity
> required in the implementation is another (rather large) nail in the coffin.
> :-)

I don't like any of the proposals.  The only reason for using functions
normally is so you can nest calls.  The Mozart solution[1] is worth
considering:

    p1(X, p2(Y, $), Z)

====>

    p2(Y, Tmp),
    p1(X, Tmp, Z)

Peter

[1] http://www.mozart-oz.org/home/doc/tutorial/node5.html#control.nesting