Re: [q-lang-users] Q 7.2 RC1 Issue 2: Notation

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

Rob Hubbard wrote:
> The problem could be solved by having (/) return a Rational rather
> than a Float where possible. That, in my view, would be desirable
> anyway, but I suspect that this would be unpopular, as such a change
> might break existing code.

Well, I know that I'm guilty of that idea as well, but unfortunately I 
didn't think it through...

This wouldn't just be unpopular and break backwards compatibility, it's 
also a misfeature (in a programming language, as opposed to a computer 
algebra system), because you could never be sure which type is returned 
by (/). This in turn will make some code involving numbers as arguments 
to other functions very error-prone. It's true that it doesn't really 
matter what the type of the result of (/) is as long as you stay within 
the realm of arithmetic expressions, but when you eventually pass the 
result to another function (printf, e.g.) then it does matter a lot. A 
similar (but even worse) issue has already been beaten to death over at 
the Python mailing list, see, e.g., http://www.python.org/dev/peps/pep-0238/

> An alternative suggestion: Could the unparse/quotation code be made to
> produce "(1 over 5)+(2 over 3)", or is there a reason why such
> redundant parenthesis can't/shouldn't be generated?

That would make pretty-printing very inconsistent. Then why not always 
parenthesize "div"/"mod", too? And "and then"? Or just every expression? 
Which would essentially give us something which looks more like infix 
s-expressions than anything else. Not that I have anything against 
s-expressions, but it's just not "the right thing" for Q.

So where do we go from here? I'd be happy with both "over" and "%", but 
I think that John raised a legitimate concern about "over" which, in 
this form, only arises with "over" because it's used as in the visual 
representation of numbers. I think it's not quite as bad as he makes it 
out to be, though. You'd never see something like "1 over 5+2 over 3" in 
a printed result unless it's in a quoted term or a symbolic expression. 
Typically, you'd just have something like "5 over 13" occurring as a 
toplevel expression, list member (where no parentheses are necessary for 
humans to parse it correctly) or an argument of a constructor 
application (where it would be parenthesized anyway).

Should we have a poll now? :)

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