[m-rev.] for review: Added cord.condense/2
novalazy at gmail.com
Tue Jul 2 11:29:07 AEST 2013
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 is worth
p1(X, p2(Y, $), Z)
p1(X, Tmp, Z)
More information about the reviews