Andreas, see below regarding:
> > <fn>
> > <apply>
> > <int/>
> > <bvar><ci>x</ci></bvar>
> > <lowlimit><cn>0</cn></lowlimit>
> > <uplimit><cn>1</cn></uplimit>
> > </apply>
> > </fn>
> > "
>
> This has been clarified in the remarks by adding an example of how to
> accomplish the same thing without the deprecated fn by using a lambda
> expression.
> ... I don't understand yet whether or not you have addressed the issue
> of the bvar in the curried integral example.
>
In the original specification, this example was chosen and included
precisely because it could be used as a curried expression and we actually
meant that interpretation. Never mind that to achieve that interpretation
we had to use some sort of magic wand to get over the scoping issues
with bvar. The simplistic reasoning went something like:
"The expression was incomplete and "obviously" the
things needed to complete it simply came next once the fn was
applied."
Your comments in the review made it clear to us that people
had very reasonably decided that this was problematic or had
even other interpretations (e.g., Maple's). You also proposed salvaging
the example by eliminating the bvar, here and re-introducing it in the
containing apply. This solved the scoping issue for bvar, but led
to a different interpretation of the incomplete integral and possibly
other interpretations.
This was further complicated by the fact that it is a deprecated feature
and so best left alone because it was going away anyway. Why
fix a bug in something that is deleted?
Instead of simply salvaging the example, changing its interpretation
and possibly dropping the whole issue of curried expressions
we opted to leave the deprecated example as is and to
use is a vehicle to lead into what we meant to say.
We have clarified what was originally meant (however ill advised it may
have been at the time), and included a new example showing how the
intended effect could be achieved without using the deprecated feature.
This had the second benefit of stating even more precisely
what was originally intended.
Does this address the issue or are we still missing something?
Stan.
>
>
>