Re: [q-lang-users] New stuff in cvs: multichar ops, views

[Albert G. <Dr....@t-...>]

Rob Hubbard wrote:
> This is a rare occasion where I *strongly* disagree. The purpose of
> (+:) is to form complex numbers syntactically, when they are in some
> sense 'atomic' or 'literal' semantically.

I see your point, but note that in common mathematical notation complex
numbers aren't atomic either (unless you write them as pairs), so you
face the same kind of problem.

But let's assume, just for fun, that X+:Y really is atomic, how should
foo 2 +: 3 be parsed? Or -2+:3 ? I think that it would be rather
surprising if -2+:3 returned (-2)+:(-3). Note the parentheses; these
would be obligatory if (+:) had, say, the same precedence as (.).

I really think that 'X+:Y' should be seen as an abbreviation for 'X+i*Y'
(in fact, that's just how it is implemented, but this doesn't count in
this discussion). Consequently, '+:' should have the same precedence as
'+', anything else is just awkward in subtler but equally annoying ways,
as pointed out above.

>    ==> 1+:2 * 3+:4
>    1+:10 // is wrong (and surprising)

I have no problem with that if I read '1+:2*3+:4' as '1+i*2*3+i*4'.

BTW, this apparent weirdness is somewhat mitigated in Haskell because
Haskell's ':+' is non-associative (which makes sense in Haskell since
':+' only takes Real operands there). But why should we arbitrarily
limit the scope of Q's '+:' when it can be applied to complex operands
just as easily? Besides, this also makes '+:' work exactly analogous to
exact division '%' which is a Good Thing, IMHO.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag