Hardware dependency

William Tanksley wtanksle@ucsd.edu
Sat, 9 May 1998 20:55:05 -0700 (PDT)


On Sun, 10 May 1998, Adrian Hey wrote:

>On Sat 09 May, Rolf-Thomas Happe wrote:

>> A particular nuisance in my version of Clean is mod: -1 mod 3
>> evaluates to -1, while I'd expect 2.  
>> If the Clean team has a concept of modulo different from mine -- 
>> the report doesn't say what mod(ulo) is meant to calculate anyway.
>> The definition of mod is left to a random hardware operator, as it seems.

>I would aggree with your definition of 'mod', but I've found that often
>programming languages don't seem to work this way for negative Nos.
>I've never really understood why, I just assumed that it was me who
>was stupid and so learned to live with it without griping :-)

Ouch.  Evidently Clean relies on C's division and mod.  This is a Bad
Thing, since the ANSI C standard does not specify what type of division
and modulus a compliant compiler will use; they are allowed to simply use
whatever happens to be present on the hardware.

For unsigned numbers this presents no difficulty.  For signed numbers, as
you see, there are two different answers.

Unsuprisingly, there are relatively few publicly languages which bother to
implement a correct division and modulus.  May I recommend (for future
code-stealing) Python, from www.python.org?  Its license allows completely
guilt-free code stealing, so there's no problems from that.  Once Python's
code is implanted in Clean everything should be just wonderful, since
Python is also designed to work multiplatform.

>> A compiler switch that, on floating point exceptions, drove the 
>> Clean runtime system into suicide, would be both nice and easily 
>> feasible (on some platforms).

>Nice? Don't you mean nasty? I don't think a program should _ever_ be
>designed to 'bomb out' on users, unless you know that you are going
>to be the only user. This sort of thing is generally indicative of
>software bugs and shouldn't be part of your design goals. Unfortunately,
>even nowadays there are far too many programs (even operating systems) in
>the world which do precisely this :-)

This is part of a huge controversy, actually.  However, I agree with him
that a compiler _switch_ to turn on the behavior where possible would be
immensely nice for programmers needing it.

And I can't help but throw myself into this debate: you state that "such a
thing is generally indicative of software bugs..."  Well, that's the
point; this makes software bugs obvious instead of allowing them to hide.
It makes it impossible for programmers to ignore a bug simply because it's
rare.

And, of course, since it's only a compiler switch, it's still possible to
leave it off and keep the good old head-in-the-sand approach to debugging.
:)

>> PS: Does exception handling fit into a pure functional language?

>This is a question of great interest to me. But if I get started on this
>subject I'll end up writing another essay, so I'd better stop now.

I'd be interested in your opinion --- I have none of my own on the topic
(too little knowledge).  Is there a more appropriate list?

>Adrian Hey

-Billy