HaloO,

David Green wrote:
On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using "div" instead of "/" should make it pretty clear that you're disposing of the remainder.

I strongly agree to that. Actually you are disposing of the
fractional part.


I misremembered div vs. idiv, but how standard is it?

IIRC, that was in the discussion about the euclidean modulo
operation. The final outcome at the time was to have floor
semantics by default.


I know "div" commonly means int division, but not always. On the one hand, some things you just have to learn; on the other, lots of P6 operators have word-names as well as symbols, and "div" is the obvious way to spell "/" (what else would you call it?).

It's not only the name that is at stake but the rest of the
specification of the div and mod pair. It is specced to be type
specific. E.g. if one implements the Gaussian integers---that
is complex numbers with integer coordinates---I would expect div
to be *closed* on that type and not lead out of the type as it is
prescribed in the Int case. In general I would expect that a type Foo
that supports a notion of division implements div and mod with
signature :(Foo, Foo --> Foo).

Note that the wording of the spec enforces infix:</>:(Num,Complex-->Num)
instead of infix:</>:(Num,Complex-->Complex) and I wonder how a Complex
is numified. This should be changed, too.

The mixed signature cases of div and mod should return the larger of the
two types. E.g. :(Rat, Int --> Rat) and :(Num, Int --> Num) as long as
Num can hold the result. Does Num in general failover to Rat?


A way to get both [quotient and reminder] in one fell swoop would be nice

Agreed; though having two different operators seems a bit unperlish.

We have the pair of infix (!) operators min, max and the operator
minmax that delivers both values in one go. Copying that prior art
would simply mean to define divmod. I'm fine with that.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan

Reply via email to