<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Mika you underestimate me somewhat but maybe not entirely.<BR>
<BR>I have never used Algol.<BR>I should do a bit more research.<BR>
<BR>BNF to me is, you know, like a grammar, LALR, LL, yacc, PCCTS, whatever.<BR>
<BR>It is very useful step, a very good way to state what it states.<BR>But as I understand only describes syntax and not semantics.<BR>
<BR>I could say is:<BR>English: subject verb [and verb]*<BR>Jay sits. ok<BR>Jay stands. ok<BR>Jay gallops. Syntactically correct but not semantically. Jay is not a horse.<BR>It is not type correct. Programming languages catch these errors usually,<BR>you don't need "extended static checking".<BR>Or you could be type correct but still wrong:<BR>Jay dies and lives.<BR>
<BR>Something has to know that living cannot occur after dying.<BR>How do I state that?<BR>
<BR>I think C++ is actually underappreciated here.<BR>Stroupstrup alludes to a style of programming where all side affects<BR>are via constructor calls. I believe this is "very functional".<BR>I haven't yet seen anyone elaborate on this.<BR>Add type safety to that.<BR>"Jay = Jay->die()" would return a subtype of human_t that does not have the live() method.<BR>Type checking can possibly do a lot of this.<BR>(sorry this is so morbid, I had to think of operations that could not go in a<BR>certain sequqence. I guess a better one would be Jay learns to program and Jay is born.)<BR>
<BR>Being syntactically correct is a necessary first step, and then<BR>comes type safety, and then comes actually doing what is intended.<BR>
<BR>Maybe BNF has more features than I assume.<BR>
<BR>I have been exposed to multiple opposing views, such as:<BR>
<BR>as you say -- programs are for people first, computers second<BR> The SICP book was very interesting..<BR>
<BR>and the contrary -- performance, performance, performance<BR>
<BR>Too much abstraction and you lose touch with the machine that does<BR>ultimately have to run your creation and if it is runs it too slowly,<BR>well, that does matter. (Humans are not going to run your program<BR>
after all; they are much too slow.)<BR>
<BR>I have a lot of real world practical experience.<BR>Not as much maybe as I should but a lot.<BR>
<BR> > How large a data structure a given program can process is clearly<BR> > part of its interface, like so:<BR> > PROCEDURE A(VAR r : ARRAY OF INTEGER);<BR> > (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) <BR>
<BR>Your example proves my point. The "specification" is a comment written in English.<BR>Nothing will check it. It might change. Worse, the level of detail in a comment<BR>is totally up to the programmer. If the comment was missing, what would the<BR>interface be? That the function does nothing?<BR>
<BR>I contend that there is no language that can state the complete specification.<BR>The language of the implementation comes close, however it then rests on what is below it,<BR>and so on down the line. Science has apparently figured out enough that "and so on down<BR>the line" doesn't go all that far. We know the computer is digital, 0s and 1s, we don't have<BR>to talk about how the transistors work to spec a function.<BR>
<BR>I will look into the sleep.<BR>Can it not be a, um, a wait? You know, wait specifically for the process to exit?<BR>At the same time as reading its stdout and stderr?<BR>Actually I have some experience here...<BR>It turns out, on Windows, that it is very easy to deadlock writing code like this.<BR>There about three simple patterns, one that deadlocks, two that don't.<BR>
<BR>pseudo code:<BR>
<BR>1)<BR>process = CreateProcess();<BR>if process not done<BR> read some from stdout<BR> echo it to my stdout<BR> read some from stderr<BR> echo it to my stderr<BR>
<BR>This can deadlock.<BR>IF the child process ONLY writes to one of stdout or stderr, I think no deadlock.<BR>But if it writes to both, can deadlock.<BR>
<BR>2)<BR>process = CreateProcess<BR>create another thread (or have one already created waiting for work to do)<BR>optionally create another thread for symmetry of implementation, but inefficient<BR>have one thread read/echo stderr, the other read/echo stdout<BR>This won't deadlock.<BR>
<BR>3)<BR>create the process such that stdout and stderr are the same<BR>then just read that one pipe/handle/file/whatever, on one thread<BR>
<BR>I guess, I have to check, I think on Windows you do like WaitForMultipleObjects(2, [pipe and process]).<BR>I have to check if the pipe is signaled by having data available.<BR>
<BR>And then I have to look into what Posix offers here.<BR>Maybe have NT386GNU not use Posix here, however..having tried this for "serial", having done it with Thread,<BR>the various implementation pieces are not always so easily mixed and matched.<BR>For example PosixFile wants PosixScheduler, which is not usually "with" ThreadWin32, but I put in a dummy one.<BR>
<BR>Having both FileWin32 and FilePosix available, with one being the revealer of File.T would be good.<BR>I think this is a simple restructuring of the code.<BR>
<BR>Knowing the machine model and how your code ends up executing on the machine is not at all a bad thing.<BR>Being careful with how large the abstraction layers you build is not a bad thing.<BR>Making a compromise between human and computer is not a bad thing.<BR>I long ago gave up writting in assembly, after all.<BR>However I am constantly viewing assembly, partly by dumb virtue of how my debugger works, but<BR>also partly because there are bugs everywhere and everything you hide from me is an opportunity<BR>for you to hide the bug I am looking for.<BR>
Every abstraction you build is something that is going to have bugs in it that I'm going to have to debug.<BR>
The less abstraction, the thinner the layers, the less debugging will be needed.<BR>
But yet you do absolutely need abstraction.<BR>
<BR>There is this term -- "leaky abstraction".<BR>Most abstractions leak underlying details, there it is useful to understand as much of the stack as possible.<BR>
<BR>Yes, I understand, it is important to know what is an implementation detail and what is an interface/behavioral<BR>guarantee. They are often blurred. One of the things good about Modula-3 is its "portability".<BR>
<BR>The fact that I can do roughly the same things already on NT386, PPC_DARWIN, PPC_LINUX "keeps my honest".<BR>I can fairly readily check my work on three kind of different systems.<BR>
<BR>The counterpoint here however is that at the C level and above, all machines are converging on<BR>two and only two models -- Windows and Posix.<BR>Portability is becoming like English. Or English and French.<BR>Rather than come up with some very very broad commonality that you believe will be implementable<BR>on forseeable architectures, you merely have to fit only two common cases.<BR>Or heck, if Cygwin flies, only one common case.<BR>(Btw, AMD64_MINGWIN should be fairly easy to implement today, AMD64_CYGWIN not so much.<BR>There are already AMD64 MinGWin distributes. Cygwin is loaded with assembly cod and the FAQ/docs<BR>are not optimistic about AMD64. So Cygwin isn't clearly a way forward.<BR>The integrated backend of course needs work and should be viable.<BR>)<BR>
<BR>Yes I know LL is about static checking of locking, though I don't know how to read/write the pragmas.<BR>I also noticed the large or lm3 or whatnot files.<BR>I should look into what they can state and check.<BR>
<BR>I relatively recently amassed a fairly large collection of compilers in order to "test portability".<BR>Man it is a bit sad. CFront based C++ compilers are awful. Only one return statement per function<BR>or something. Maybe this experiment went overboard and there's a smaller number of interesting<BR>modern tools..<BR>
<BR>Most of the stuff that is left "undefined" in C is very reasonable to leave undefined.<BR>For example, signed integer encoding is not specified.<BR>Things like going out of bounds on arrays is probably not specified.<BR>The reason is obvious -- because it is expensive to check.<BR>I have heard of code accidentally depending on array bounds overflow.<BR>Two local variables, one could overflow into the other, accidentally doubling the capacity of the program!<BR>
<BR> > in this you are joined by 99% of people who use computers <BR>
<BR>Equating a PROGRAMMER with 99% of computer USERS is very insulting.<BR>Really.<BR>The family/relative tech support I do..."click the whatever." "Right click or left click?"<BR>I have had that question so many times. Good thing three button mice are not prevalent. :)<BR>(and please don't insult whoever asked me that question..)<BR>
<BR>The rude thing to wonder here is something about practicality vs. theory....<BR>The Modula-3 is actually squarely in the practical camp.<BR>What with having the compiler and garbage collector implemented it, for starters.<BR>
<BR>I have used Scheme btw, and I was very enamored of it.<BR>Then I started debugging some of it by stepping through STk.<BR>Man every other instruction was a type check. Despite that 99% of the type checks<BR>all succeeded, or had even already succeeded against that data.<BR>It's a great programming model, but perhaps? too difficult to implement efficiently?<BR>I don't know. One hole in my experience is working with or implementing systems that infer types,<BR>except as a user of C++ templates, which does involve a significant amount of type inference.<BR>But it's not e.g. SML or a high end efficient compilation Scheme/Lisp.<BR>
<BR>Meanwhile, the mailing lists are still down.<BR>
<BR>Later,<BR> - Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Do I remember well... <BR>> Date: Mon, 25 Feb 2008 19:47:03 -0800<BR>> From: mika@async.caltech.edu<BR>> <BR>> <BR>> I believe the main reason the compiler is slow on most platforms<BR>> is that it sleeps for 0.1 seconds every time it spawns a process.<BR>> My private version of the compiler has that sleep taken out and<BR>> runs probably 20x faster (for a typical compile).<BR>> <BR>> Jay, I still say you are ignorant of a huge part of the history of<BR>> Computer Science---in this you are joined by 99% of people who use<BR>> computers, by the way. You should in fact not start with the Green<BR>> Book, but with this:<BR>> <BR>> http://www.masswerk.at/algol60/report.htm<BR>> <BR>> And reflect upon these words (again, from "The Humble Programmer", Dijkstra's<BR>> 1972 Turing Award lecture):<BR>> <BR>> The fourth project to be mentioned is ALGOL 60. While up to the<BR>> present day FORTRAN programmers still tend to understand their<BR>> programming language in terms of the specific implementation they<BR>> are working with hence the prevalence of octal and hexadecimal<BR>> dumps, while the definition of LISP is still a curious mixture of<BR>> what the language means and how the mechanism works, the famous<BR>> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine<BR>> effort to carry abstraction a vital step further and to define a<BR>> programming language in an implementation-independent way. One could<BR>> argue that in this respect its authors have been so successful that<BR>> they have created serious doubts as to whether it could be implemented<BR>> at all! The report gloriously demonstrated the power of the formal<BR>> method BNF, now fairly known as Backus-Naur-Form, and the power of<BR>> carefully phrased English, a least when used by someone as brilliant<BR>> as Peter Naur. I think that it is fair to say that only very few<BR>> documents as short as this have had an equally profound influence<BR>> on the computing community. The ease with which in later years the<BR>> names ALGOL and ALGOL-like have been used, as an unprotected trade<BR>> mark, to lend some of its glory to a number of sometimes hardly<BR>> related younger projects, is a somewhat shocking compliment to its<BR>> standing. The strength of BNF as a defining device is responsible<BR>> for what I regard as one of the weaknesses of the language: an<BR>> over-elaborate and not too systematic syntax could now be crammed<BR>> into the confines of very few pages. With a device as powerful as<BR>> BNF, the Report on the Algorithmic Language ALGOL 60 should have<BR>> been much shorter... [talk about parameter-passing in Algol 60]<BR>> <BR>> How large a data structure a given program can process is clearly<BR>> part of its interface, like so: <BR>> <BR>> PROCEDURE A(VAR r : ARRAY OF INTEGER);<BR>> (* A causes operation op to occur on r. <BR>> It requires that r be no larger than 10 elements *)<BR>> <BR>> Whether that particular bit of information can be represented in a<BR>> machine-readable form or not is open to question, but irrelevant.<BR>> <BR>> C and C++ don't get much in the way of static verification not<BR>> because they have messy syntax but because they have poorly understood<BR>> (sometimes, plainly undefined, I am told) semantics. And yes that<BR>> is why they started with Modula-3. The readers and writers (Rd and<BR>> Wr) libraries, as they came out of SRC, have been statically verified<BR>> to be entirely free of deadlock and I believe also incorrect data<BR>> accesses. I was at a talk that Greg Nelson gave about this at<BR>> Caltech a few years ago, but I don't remember all the details---just<BR>> that they found a few previously unknown bugs. This is what all<BR>> those <* LL *> pragmas are all about. The ESC project continued<BR>> with Java. I think the people are all at Microsoft now, but ESC<BR>> is still available, I believe both for Modula-3 and Java (I think<BR>> the Java version is still written in Modula-3). Btw, the example<BR>> that Greg Nelson showed when he gave his demo (live on a laptop!)<BR>> *did* catch a problem with + vs. - (well it was an array index that<BR>> was off by 1, and it was caught statically, but it clearly depended<BR>> on the checker's knowing about + vs. -).<BR>> <BR>> And yes you are right, of course, testing never shows much. Another<BR>> Dijkstraism (from 1970):<BR>> <BR>> Program testing can be used to show the presence of bugs, but never to<BR>> show their absence!<BR>> <BR>> It is clear that if you actually want to be certain your program<BR>> is correct (and some people do, some of the time), you will have<BR>> to invest in some sort of formal reasoning. In order for it to be<BR>> tractable, you need simple languages, languages that are not defined<BR>> by their implementations (because trying to understand that would be <BR>> hopeless). If you can do that, you can at least divide your bugs into<BR>> the categories "application bugs" and "language implementation bugs".<BR>> It is *not* a feature or shortcoming of Modula-3 that its arithmetic<BR>> rolls over instead of raising an exception on overflow. The language spec<BR>> is clear on it: in Modula-3, overflows are to be checked runtime errors.<BR>> It is a compiler shortcoming (or bug) that they aren't checked. <BR>> <BR>> And yes, Modula-3 was far ahead, in exactly the same way that Backus,<BR>> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,<BR>> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.<BR>> But no, absolutely no one has caught up. The utterly vast majority<BR>> of people who deal with computers still have absolutely no understanding<BR>> of how to handle system complexity. I am sure that this sad state<BR>> of affairs is familiar enough to every reader of this email that I<BR>> don't have to multiply examples.<BR>> <BR>> Finally, I'm really not talking about language features.. safe vs.<BR>> unsafe, avoidance of bus errors, etc. It's a question of tools of<BR>> the human mind more than it is a question of compiler implementation<BR>> and runtime systems---not, where do you want to go today? but, do<BR>> you UNDERSTAND where you are going today? Remember that programming<BR>> languages are for HUMANS, not computers. Computers couldn't care<BR>> less what language you are programming in. In fact they would be<BR>> "happier" if you just typed in the machine code directly!<BR>> <BR>> Mika<BR>> <BR>> <BR>> <BR>> Jay writes:<BR>> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_<BR>> >Content-Type: text/plain; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> >Mika, I do need to reread that book, yes. Most of my reading of it was year=<BR>> >s ago.<BR>> >Yes the odds of me confusing checked and unchecked errors are real. I think=<BR>> > I might have speculated as to the way things really are, while talking mai=<BR>> >nly about how things perhaps are not.<BR>> >=20<BR>> >However..I still believe the implementation is the interface.<BR>> >I don't see how Modula-3 fixes that.<BR>> >=20<BR>> >> If you use the garbage collector alluded to by Knuth, timing changes> in =<BR>> >your program CANNOT cause it to run out of memory.<BR>> >I didn't mean to necessarily link these things together.<BR>> >Let's say garbage is collected immedately upon it being created.<BR>> >A program still has a certain amount of non-garbage memory allocated at any=<BR>> > one time, and that amount might grow or shrink as changes are made to the =<BR>> >code.<BR>> >=20<BR>> >How about this backwards example: Let's say I have some code that does a he=<BR>> >ap allocation and handles arbitrarily large data. I find it is slow and I r=<BR>> >eplace it with a fixed sized array. Boom, I break anyone using large data. =<BR>> >Now, granted, this is a dumb, backwards example. But it is an implementatio=<BR>> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=<BR>> >erface. If you get those to match, well, great, your stack won't be unbalan=<BR>> >ced, safe code will be safe, but nothing will necessarily be correct.<BR>> >=20<BR>> > > If you use the Extended Static Checker (coded by some of the same people=<BR>> > > who did Modula-3), timing changes to your program CANNOT expose unknown=<BR>> >=20<BR>> >Well...I'm ignorant of this particular checker. I am familiar with some of =<BR>> >the static checking that is ot there. Only recently have I seen any static =<BR>> >checking for race conditions. This is against and C and C++ code, mind you.=<BR>> > Perhaps they "resisted" static analysis until recently, hard to parse and =<BR>> >all that.. Anyway, while I am not an expert on static checking potential an=<BR>> >d practise, I have seen just an astounding number of "crazy" bugs and I don=<BR>> >'t see much hope for much automatic bug detection. Most of the "bugs" found=<BR>> > by static checking are very basic things, like leaks or forgetting to chec=<BR>> >k an error, and never something particularly high level as to what the code=<BR>> > is actually supposed to do. I mean..I'm not sure this is a valid example o=<BR>> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=<BR>> > a terrible typist and I implement Plus with - and Minus with +. What stati=<BR>> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=<BR>> > testing will catch it. But I think the point is valid -- static checking n=<BR>> >ever checks much. Generalized automatic checking never checks much. The bes=<BR>> >t you can do is along the lines of m3-sys/tests -- a small "framework" for =<BR>> >"running stuff" and "comparing the output against expected", perhaps being =<BR>> >amitious and including "negative tests" (make sure erroneous source code fa=<BR>> >ils to compile and gives a good error message).<BR>> >=20<BR>> >I guess, to put a positive light on things, the best we can hope for is som=<BR>> >e sort of composition of larger systems out of available parts that are alr=<BR>> >eady well tested and known to work fairly well. However, this is just..like=<BR>> >..a fractal. Those available parts are built up out of yet again smaller we=<BR>> >ll tested parts. And so on down the line. And no layer or part is free of b=<BR>> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which =<BR>> >are really nothing special -- just another bunch of libraries) have bugs. "=<BR>> >There are bugs everywhere". "More code =3D> more bugs, even if that code is=<BR>> > meant to find bugs, such as assertion failures" =3D> people put in incorre=<BR>> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=<BR>> >ion.<BR>> >=20<BR>> >I just don't see static checking making all that much headway against the t=<BR>> >remendous variety of things programmers do wrong. "Safety" is a nice step, =<BR>> >get the easy things, the buffer overflows, but that still leaves lots of ro=<BR>> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=<BR>> >le....)<BR>> >=20<BR>> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=<BR>> >ave caught up.<BR>> >I grant that most of the systems that have caught up might not catch all th=<BR>> >e way up, they are either not as safe or not as performant.<BR>> >=20<BR>> >Again, really, I think correctness is about far more than safety, and that =<BR>> >implementation is interface, because safety or no safety, code can depend o=<BR>> >n nearly arbitrary characteristics of the code it uses.<BR>> >=20<BR>> >Ok, I'm repeating myself now, sorry.<BR>> >=20<BR>> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=<BR>> > some problems. It doesn't do the impossible.<BR>> >=20<BR>> >Have you used the NT386 system btw? One of the great things about Modula-3 =<BR>> >is only parsing the headers once, and a resulting very fast compiler. Howev=<BR>> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=<BR>> >piler is just way way way way faster than the gcc backend... you (all) shou=<BR>> >ld try it.<BR>> >=20<BR>> >Gotta go,<BR>> > - Jay<BR>> ><BR>> ><BR>> ><BR>> >> To: jayk123@hotmail.com> CC: m3devel@elegosoft.com> Subject: Re: [M3devel=<BR>> >] Do I remember well... > Date: Mon, 25 Feb 2008 18:19:16 -0800> From: mika=<BR>> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=<BR>> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=<BR>> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=<BR>> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=<BR>> >checked runtime errors can occur only in unsafe modules."> > If I may make =<BR>> >one of those philosophical diversions that so often> lead to Language Wars =<BR>> >(but in this case isn't intended to), you> mentioned something a while back=<BR>> > along the lines of (I am not quoting> you verbatim) "every line of code is=<BR>> > part of an application's> interface, because it can cause...a change in me=<BR>> >mory usage or expose> a previously unknown race condition"..> > The whole p=<BR>> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=<BR>> >hinking, even, under which this isn't true.> > If you use the garbage colle=<BR>> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=<BR>> >o run out of memory.> > If you use the Extended Static Checker (coded by so=<BR>> >me of the same people> who did Modula-3), timing changes to your program CA=<BR>> >NNOT expose unknown> race conditions because there ARE no race conditions i=<BR>> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=<BR>> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=<BR>> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=<BR>> >ecked> runtime errors!> > Now it is true that we live in an imperfect world=<BR>> >, and that neither> any mortal nor any product of any mortal is perfect, bu=<BR>> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=<BR>> >erfection!!!! All of its users are longing to one day be programming> in th=<BR>> >e Elysian Fields where there are no race conditions, heap> overflows due to=<BR>> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=<BR>> >et there? I don't know. But for me at> least, one of the reasons I use Modu=<BR>> >la-3 is because it tries, and> I can see how one might fill in the gaps and=<BR>> > get it all the way.> I know of no other programming environment that comes=<BR>> > to within> several orders of magnitude of Modula-3's performance and satis=<BR>> >fies> the same properties.> > Integer overflow: the Green Book says that th=<BR>> >e language catches it.> Implementations generally don't, as far as I know.>=<BR>> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=<BR>> >e:> >This sounds very much how Windows has been but finally changed. > > > =<BR>> >> It used to be in C++ you could do: > > > > try { printf("%s\n", (char*) 1=<BR>> >); } /* access violation, reading from address 1 */ > > else catch (...) { =<BR>> >printf("caught exception\n"); } > > > > now you can't. > > Now catch (...) =<BR>> >catches all C++ exceptions but not these "Win32 structured exceptions". > >=<BR>> > "Win32 structured exceptions" are generally "hardware exceptions" made vis=<BR>> >ible to software. > > The most common one is an "access violation". There's=<BR>> > also "stack overflow". And others.> > They can be raised by code via Raise=<BR>> >Exception though.> > > > There is a similar syntax for catching them -- __t=<BR>> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=<BR>> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=<BR>> >ll into two or three classes:> > Someone called RaiseException. These are o=<BR>> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=<BR>> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=<BR>> >cess violated" (aka: some sort of signal/tap on Unix) > > This is the more =<BR>> >common case, and if you catch such an exception, you have to wonder, uh, so=<BR>> >me data is corrupt..which data? What can I possily do at this point, given =<BR>> >that some dat> >a somewhere is corrupt? It could be the heap. It could be t=<BR>> >he stack. It could be something small that I'm not going to touch. Heck, ma=<BR>> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=<BR>> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=<BR>> >n adequate job of noticing things as soon as they have gone bad, and not at=<BR>> > an indeterminate point afterward, that sounds more viable. I suspect this =<BR>> >might be the cas> >e, as long as you haven't called out to some buggy C cod=<BR>> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=<BR>> >r. :)> > > > - Jay=20<BR>> >_________________________________________________________________<BR>> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=<BR>> >r power.<BR>> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=<BR>> >n=<BR>> ><BR>> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_<BR>> >Content-Type: text/html; charset="iso-8859-1"<BR>> >Content-Transfer-Encoding: quoted-printable<BR>> ><BR>> ><html><BR>> ><head><BR>> ><style><BR>> >.hmmessage P<BR>> >{<BR>> >margin:0px;<BR>> >padding:0px<BR>> >}<BR>> >body.hmmessage<BR>> >{<BR>> >FONT-SIZE: 10pt;<BR>> >FONT-FAMILY:Tahoma<BR>> >}<BR>> ></style><BR>> ></head><BR>> ><body class=3D'hmmessage'>Mika, I do need to reread that book, yes. Most of=<BR>> > my reading of it was years ago.<BR><BR>> >Yes the odds of me confusing checked and unchecked errors are real. I think=<BR>> > I might have speculated as to the way things really are, while talking mai=<BR>> >nly about how things perhaps are not.<BR><BR>> > <BR><BR>> >However..I still believe the implementation is the interface.<BR><BR>> >I don't see how Modula-3 fixes that.<BR><BR>> > <BR><BR>> >> If you use the garbage collector alluded to by Knuth, timing changes<B=<BR>> >R>> in your program CANNOT cause it to run out of memory.<BR><BR><BR>> >I didn't mean to necessarily link these things together.<BR><BR>> >Let's say garbage is collected immedately upon it being created.<BR><BR>> >A program still has a certain amount of non-garbage memory allocated at any=<BR>> > one time, and that amount might grow or shrink as changes are made to the =<BR>> >code.<BR><BR>> > <BR><BR>> >How about this backwards example: Let's say I have some code that does a he=<BR>> >ap allocation and handles arbitrarily large data. I find it is slow and I r=<BR>> >eplace it with a fixed sized array. Boom, I break anyone using large data. =<BR>> >Now, granted, this is a dumb, backwards example. But it is an implementatio=<BR>> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=<BR>> >erface. If you get those to match, well, great, your stack won't be unbalan=<BR>> >ced, safe code will be safe, but nothing will necessarily be correct.<BR><BR>> > <BR><BR>> > > If you use the Extended Static Checker (coded by some of the sam=<BR>> >e people <BR> > who did Modula-3), timing changes to your program C=<BR>> >ANNOT expose unknown <BR><BR><BR>> >Well...I'm ignorant of this particular checker. I am familiar with some of =<BR>> >the static checking that is ot there. Only recently have I seen any static =<BR>> >checking for race conditions. This is against and C and C++ code, mind you.=<BR>> > Perhaps they "resisted" static analysis until recently, hard to parse and =<BR>> >all that.. Anyway, while I am not an expert on static checking potential an=<BR>> >d practise, I have seen just an astounding number of "crazy" bugs and I don=<BR>> >'t see much hope for much automatic bug detection. Most of the "bugs" found=<BR>> > by static checking are very basic things, like leaks or forgetting to chec=<BR>> >k an error, and never something particularly high level as to what the code=<BR>> > is actually supposed to do. I mean..I'm not sure this is a valid example o=<BR>> >r not, but let's say I have the functions Plus and Minus, and let's say I'm=<BR>> > a terrible typist and I implement Plus with - and Minus with +. What stati=<BR>> >c checking will catch that. Now, yes, I grant, any amount of manual dynamic=<BR>> > testing will catch it. But I think the point is valid -- static checking n=<BR>> >ever checks much. Generalized automatic checking never checks much. The bes=<BR>> >t you can do is along the lines of m3-sys/tests -- a small "framework" for =<BR>> >"running stuff" and "comparing the output against expected", perhaps being =<BR>> >amitious and including "negative tests" (make sure erroneous source code fa=<BR>> >ils to compile and gives a good error message).<BR><BR>> > <BR><BR>> >I guess, to put a positive light on things, the best we can hope for is som=<BR>> >e sort of composition of larger systems out of available parts that are alr=<BR>> >eady well tested and known to work fairly well. However, this is just..like=<BR>> >..a fractal. Those available parts are built up out of yet again smaller we=<BR>> >ll tested parts. And so on down the line. And no layer or part is free of b=<BR>> >ugs. Processors have bugs. Compilers have bugs. "operating systems" (which =<BR>> >are really nothing special -- just another bunch of libraries) have bugs. "=<BR>> >There are bugs everywhere". "More code =3D> more bugs, even if that code=<BR>> > is meant to find bugs, such as assertion failures" =3D> people put in i=<BR>> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the =<BR>> >assertion.<BR><BR>> > <BR><BR>> >I just don't see static checking making all that much headway against the t=<BR>> >remendous variety of things programmers do wrong. "Safety" is a nice step, =<BR>> >get the easy things, the buffer overflows, but that still leaves lots of ro=<BR>> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=<BR>> >le....)<BR><BR>> > <BR><BR>> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=<BR>> >ave caught up.<BR><BR>> >I grant that most of the systems that have caught up might not catch all th=<BR>> >e way up, they are either not as safe or not as performant.<BR><BR>> > <BR><BR>> >Again, really, I think correctness is about far more than safety, and that =<BR>> >implementation is interface, because safety or no safety, code can depend o=<BR>> >n nearly arbitrary characteristics of the code it uses.<BR><BR>> > <BR><BR>> >Ok, I'm repeating myself now, sorry.<BR><BR>> > <BR><BR>> >I don't think I see an argument here btw. Modula-3 is what it is. It solves=<BR>> > some problems. It doesn't do the impossible.<BR><BR>> > <BR><BR>> >Have you used the NT386 system btw? One of the great things about Modula-3 =<BR>> >is only parsing the headers once, and a resulting very fast compiler. Howev=<BR>> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=<BR>> >piler is just way way way way faster than the gcc backend... you (all) shou=<BR>> >ld try it.<BR><BR>> > <BR><BR>> >Gotta go,<BR><BR>> > - Jay<BR><BR><BR><BR>> ><BR>> ><HR id=3DstopSpelling><BR>> ><BR><BR>> >> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subj=<BR>> >ect: Re: [M3devel] Do I remember well... <BR>> Date: Mon, 25 Feb 2008 18=<BR>> >:19:16 -0800<BR>> From: mika@async.caltech.edu<BR>> <BR>> Jay,<BR>=<BR>> >> <BR>> Sometimes I wonder if you have never read the Green Book!!!<B=<BR>> >R>> <BR>> The very first section of the Modula-3 definition, Section =<BR>> >2.1 of<BR>> the Green Book, talks about the distinction between "checked=<BR>> > runtime<BR>> errors" and "unchecked runtime errors" and ends with the s=<BR>> >entence<BR>> "Unchecked runtime errors can occur only in unsafe modules.=<BR>> >"<BR>> <BR>> If I may make one of those philosophical diversions that=<BR>> > so often<BR>> lead to Language Wars (but in this case isn't intended to=<BR>> >), you<BR>> mentioned something a while back along the lines of (I am no=<BR>> >t quoting<BR>> you verbatim) "every line of code is part of an applicati=<BR>> >on's<BR>> interface, because it can cause...a change in memory usage or =<BR>> >expose<BR>> a previously unknown race condition"..<BR>> <BR>> The =<BR>> >whole point of Modula-3 is that Modula-3 is part of a family<BR>> of too=<BR>> >ls, a way of thinking, even, under which this isn't true.<BR>> <BR>> =<BR>> >If you use the garbage collector alluded to by Knuth, timing changes<BR>>=<BR>> >; in your program CANNOT cause it to run out of memory.<BR>> <BR>> If=<BR>> > you use the Extended Static Checker (coded by some of the same people<BR>&=<BR>> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=<BR>> ><BR>> race conditions because there ARE no race conditions in your progr=<BR>> >am!<BR>> <BR>> And if you use Modula-3 the way you're supposed to---t=<BR>> >hat is, use the<BR>> safe features almost exclusively and use UNSAFE cod=<BR>> >e so sparingly that<BR>> it is obviously (i.e., provably) correct, you w=<BR>> >ill have NO unchecked<BR>> runtime errors!<BR>> <BR>> Now it is tr=<BR>> >ue that we live in an imperfect world, and that neither<BR>> any mortal =<BR>> >nor any product of any mortal is perfect, but the WHOLE<BR>> POINT of Mo=<BR>> >dula-3 is to be a stepping-stone to this type of<BR>> perfection!!!! All=<BR>> > of its users are longing to one day be programming<BR>> in the Elysian =<BR>> >Fields where there are no race conditions, heap<BR>> overflows due to la=<BR>> >zy garbage collectors, nor any unchecked runtime<BR>> errors. Will we ev=<BR>> >er get there? I don't know. But for me at<BR>> least, one of the reasons=<BR>> > I use Modula-3 is because it tries, and<BR>> I can see how one might fi=<BR>> >ll in the gaps and get it all the way.<BR>> I know of no other programmi=<BR>> >ng environment that comes to within<BR>> several orders of magnitude of =<BR>> >Modula-3's performance and satisfies<BR>> the same properties.<BR>> <=<BR>> >BR>> Integer overflow: the Green Book says that the language catches it.=<BR>> ><BR>> Implementations generally don't, as far as I know.<BR>> <BR>>=<BR>> >; The specification is really only fifty pages long...<BR>> <BR>> Mik=<BR>> >a<BR>> <BR>> Jay wrote:<BR>> >This sounds very much how Windows=<BR>> > has been but finally changed. <BR>> > <BR>> > It used to be in=<BR>> > C++ you could do: <BR>> > <BR>> > try { printf("%s\n", (char*)=<BR>> > 1); } /* access violation, reading from address 1 */ <BR>> > else ca=<BR>> >tch (...) { printf("caught exception\n"); } <BR>> > <BR>> > now=<BR>> > you can't. <BR>> > Now catch (...) catches all C++ exceptions but no=<BR>> >t these "Win32 structured exceptions". <BR>> > "Win32 structured exce=<BR>> >ptions" are generally "hardware exceptions" made visible to software. <BR>&=<BR>> >gt; > The most common one is an "access violation". There's also "stack =<BR>> >overflow". And others.<BR>> > They can be raised by code via RaiseExc=<BR>> >eption though.<BR>> > <BR>> > There is a similar syntax for cat=<BR>> >ching them -- __try / __except. <BR>> > <BR>> > Now, maybe Modu=<BR>> >la-3 runtime errors are "more orderly" and so more "catchable"?<BR>> >=<BR>> >; In particular, Win32 structured exceptions fall into two or three classes=<BR>> >:<BR>> > Someone called RaiseException. These are orderly and reasona=<BR>> >ble to catch, but rare. <BR>> > (Even if C++ exceptions are implement=<BR>> >ed via RaiseException.) <BR>> > Someone has some corrupted data and "=<BR>> >access violated" (aka: some sort of signal/tap on Unix) <BR>> > This =<BR>> >is the more common case, and if you catch such an exception, you have to wo=<BR>> >nder, uh, some data is corrupt..which data? What can I possily do at this p=<BR>> >oint, given that some dat<BR>> >a somewhere is corrupt? It could be t=<BR>> >he heap. It could be the stack. It could be something small that I'm not go=<BR>> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" <BR=<BR>> >>> >corrupt. I suggest a NULL deref might be the third class, but not=<BR>> > clear.<BR>> > <BR>> >If Modula-3 does an adequate job of notic=<BR>> >ing things as soon as they have gone bad, and not at an indeterminate point=<BR>> > afterward, that sounds more viable. I suspect this might be the cas<BR>>=<BR>> >; >e, as long as you haven't called out to some buggy C code or some uns=<BR>> >afe Modula-3, oops.<BR>> > <BR>> >What about integer overflow? =<BR>> >I wonder. :)<BR>> > <BR>> > - Jay <BR><BR><br /><hr />Climb to =<BR>> >the top of the charts!=A0Play the word scramble challenge with star power. =<BR>> ><a href=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmail=<BR>> >textlink_jan' target=3D'_new'>Play now!</a></body><BR>> ></html>=<BR>> ><BR>> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_--<BR><BR><br /><hr />Need to know the score, the latest news, or you need your HotmailŪ-get your "fix". <a href='http://www.msnmobilefix.com/Default.aspx' target='_new'>Check it out.</a></body>
</html>