[M3devel] Do I remember well...

[Mika Nystrom]

Jay,

Sometimes I wonder if you have never read the Green Book!!!

The very first section of the Modula-3 definition, Section 2.1 of
the Green Book, talks about the distinction between "checked runtime
errors" and "unchecked runtime errors" and ends with the sentence
"Unchecked runtime errors can occur only in unsafe modules."

If I may make one of those philosophical diversions that so often
lead to Language Wars (but in this case isn't intended to), you
mentioned something a while back along the lines of (I am not quoting
you verbatim) "every line of code is part of an application's
interface, because it can cause...a change in memory usage or expose
a previously unknown race condition"..

The whole point of Modula-3 is that Modula-3 is part of a family
of tools, a way of thinking, even, under which this isn't true.

If you use the garbage collector alluded to by Knuth, timing changes
in your program CANNOT cause it to run out of memory.

If you use the Extended Static Checker (coded by some of the same people
who did Modula-3), timing changes to your program CANNOT expose unknown
race conditions because there ARE no race conditions in your program!

And if you use Modula-3 the way you're supposed to---that is, use the
safe features almost exclusively and use UNSAFE code so sparingly that
it is obviously (i.e., provably) correct, you will have NO unchecked
runtime errors!

Now it is true that we live in an imperfect world, and that neither
any mortal nor any product of any mortal is perfect, but the WHOLE
POINT of Modula-3 is to be a stepping-stone to this type of
perfection!!!!  All of its users are longing to one day be programming
in the Elysian Fields where there are no race conditions, heap
overflows due to lazy garbage collectors, nor any unchecked runtime
errors.  Will we ever get there?  I don't know.  But for me at
least, one of the reasons I use Modula-3 is because it tries, and
I can see how one might fill in the gaps and get it all the way.
I know of no other programming environment that comes to within
several orders of magnitude of Modula-3's performance and satisfies
the same properties.

Integer overflow: the Green Book says that the language catches it.
Implementations generally don't, as far as I know.

The specification is really only fifty pages long...

     Mika

Jay wrote:
>This sounds very much how Windows has been but finally changed. 
> 
> It used to be in C++ you could do: 
> 
>  try { printf("%s\n", (char*) 1); }  /* access violation, reading from address 1 */ 
>  else catch (...) { printf("caught exception\n"); }  
> 
>  now you can't.  
>  Now catch (...) catches all C++ exceptions but not these "Win32 structured exceptions".  
>     "Win32 structured exceptions" are generally "hardware exceptions" made visible to software. 
>     The most common one is an "access violation". There's also "stack overflow". And others.
>     They can be raised by code via RaiseException though.
> 
>  There is a similar syntax for catching them -- __try / __except.  
> 
>  Now, maybe Modula-3 runtime errors are "more orderly" and so more "catchable"?
> In particular, Win32 structured exceptions fall into two or three classes:
>    Someone called RaiseException. These are orderly and reasonable to catch, but rare. 
>      (Even if C++ exceptions are implemented via RaiseException.) 
>    Someone has some corrupted data and "access violated" (aka: some sort of signal/tap on Unix)  
>    This is the more common case, and if you catch such an exception, you have to wonder, uh, some data is corrupt..which data? What can I possily do at this point, given that some dat
>a somewhere is corrupt? It could be the heap. It could be the stack. It could be something small that I'm not going to touch. Heck, maybe it was merely a NULL deref and nothing "very" 
>corrupt. I suggest a NULL deref might be the third class, but not clear.
> 
>If Modula-3 does an adequate job of noticing things as soon as they have gone bad, and not at an indeterminate point afterward, that sounds more viable. I suspect this might be the cas
>e, as long as you haven't called out to some buggy C code or some unsafe Modula-3, oops.
> 
>What about integer overflow? I wonder. :)
> 
>   - Jay