In this, we assume that the formal parameters of main are the dynamic
variables initially.

1]

The formulation of BTA as given in the document on correction to Jones
et al. is overly conservative when it assumes that any function which
has a dynamic actual argument in any of its calls must have a dynamic
return value.

Consider the example:

    (define (goal a) 
        (call other a)
    )

    (define (other b)
        4
    )

The binding-time pattern obtained here is [goal -> ((D),D),
other -> ((D),D)].

The resulting annotation would be:

    (define (goal () (a)) 
        (callD other a)
    )

    (define (other () (b))
        lift (4)
    )

and the specialized program:

    (
        (define (goal a) 
            (call other a)
        )
        (define (other b)
            4
        )
    )

Note here that although other is called with a dynamic parameter, it
always returns the static value 4. More generally, it is possible to
have a function that is called with a mixture of static and dynamic
parameters, but ut only ever uses its static parameters (possibly
through recursive calls) and returns a value. One would have liked to
notice that the function other has a return value type (namely 4) that
does not depend on any dynamic parameters and hence can be evaluated
in the static environment at any call site during specialization and
get:

Binding time pattern: [goal -> ((D),D), other -> ((D),S)]
annotation:

    (define (goal () (a))
        lift (callS other a)
    )

    (define (other () (b))
        4
    )

specialized program:

    (define (goal a)
        4
    )

Notice here that the annotation phase has to be modified slightly to
change the rules for when lift is introduced. The clause that states
"the expression is the body of a function that has >= 1 dynamic
parameters" changes to "the expression is the body of a function that
has dynamic return type".

In the BTA phase, we propose to improve upon this point by changing
the equations thus:

Be: The call case changes to -

    B_e[|(call f e_1 ... e_a|] div h = t where t (div f) = (_,t)   **

B_v: The call case changes to -

    B_v[|(call f e_1 ... e_a)|] div h g = 
            (t,s)                if f!=g
            (t,s) |_| (u,((div g) \up 2))    if f=g               **
                where,
                (t,s) = |_|{j=1...a} B_v[|e_j|] div h g
                u = (B_e[|e_1|] div h ... B_e[|e_a|] div h)
    
Finally, the equation for div *remains unchanged* -

    div g = 
        (|_|{i=1...n} B_v[|e_f_i|] div f_i g) |_| (goal-args, D) 
                    if g is the goal function
        (|_|{i=1...n} B_v[|e_f_i|] div f_i g) |_| ((S,...,S),B_e[|e_g|] div g)
                    otherwise

The idea here is that one need not infer from the existence of dynamic
parameters that the return type will be dynamic. We let the last
clause in the equation for div handle the propogation of dynamic tag
from paramters to return types.

===========================================================================

2]

Another idea that makes the one above even more relavant is to carry
around for the static variables, the pair (S,val) while doing BTA
which contains the currently known static value of the variable. Then,
if condition can be handled with a somewhat more sophisticated manner:

    if e1 e2 e3 -> old_tag |_| static if e1,e2,e3 static
                   old_tag |_| static if e1 static, e1 true and e2 static
                   old_tag |_| static if e1 static, e1 false and e3 static
                   dynamic otherwise.

This analyses captures the cases like

    if 1
        2
        (callD foo 3)

This analyses will take longer that the original BTA, but no longer
than the specialization phase. If this analyses does not terminate,
neither will specialization.

In conjunction with the first idea above, somewhat complex looking
functions can be specialized well

    (define (main dyn)
        (call foo 10 dyn)
    )

    (define (foo a b)
        (if (> a 4)
            (call bar a)
            (call duh b)
        )
    )

    (define (bar a)
        (if (> a 5)
            (call bar (-a 1))
            a
        )
    )

    (define (duh a)
        a
    )

Here, duh is never called and so BTA for us returns [main -> ((D),D),
foo -> (((S,10),D),(S,5)), bar -> (((S,5)),(S,5)), duh((D)->D)] since
we get only the final actual values for the S after the analyses
(which we don't really care about anyway beyond BTA)
and can be specialized to 

    (define (main dyn)
        5
    )

This is obviously a contrived example to show how the two ideas
together can work well. It is a good question if this improvement
gives a considerably better specialization in practice.