Re: Suggested Corrections to 4.2.3.2 and 4.4.2.15

Stan,

can you send me the example that accomplishes the intended meaning with 
a lambda?  Does that one still use currying to achieve its result?

In principle, I would say your approach sounds reasonable: depracate the 
example, and explain why, and how to get the intended meaning in a 
proper way.  Besides, I didn't realize that the surrounding fn was 
supposed to signal the currying -- I always thought of the example with 
the surrounding fn simply removed.

It's not clear to me yet if the 'proper way' still involves currying or 
not, and as you say, and as I discovered for OpenMath, currying opens a 
whole other can of worms.  It's apparently surprisingly hard to get right.

I realized this morning that I wasn't really all that clear about my 
problem with this example.  I must have sounded like I was opposed to 
the curried interpretation of the example, but that's not really it. In 
fact, if you read my dissertation, you will find that I *like* currying 
- if it's done right.

Rather, the problem was that the binding issues meant that the example 
as it was, interpreted as *curried* within a proper formal semantics 
modeled on the lambda calculus (which includes alpha-conversion rules 
for a good reason), necessarily(?) yields something equivalent to the 
identity function, not the intended operator of integrals over the 
interval [0,1].  Removing the bvar would have yielded the latter curried 
interpretation, but notice that *both* interpretations involve currying, 
and *both* examples are actually correct MathML (they just mean 
different things).

The fixed version of this example that I had in mind would have been 
used as follows:
<apply>
   <apply>
     <int/>
     <lowlimit><cn>0</cn></lowlimit>
     <uplimit><cn>1</cn></uplimit>
   </apply>
   <lambda> <bvar> <ci>x</ci> </bvar>
     ...
   </lambda>
</apply>

i.e. the bvar would effectively be moved to the argument of the 
resulting linear operator (to use functional analysis terminology), 
which is as it should be.  Notice that this example still uses currying, 
but it solves the scoping issue just fine. Notice also that the argument 
here *must* be functional if you want the argument to be treated as 
something other than a constant in the integral.  Having a bvar in the 
surrounding apply, on the other hand, would not get you the desired result.

Stan Devitt wrote:

> 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?

See my comments above on what I had in mind. Is that what you understood?

As I said, in principle, your approach sounds right, but I'd like to see 
how exactly you 'stat[e] even more precisely what was originally 
intended' because at this point I'm still a bit confused about what 
exactly that intention was (currying?), and how exactly that new example 
'achieves the intended effect (=currying?) without the deprecated 
feature (=fn?).'

To summarize, it sounds like you may have fixed this problem, but I 
think I'd need to see the concrete resolution to be sure.

Thanks,

  -- Andreas

Received on Friday, 20 June 2003 04:13:26 UTC