Inconsistency when using previously defined variables as arguments to functions

On Wed, Jan 26, 2011 at 12:10, Richard Fateman
<fateman at eecs.berkeley.edu> wrote:
> On 1/26/2011 8:52 AM, Stavros Macrakis wrote:
>>
>> You would write
>>
>> ? ? ?sum(lambda([n],sum(lambda([k], k),1,n)),1, m)
>>
>> But the traditional lambda syntax is clumsy and obscure to
>> non-computer-scientists.
>
> you could write ?function[k]:k ?if that would make people happier.

Yes, something as trivial as that could make a difference....

>> ? Maybe it's as easy as defining a nicer
>> syntax, e.g.
>>
>> ? ? ? sum( sum( k // k, 1:n ) // n, 1:m )
>>
>> But then what do you do when you *do* want to define a function like
>> sum_over (expr, varlist)? ?Do you define yet another syntax for
>> syntactic lambda-construction? ?Do you use subst or buildq (yuck)? ?I
>> suppose that at least moves the complexity to an 'expert' level.
>
> even if you changed ? sum(lambda([k],k),1,n) ?to return lambda([n],
> (n+n^2)/2)

No, I would not expect the free variable n to suddenly become bound in
sum!  The result of

        sum(lambda([k],k),1,n)

should be simply (n+n^2)/2.  If you want to nest that in another sum,
with n being a bound variable, you'd write

        sum( lambda([n], sum(lambda([k],k),1,n), ...)

...
> People writing code in idiomatic Scheme might be more comfortable with such
> stuff, but the typical applied-math user would probably be uncomfortable with explicit
> functional notation.

Yes, I agree entirely.

> ?For what it is worth, much of the practical applied math books etc are jumbles of mismatched notation,
> but an expert has sufficient context so that he/she not only is comfortable, but doesn't
> even notice the subtle ambiguity.

Yes, see http://mitpress.mit.edu/sicm/book-Z-H-5.html#footnote_Temp_5
and http://mitpress.mit.edu/sicm/book-Z-H-12.html#footnote_Temp_69 in
Sussman's Classical Mechanics for more examples of notational issues.

> You also probably want a summation notation that allows sum over ?1<=i,j<=n,
> i /= j, ?or over sets like ?odd(i).

Well, that actually becomes conceptually much easier when you split
out the functionality of sum() into (a) define the function being
summed and (b) define the sequence over which it is being summed.  You
still need to define notation and simplifications etc. for objects
like {natural number n where oddp(n)}, but at least the 'sum' function
is conceptually the same.

             -s