Hardware dependency

[Adrian Hey]

I didn't mean that I didn't think exceptions indicating errors in shouldn't
be generated. Far from it, it is essential that they are. I just meant that
program suicide is a nasty response to these events. It would like something
better, but I'm not sure what.

One of the good things about ML is its ability to raise and handle
exceptions. I know purists despise them, but I think in practice
they are very useful. The problem is, how to implement ML style
exceptions (or something very similar) in a lazy language. I'm not
sure I know the answer. Perhaps there's a better way of doing things
in a lazy language. This is why this problem interests me. Perhaps
somebody out there can tell us. I haven't really looked at the Object
IO library yet, maybe there's something in there that facilitates Cleaner
(excuse the pun) exception handling. I also have a few ideas of my own,
but I just don't have enough time to work them out properly at the moment,
so I'll say no more.

-------------------------------------
On Sun 10 May, Alan Hutchinson wrote:
-------------------------------------
An interesting message. I'll study this some more.

---------------------------------------
On Sun 10 May, Rolf-Thomas Happe wrote:
---------------------------------------
> What about portability?

I can't disaggree. I'm sure the Clean Team wouldn't either, but
all these things take time.
 
> Yet, Clean is announced as a general purpose programming language for real
> world applications.
 
> I would prefer to be grateful that we can write *correct* numerical software
> in a functional language.  Sure, speed matters, too.

Well, if C users can cope with all these problems and more besides,
I'm sure Clean users can for a while longer. We live in an imperfect
world, be patient :-)

> E. W. Dijkstra writes (in A_Discipline_of_Programming):
> "From the above it is clear that explicit refusal by the HSLM
> (Hopefully Sufficiently Large Machine), whenever asked to do 

I take it he's refering to a MacOS applications workspace here :-)

> something exceeding its capacity, is a vital feature of the HSLM:
> it is necessary for our ability of doing the experiment. There
> exist, regretfully enough, machines in which the continuous check
> that the simulation of the behaviour of the UM (Unbounded Machine)
> is not beyond their capacity is so time-consuming, that this check
> is suppressed for the supposed sake of efficiency: whenever the 
> capacity would be exceeded by a correct execution, they just
> continue - for the supposed sake of convenience - incorrectly.

True, as I said earlier, the question (as far as I'm concerned) is not
_whether_ to deal with exceptions, but _how_. (Hopefully) very few run
time errors are fatal (in the sense that the heap has been corrupted
or something like that), so why should the program abort?.

> Side remark: Yes, I know, the IEEE floating point standard defines 
> operations involving Infinity, NaNs, ... And abortion is not my 
> favourite exception handling scheme.

Not mine either, as you know.

--------------------------------------
On Sun 10 May, William Tanksley wrote:
--------------------------------------
> Ouch.  Evidently Clean relies on C's division and mod.

I hope your not quoting _me_ re that. I don't _know_ if its true. But it
seems like a plausible theory.

> This is part of a huge controversy, actually.

Evidently, I wish I'd never joined in :-)

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

Yes, but what you do during debugging and what is acceptable error
handling when the software ends up in the hands of customers are two
different things. I'm working on the (possibly misguided) assumption
that programmers are competent, responsible and diligent professionals,
so errors/bugs won't simply be ignored.

> I'd be interested in your opinion

Thanks, but I've decided to keep my opinions to myself for the time
being. (I just have far to many opinions to post them all!)

Regards
-- 
Adrian Hey