Re: Unary /

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>> Ah, so there will not be a lot of legacy code relying on the current
>> semantics.  This would be
> [...]
>> Since there are about a dozen apparently unrelated changes, the question
>> is whether anything specifically relied on this change.
>
> I don't remember the specific case that motivated the change.
> IIRC I changed it mostly because the limitation was arbitrary (as you
> can see in the patch, which doesn't actually change the code).
>
> I didn't know that CL had decided to give a completely different meaning
> to the unary / than the natural generalization of the behavior of (/ X1
> X2 ... Xn).  It seems backward to me, so I guess my sense of aesthetics
> would incite me to simply revert my patch, adding a comment that for the
> semantics of the unary / there is a conflict between the natural choice
> and CL compatibility.

Should we do that for unary - as well?  It's exactly the same situation.

(- 3) is not the same as (- 3 0) but as (- 0 3), just like (/ 3.0) is
not the same as (/ 3.0 1.0) but as (/ 1.0 3.0).

That is, given only a single argument, you get the inverse element for
addition/multiplication, respectively.

-- 
David Kastrup