Re: Catching Break?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> When I have read your mail I thought this would be trivial to work
> around.  But it isn't.  First it isn't that obvious what counts as
> a function application.  Given the functional nature of ML I'd like to
> say "everything".  But then I start to have doubts.  What about basic
> arithmetic operators for instance?

These do not check for signals.  Worse, applications of primitive
functions (defined by an "external" clause) don't check either.
So, yes, it's kind of hard to know when signals will be tested exactly.

> Finally, and more seriously, this is just a toy example.  In my real
> program, I need to return a _value_ from the expression that
> corresponds to suicide().  I tried
> 
> let suicide() =
>     begin Unix.kill (Unix.getpid()) Sys.sigint; 1 end
> 
> let id x = x
> 
> let suicidal = try
>     (suicide(), id 0)
> with Sys.break -> (0, 0)

First of all, that should be Sys.Break (an exception constructor), not
Sys.break.  It doesn't work because of the right-to-left evaluation order
(id 0 is evaluated before suicide()).

> let suicidal = try
>     id (suicide())
> with Sys.break -> 0

Works fine here (with Sys.Break of course).

> Do I really have to use _sequencing_ to force a `safe point'?

Not at all.

> That
> throws away the value from suicide(), so I'll have to invent a
> reference to assign to - eeek!

A sequencing operator that doesn't throw away the value of its left
subexpression exists: it's called "let".

One more comment: rather than sending yourself a signal, then turn the
signal into an exception via the signal handler (as Sys.catch_break does),
why not throw the exception directly?  E.g. just raise Sys.Break when
your program wishes to commit suicide.  Exceptions are much nicer for
synchronous notification; signals are a pain and only required for
asynchronous notification (such as the user pressing ctrl-C).

All the best,

- Xavier Leroy