[clean-list] My very first program crashes!

[Maarten de Mol]

OK, so I should have formulated more carefully ;-)

----- Fergus Henderson wrote: -----

> That's true, but it's possible to do a better job than the current
> Clean implementation.

Indeed.

> Firstly, it's quite easy for the compiler to detect cases like this one
> where a function calls itself with the same arguments, and to issue a
> warning.  For example, the Mercury compiler does that.  As it happens,
> Mercury uses a syntax where function calls are written with commas to
> separate the arguments, so the problem would be unlikely to arise in
> the first place ;-).  But if you ignore that, and go ahead and write an
> equivalent program in Mercury, the compiler will report the following
> warning:
>
> | test1.m:012: Warning: recursive call will lead to infinite recursion.

Agreed. In this situation, a compile-time warning could easily be generated.
(of course, I always compile with warnings off so it wouldn't help me ;-))
However, this will not work for other situations.

> Secondly, it's possible for the implementation to catch stack overflow
> at runtime, and to issue a nicer error message than just "Stack Fault".
> For example, if you compile with no special options and run the program
> on Linux, then the Mercury runtime system will report the following
> message:
>
>  | Mercury runtime: memory zone detstack#0 overflowed
>  | PC at signal: 134513980 (804853c)
>  | This may have been caused by a stack overflow, due to unbounded
recursion.

The problem is that currently the Clean runtime system is NOT able to detect
stack overflow at all. Clean will not even issue a 'Stack Fault' but simply
crash.
This is the major flaw IMO.

> The first two lines here are probably not especially helpful.
> But the last line may help a lot, particularly for newcomers.

It helps in finding out *what* went wrong, but not in *where* it went wrong.

> Of course, the Mercury compiler does have its own flaws, so there may
> well be examples where the Clean compiler does things better.
> But by plugging the features of a rival implementation, maybe I can
> spur the Clean team into handling this particular issue better ;-)

;-)

----- Richard A. O'Keefe wrote -----

> However, it does ***NOT*** follow that a crash is acceptable behaviour.
> What's probably occurring is some type of stack overflow.  Other
programming
> languages manage perfectly well to catch such errors and give you an
> intelligible diagnostic.  Just crashing and leaving it to the operating
> system to tell you why just isn't good enough.  Clean gets away with it
> because it's free.

This is a point where Clean definitely needs to be improved.

Cheers,
    Maarten de Mol