q-lang-users — general discussion, questions, suggestions, etc.

[q-lang-users] Unparse on Rationals

[Rob H. <hub...@gm...>]

At the moment, unparse on (positive) Rational values always produces a 
value of the form
    N%D
(well, pending the change to (%) from (over) anyway).
Is this what is really desired?

I wondered whether it would be preferable to present, for example:

    3%1  as just  3
        The LHS has the advantage of looking like the rational it is
        The RHS is clearly simpler

    11%5  as  2+1%5
        The LHS is simpler this time
        The magnitude of the RHS more obvious (i.e. that it's "2 and a bit")

I prefer the RHS in both cases.

Comments welcome.

Thanks,
Rob.

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

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

Rob Hubbard wrote:
> I've been persuaded of some benefits of (%); so I suppose I'm leaning
> if favour of (%) over (over) -- pun not intended. I'm now happy for
> (%) to be used.

Great. :) I'll do the necessary changes after I've finished fixing the 
INF/NaN support (or rather getting rid of the code which prevents it). I 
guess I'll be ready to release RC2 before the weekend...

> It looks like (%) wins to me, which is a big factor; the remainder of
> us have been persuaded; we are no longer divided. Groan -- sorry.

I'd have to reply with poetry, but inadequate is my English; happy I am 
we reached a consensus; no longer divided we are.

Tim, it's your turn now. How about some habbie stanza? :)

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

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

[Tim H. <q...@st...>]

"Rob Hubbard" <hub...@gm...> writes:

[snip]
> I have not been able to come up with another compound symbol (such as
> (/^) or (/.)) that looks good enough.
> 
> Tim is "50-50". John and Keith appear to be in favour of, or okay with,
> (%).

Yeah, OK, I'll lean slightly to the right as well. % is permissible :)

> It looks like (%) wins to me, which is a big factor; the remainder of
> us have been persuaded; we are no longer divided. Groan -- sorry.

Argh! :P)

~Tim
-- 
<http://spodzone.org.uk/>

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

[Rob H. <hub...@gm...>]

On 21/06/06, Albert Graef <Dr....@t-...> wrote:
> Ok, it looks like we are leaning more to the side of "%" now. Rob, can
> you be convinced, in the light of all those arguments? :)

Well, the arguments in favour of (%) have been quite compelling. In particular:
    > "1%5+2%3*i" is a lot more readable than "1 over 5+2 over 3*i"
Yes, it is. I agree.

My objection was based on the use of '%' in 'C' for modulus. That
argument seems much weaker now.

The percent sign contains an oblique/slash (/), thus it is at least
reminiscent of division.

I would prefer another, perhaps compound symbol. I missed that '//'
introduces a comment as John pointed out. [Which reminds me of another
'gotcha' in 'C': x divided by the dereferenced pointer p is: 'x/*p' --
which also introduces a comment.]

I have not been able to come up with another compound symbol (such as
(/^) or (/.)) that looks good enough.

Tim is "50-50". John and Keith appear to be in favour of, or okay with, (%).

I've been persuaded of some benefits of (%); so I suppose I'm leaning
if favour of (%) over (over) -- pun not intended. I'm now happy for
(%) to be used.

It looks like (%) wins to me, which is a big factor; the remainder of
us have been persuaded; we are no longer divided. Groan -- sorry.

Rob.

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

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

Rob Hubbard wrote:
> Please, please keep the unparsing.

I certainly will. :) (See my reply to John's remark in this thread.)

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

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

[Rob H. <hub...@gm...>]

On 21/06/06, John Cowan <co...@cc...> wrote:
> I'm beginning to wonder if this unparsing is the Right Thing after all:
> it makes it harder to see what is a normal form and what is not.  If you
> type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back
> "1 over 5+2 over 3*i", as if the expression were in fact in normal
> form.  But it's not; the underlying normal form is "complex::complex
> (rational::rat 1 5) (rational::rat 2 3)", which is then effectively
> denormalized for printing purposes.

There is a problem of thinking that an expression has not been
understood, certainly.

Perhaps the system could indicate whether an expression is in normal
form in some other way (perhaps optionally), and provide the normal
form upon request (perhaps through a new function).

However, I think unparsing is a *big* step forward. I really didn't
like seeing the internal representation of a value, and was frustrated
by not being able to do anything about it. I didn't really see the
point of the unparsing stuff until I saw it in action.

Please, please keep the unparsing.

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

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

John Cowan wrote:
> The expression "f != 0.0 && f == f + f" will work, I think.
> 0.0 and NaN are rejected by the left side of "&&", and all
> other finite values by the right side.

Thinking about it some more I think that "!isnan(f) && isnan(f-f)" 
(given John's definition of isnan()) might be an even better way to do 
this. f-f can never be nan on an IEEE float system unless f is either 
nan or inf. And with non-IEEE floats this test should always fail 
because (presumably) f==f will always be true and hence isnan will 
always be false. Right?

This test only relies on the algebraic properties of inf and nan and 
should be about the most efficient way to do it, too, as it just needs a 
single subtraction and two comparisons.

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

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

[John C. <co...@cc...>]

Albert Graef scripsit:

> But you want the code at least not to do any harm on systems with _no_ 
> IEEE floats. I'm not sure, but couldn't dividing by 0.0 on such systems 
> kill your program with SIGFPE?

I don't know.  I've never done serious floating-point work that
had to run on a non-IEEE system (everything I did on a PDP-8, PDP-11,
or pre-IEEE VAX was pretty much either integer-only or floats-as-integers,
as in most Basics).

> Another point is that division is a much more costly operation than 
> adding and subtracting.

True.

> BTW, should I cc the Chicken list in this thread?

Might as well, though your postings might or might not go through.

-- 
That you can cover for the plentiful            John Cowan
and often gaping errors, misconstruals,         http://www.ccil.org/~cowan
and disinformation in your posts                co...@cc...
through sheer volume -- that is another
misconception.  --Mike to Peter

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

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

John Cowan wrote:
> Abdulaziz Ghuloum scripsit:
> 
>>Out of curiosity, why not simply do "f==1.0/0.0 || f==-1.0/0.0" to test
>>if f is +inf.0/-inf.0?
> 
> Umm.  Too obvious, I guess.  I started working these out in
> Chicken, where dividing by zero throws an exception, so I
> wanted some other method.  But in C, of course, there's no
> such issue.

But you want the code at least not to do any harm on systems with _no_ 
IEEE floats. I'm not sure, but couldn't dividing by 0.0 on such systems 
kill your program with SIGFPE?

Another point is that division is a much more costly operation than 
adding and subtracting.

BTW, should I cc the Chicken list in this thread?

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

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

[John C. <co...@cc...>]

Abdulaziz Ghuloum scripsit:

> Out of curiosity, why not simply do "f==1.0/0.0 || f==-1.0/0.0" to test
> if f is +inf.0/-inf.0?

Umm.  Too obvious, I guess.  I started working these out in
Chicken, where dividing by zero throws an exception, so I
wanted some other method.  But in C, of course, there's no
such issue.

-- 
One art / There is                      John Cowan <co...@cc...>
No less / No more                       http://www.ccil.org/~cowan
All things / To do
With sparks / Galore                     -- Douglas Hofstadter

Re: [q-lang-users] Improper tuples and user-defined operators

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

John Cowan wrote:
> Another point: it would be useful to me to have a qint.h function that
> reports which symbols are operators and which are not, so that when the
> Scheme user writes "(q-call over 1 2)" I can pass the symbol "(over)"
> rather than "over" to the qmkapp() function.  Probably the Right Thing
> is to return the precedence level, for the benefit of someone trying
> to reconstruct the infix representation, or 0 if the symbol is not
> an operator.

Ok, I've put that on my TODO list for 7.2 final.

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

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

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

John Cowan wrote:
> The expression "f != 0.0 && f == f + f" will work, I think.
> 0.0 and NaN are rejected by the left side of "&&", and all
> other finite values by the right side.

Ok, I'll fix that, thanks.

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

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

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

John Cowan wrote:
> True, but you will see "1 over 5+2 over 3*i", which was the example in
> the first draft of my original e-mail.

Yes, you're right, I forgot about that case. So that really makes it an 
  issue. "1%5+2%3*i" is a lot more readable than "1 over 5+2 over 3*i", 
I fully agree with that now.

> I'm beginning to wonder if this unparsing is the Right Thing after all:
> it makes it harder to see what is a normal form and what is not.  If you
> type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back
> "1 over 5+2 over 3*i", as if the expression were in fact in normal
> form.  But it's not; the underlying normal form is "complex::complex
> (rational::rat 1 5) (rational::rat 2 3)", which is then effectively
> denormalized for printing purposes.  

Yes, I really should add some remarks about this to the manual.

I still think that this is very desirable or even essential for the 
benefit of readability. And it also resolves the issue of external 
objects not being printable and serializable, which was another one of 
my pet peeves.

BTW, it's easy to get rid of the custom unparsings if you don't want 
them (e.g., for debugging purposes). Just add the equation "unparse = 
();" to your program. I should mention that in the manual, too.

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

Re: [q-lang-users] [Chicken-users] Re: IEEE float arithmetic

[John C. <co...@cc...>]

Abdulaziz Ghuloum scripsit:

> The test [for infinity] is obviously bogus since f==f+1.0 for large values of f.
> (try 1e16)

Oops, quite right.

The expression "f != 0.0 && f == f + f" will work, I think.
0.0 and NaN are rejected by the left side of "&&", and all
other finite values by the right side.

-- 
Andrew Watt on Microsoft:                       John Cowan
Never in the field of human computing           co...@cc...
has so much been paid by so many                http://www.ccil.org/~cowan
to so few! (pace Winston Churchill)

[q-lang-users] Improper tuples and user-defined operators

[John C. <co...@cc...>]

Albert Graef scripsit:

> "Improper" tuples are vital in symbolic computations, e.g., you will 
> often find them as a pattern in lambdas or "case" constructs. Redefining 
> this syntax to something else would thus not only raise orthogonality 
> concerns, it would also kill Q's reflective capabilities.

Ah, quite so.  I wasn't thinking about patterns, where improper tuples are
clearly useful.  It still leaves me with the problem of how to map them
to Scheme, however.  Probably as a list whose first element is "q-tuple".

Another point: it would be useful to me to have a qint.h function that
reports which symbols are operators and which are not, so that when the
Scheme user writes "(q-call over 1 2)" I can pass the symbol "(over)"
rather than "over" to the qmkapp() function.  Probably the Right Thing
is to return the precedence level, for the benefit of someone trying
to reconstruct the infix representation, or 0 if the symbol is not
an operator.

-- 
John Cowan  co...@cc...   http://ccil.org/~cowan
"The exception proves the rule."  Dimbulbs think: "Your counterexample proves
my theory."  Latin students think "'Probat' means 'tests': the exception puts
the rule to the proof."  But legal historians know it means "Evidence for an
exception is evidence of the existence of a rule in cases not excepted from."

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

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

Hi Keith,

thanks for chiming in. :)

> Suggestion #1: please, use "%" and not "over" or any other perlish "line noise".

I agree, those perlish conglomerates of arbitrary punctuation chars just 
make programs unreadable, especially for the casual user of a 
programming language. (IIRC, the last Perl version that I really did 
some programming with was version 2.)

> In terms of heritage, Q has more in common with the language families / traditions that I have mentioned in my "Suggestion #2", than Lisp / Scheme, and (especially) C / Perl / etc.

That's certainly true.

> Okay, I will shut up now. But I think that I may have held my tongue too long...

No need to shut up, you didn't start a flamewar, you made some very 
reasonable remarks. Please continue to do so.

It might seem silly to spend so much time and bandwidth on an apparently 
trivial issue like this, but I'd like to get this right before Q 7.2 
comes out, because I hope that this can be the stable version (except 
for bug and portability fixes) for quite some time, which I can base my 
forthcoming book on.

Ok, it looks like we are leaning more to the side of "%" now. Rob, can 
you be convinced, in the light of all those arguments? :)

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

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

[John C. <co...@cc...>]

Albert Graef scripsit:

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

I agree: we need different operators for exact and inexact division.

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

True, but you will see "1 over 5+2 over 3*i", which was the example in
the first draft of my original e-mail.  I removed the "*i", thinking
it would just confuse the issue, and not realizing that removing it made
the expression no longer in normal form.

I'm beginning to wonder if this unparsing is the Right Thing after all:
it makes it harder to see what is a normal form and what is not.  If you
type "1 over 5+2 over 3*i" into a Q 7.2 RC1 interpreter, you get back
"1 over 5+2 over 3*i", as if the expression were in fact in normal
form.  But it's not; the underlying normal form is "complex::complex
(rational::rat 1 5) (rational::rat 2 3)", which is then effectively
denormalized for printing purposes.  

-- 
May the hair on your toes never fall out!       John Cowan
        --Thorin Oakenshield (to Bilbo)         co...@cc...

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

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

Albert Graef wrote:
> this form, only arises with "over" because it's used as in the visual 

s/as in/in/

> a printed result unless it's in a quoted term or a symbolic expression. 
s/or a symbolic/or another suspended/

Sorry, it's already getting quite later over here. :)

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

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

[Keith T. <kaz...@ea...>]

Albert Graef wrote:
>So where do we go from here? I'd be happy with both "over" and "%"
>Should we have a poll now?

It is clear to me now why dogs typically have only _one_ tail to wag (or to be wagged by ;-)

Suggestion #1: please, use "%" and not "over" or any other perlish "line noise".

Suggestion #2: whenever this kind of situation occurs in the future, if at all possible, follow the naming / parsing / semantic traditions of Haskell / *ML / functional / logic programming languages.

Q is Q, and should remain Q. In terms of heritage, Q has more in common with the language families / traditions that I have mentioned in my "Suggestion #2", than Lisp / Scheme, and (especially) C / Perl / etc.

Not Suggestion #3, just thinking out loud: If Q has to be transformed (wagged) into following the path of another (unrelated) language, then please make it _Ruby_. Despite the fact that Ruby has some perlish nonsense, it is (for the most part) a clean, orderly language.

Suggestion #3: Q is Q. Where new users may come from should never be the reason for changing anything. OTOH, the Principle of Least Surprise (ref. Ruby) is a _Good Thing_ (ref. Martha Stewart). Thus, Suggestion #2.

Okay, I will shut up now. But I think that I may have held my tongue too long...

Cheers,
Keith 
 

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

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

Tim Haynes wrote:
> It might be that we have more folks
> coming with significant Haskell experience, in which case that's a
> non-issue.

Yes, I think that most ppl interested in trying out Q will already have 
seen a subset of, say, Lisp, ML, Haskell or Prolog, so they will have a 
broader perspective and will not complain if syntactic things are not 
like in C.

> So on average, I'm still 50-50 about it. :)

So how would you vote when you'd be forced to pick one of the 
alternatives? :)

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

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

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

John Cowan wrote:
> I'm okay with %.  Although it is used in C-ish languages including Perl,
> the operation is not exactly common anywhere.

Exactly.

> And if you tilt your head
> a bit to the left, % even looks like a division sign.

Yes.

> That reminds me.  Thinking about | gave me to wonder: since improper
> tuples like (1|2) are not stored contiguously, and the 2 is not accessible
> with !, do they really make any sense?  Ancient Lisp tradition requires us
> to allow improper lists like [A|B], but I think improper tuples should go,
> and improper streams as well.

"Improper" tuples are vital in symbolic computations, e.g., you will 
often find them as a pattern in lambdas or "case" constructs. Redefining 
this syntax to something else would thus not only raise orthogonality 
concerns, it would also kill Q's reflective capabilities.

> (My current plan for the Q egg is to treat improper tuples as opaque
> objects, whereas ordinary tuples will be mapped to Chicken vectors.)

I don't think that this is a good idea, for the reason sketched out above.

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

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

Re: [q-lang-users] Q 7.2 RC 1 issue 1: Nomenclature

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

John Cowan wrote:
> This argument is compelling.  The IEEE behavior makes sense in the
> limited terms of forcing NaNs into the straitjacket of two-valued
> logic, but Q can neatly provide a 3-valued true/false/fail system.
> This also fits with the way SRFI-77 talks about NaN:

All right, it's already in cvs. I'll try to fix the remaining issues you 
brought up tonight. With the exception of "over" vs. "%" vs. ..., of 
course, looks like we haven't yet reached a consensus about this that 
everyone is happy with (or can at least live with).

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

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

[Tim H. <q...@st...>]

John Cowan <co...@cc...> writes:

> I'm okay with %. Although it is used in C-ish languages including Perl,
> the operation is not exactly common anywhere. And if you tilt your head a
> bit to the left, % even looks like a division sign.

FWIW, I raised C/Perl et al, not because they define what's `right', but
more to consider for the rule of least surprise, from the perspective of
folks coming from those languages. It might be that we have more folks
coming with significant Haskell experience, in which case that's a
non-issue.

So on average, I'm still 50-50 about it. :)

~Tim
-- 
<http://spodzone.org.uk/>

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

[John C. <co...@cc...>]

Albert Graef scripsit:

> Let's face it, the only punctuation symbols in 7 bit ASCII which look 
> right for a division operator are /, %, \ and |. We can't use /, \ or |, 
> so the only obvious choice left is %. Since Q uses the div/mod pair for 
> integer division and Int/Int yields a Float, I don't see how someone 
> could mistake % for the remainder of integer division.

I'm okay with %.  Although it is used in C-ish languages including Perl,
the operation is not exactly common anywhere.  And if you tilt your head
a bit to the left, % even looks like a division sign.

That reminds me.  Thinking about | gave me to wonder: since improper
tuples like (1|2) are not stored contiguously, and the 2 is not accessible
with !, do they really make any sense?  Ancient Lisp tradition requires us
to allow improper lists like [A|B], but I think improper tuples should go,
and improper streams as well.  

(My current plan for the Q egg is to treat improper tuples as opaque
objects, whereas ordinary tuples will be mapped to Chicken vectors.)

-- 
You escaped them by the will-death              John Cowan
and the Way of the Black Wheel.                 co...@cc...
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan