[M3devel] Do I remember well...

[Jay]

Mika, I do need to reread that book, yes. Most of my reading of it was years ago.
Yes the odds of me confusing checked and unchecked errors are real. I think I might have speculated as to the way things really are, while talking mainly about how things perhaps are not.
 
However..I still believe the implementation is the interface.
I don't see how Modula-3 fixes that.
 
> If you use the garbage collector alluded to by Knuth, timing changes> in your program CANNOT cause it to run out of memory.
I didn't mean to necessarily link these things together.
Let's say garbage is collected immedately upon it being created.
A program still has a certain amount of non-garbage memory allocated at any one time, and that amount might grow or shrink as changes are made to the code.
 
How about this backwards example: Let's say I have some code that does a heap allocation and handles arbitrarily large data. I find it is slow and I replace it with a fixed sized array. Boom, I break anyone using large data. Now, granted, this is a dumb, backwards example. But it is an implementation detail not revealed in the .i3 file. The .i3 file, like, the "binary" interface. If you get those to match, well, great, your stack won't be unbalanced, safe code will be safe, but nothing will necessarily be correct.
 
 > 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 
Well...I'm ignorant of this particular checker. I am familiar with some of the static checking that is ot there. Only recently have I seen any static checking for race conditions. This is against and C and C++ code, mind you. Perhaps they "resisted" static analysis until recently, hard to parse and all that.. Anyway, while I am not an expert on static checking potential and practise, I have seen just an astounding number of "crazy" bugs and I don't see much hope for much automatic bug detection. Most of the "bugs" found by static checking are very basic things, like leaks or forgetting to check an error, and never something particularly high level as to what the code is actually supposed to do. I mean..I'm not sure this is a valid example or not, but let's say I have the functions Plus and Minus, and let's say I'm a terrible typist and I implement Plus with - and Minus with +. What static checking will catch that. Now, yes, I grant, any amount of manual dynamic testing will catch it. But I think the point is valid -- static checking never checks much. Generalized automatic checking never checks much. The best you can do is along the lines of m3-sys/tests -- a small "framework" for "running stuff" and "comparing the output against expected", perhaps being amitious and including "negative tests" (make sure erroneous source code fails to compile and gives a good error message).
 
I guess, to put a positive light on things, the best we can hope for is some sort of composition of larger systems out of available parts that are already well tested and known to work fairly well. However, this is just..like..a fractal. Those available parts are built up out of yet again smaller well tested parts. And so on down the line. And no layer or part is free of bugs. Processors have bugs. Compilers have bugs. "operating systems" (which are really nothing special -- just another bunch of libraries) have bugs. "There are bugs everywhere". "More code => more bugs, even if that code is meant to find bugs, such as assertion failures" => people put in incorrect assertions, oops, they trigger, let's go and remove or loosen the assertion.
 
I just don't see static checking making all that much headway against the tremendous variety of things programmers do wrong. "Safety" is a nice step, get the easy things, the buffer overflows, but that still leaves lots of room for error (look at how my "safe" m3path.m3 broke the tinderbox for example....)
 
I think Modula-3 was very far ahead of its time. I think a lot of systems have caught up.
I grant that most of the systems that have caught up might not catch all the way up, they are either not as safe or not as performant.
 
Again, really, I think correctness is about far more than safety, and that implementation is interface, because safety or no safety, code can depend on nearly arbitrary characteristics of the code it uses.
 
Ok, I'm repeating myself now, sorry.
 
I don't think I see an argument here btw. Modula-3 is what it is. It solves some problems. It doesn't do the impossible.
 
Have you used the NT386 system btw? One of the great things about Modula-3 is only parsing the headers once, and a resulting very fast compiler. However on non-NT386 the gcc backend all but ruins this perf. The integrated compiler is just way way way way faster than the gcc backend... you (all) should try it.
 
Gotta go,
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika at async.caltech.edu> > 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 
_________________________________________________________________
Climb to the top of the charts! Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080226/fd77c836/attachment-0002.html>