[M3devel] Do I remember well...

[Jay]

Mika you underestimate me somewhat but maybe not entirely.
I have never used Algol.I should do a bit more research.
BNF to me is, you know, like a grammar, LALR, LL, yacc, PCCTS, whatever.
It is very useful step, a very good way to state what it states.But as I understand only describes syntax and not semantics.
I could say is:English: subject verb [and verb]*Jay sits. okJay stands. okJay gallops. Syntactically correct but not semantically. Jay is not a horse.It is not type correct. Programming languages catch these errors usually,you don't need "extended static checking".Or you could be type correct but still wrong:Jay dies and lives.
Something has to know that living cannot occur after dying.How do I state that?
I think C++ is actually underappreciated here.Stroupstrup alludes to a style of programming where all side affectsare via constructor calls. I believe this is "very functional".I haven't yet seen anyone elaborate on this.Add type safety to that."Jay = Jay->die()" would return a subtype of human_t that does not have the live() method.Type checking can possibly do a lot of this.(sorry this is so morbid, I had to think of operations that could not go in acertain sequqence. I guess a better one would be Jay learns to program and Jay is born.)
Being syntactically correct is a necessary first step, and thencomes type safety, and then comes actually doing what is intended.
Maybe BNF has more features than I assume.
I have been exposed to multiple opposing views, such as:
as you say -- programs are for people first, computers second The SICP book was very interesting..
and the contrary -- performance, performance, performance
Too much abstraction and you lose touch with the machine that doesultimately have to run your creation and if it is runs it too slowly,well, that does matter. (Humans are not going to run your program
after all; they are much too slow.)
I have a lot of real world practical experience.Not as much maybe as I should but a lot.
 > How large a data structure a given program can process is clearly > part of its interface, like so: > PROCEDURE A(VAR r : ARRAY OF INTEGER); > (* A causes operation op to occur on r. It requires that r be no larger than 10 elements *) 
Your example proves my point. The "specification" is a comment written in English.Nothing will check it. It might change. Worse, the level of detail in a commentis totally up to the programmer. If the comment was missing, what would theinterface be? That the function does nothing?
I contend that there is no language that can state the complete specification.The language of the implementation comes close, however it then rests on what is below it,and so on down the line. Science has apparently figured out enough that "and so on downthe line" doesn't go all that far. We know the computer is digital, 0s and 1s, we don't haveto talk about how the transistors work to spec a function.
I will look into the sleep.Can it not be a, um, a wait? You know, wait specifically for the process to exit?At the same time as reading its stdout and stderr?Actually I have some experience here...It turns out, on Windows, that it is very easy to deadlock writing code like this.There about three simple patterns, one that deadlocks, two that don't.
pseudo code:
1)process = CreateProcess();if process not done   read some from stdout     echo it to my stdout   read some from stderr     echo it to my stderr
This can deadlock.IF the child process ONLY writes to one of stdout or stderr, I think no deadlock.But if it writes to both, can deadlock.
2)process = CreateProcesscreate another thread (or have one already created waiting for work to do)optionally create another thread for symmetry of implementation, but inefficienthave one thread read/echo stderr, the other read/echo stdoutThis won't deadlock.
3)create the process such that stdout and stderr are the samethen just read that one pipe/handle/file/whatever, on one thread
I guess, I have to check, I think on Windows you do like WaitForMultipleObjects(2, [pipe and process]).I have to check if the pipe is signaled by having data available.
And then I have to look into what Posix offers here.Maybe have NT386GNU not use Posix here, however..having tried this for "serial", having done it with Thread,the various implementation pieces are not always so easily mixed and matched.For example PosixFile wants PosixScheduler, which is not usually "with" ThreadWin32, but I put in a dummy one.
Having both FileWin32 and FilePosix available, with one being the revealer of File.T would be good.I think this is a simple restructuring of the code.
Knowing the machine model and how your code ends up executing on the machine is not at all a bad thing.Being careful with how large the abstraction layers you build is not a bad thing.Making a compromise between human and computer is not a bad thing.I long ago gave up writting in assembly, after all.However I am constantly viewing assembly, partly by dumb virtue of how my debugger works, butalso partly because there are bugs everywhere and everything you hide from me is an opportunityfor you to hide the bug I am looking for.
Every abstraction you build is something that is going to have bugs in it that I'm going to have to debug.
The less abstraction, the thinner the layers, the less debugging will be needed.
But yet you do absolutely need abstraction.
There is this term -- "leaky abstraction".Most abstractions leak underlying details, there it is useful to understand as much of the stack as possible.
Yes, I understand, it is important to know what is an implementation detail and what is an interface/behavioralguarantee. They are often blurred. One of the things good about Modula-3 is its "portability".
The fact that I can do roughly the same things already on NT386, PPC_DARWIN, PPC_LINUX "keeps my honest".I can fairly readily check my work on three kind of different systems.
The counterpoint here however is that at the C level and above, all machines are converging ontwo and only two models -- Windows and Posix.Portability is becoming like English. Or English and French.Rather than come up with some very very broad commonality that you believe will be implementableon forseeable architectures, you merely have to fit only two common cases.Or heck, if Cygwin flies, only one common case.(Btw, AMD64_MINGWIN should be fairly easy to implement today, AMD64_CYGWIN not so much.There are already AMD64 MinGWin distributes. Cygwin is loaded with assembly cod and the FAQ/docsare not optimistic about AMD64. So Cygwin isn't clearly a way forward.The integrated backend of course needs work and should be viable.)
Yes I know LL is about static checking of locking, though I don't know how to read/write the pragmas.I also noticed the large or lm3 or whatnot files.I should look into what they can state and check.
I relatively recently amassed a fairly large collection of compilers in order to "test portability".Man it is a bit sad. CFront based C++ compilers are awful. Only one return statement per functionor something. Maybe this experiment went overboard and there's a smaller number of interestingmodern tools..
Most of the stuff that is left "undefined" in C is very reasonable to leave undefined.For example, signed integer encoding is not specified.Things like going out of bounds on arrays is probably not specified.The reason is obvious -- because it is expensive to check.I have heard of code accidentally depending on array bounds overflow.Two local variables, one could overflow into the other, accidentally doubling the capacity of the program!
 > in this you are joined by 99% of people who use computers 
Equating a PROGRAMMER with 99% of computer USERS is very insulting.Really.The family/relative tech support I do..."click the whatever." "Right click or left click?"I have had that question so many times. Good thing three button mice are not prevalent. :)(and please don't insult whoever asked me that question..)
The rude thing to wonder here is something about practicality vs. theory....The Modula-3 is actually squarely in the practical camp.What with having the compiler and garbage collector implemented it, for starters.
I have used Scheme btw, and I was very enamored of it.Then I started debugging some of it by stepping through STk.Man every other instruction was a type check. Despite that 99% of the type checksall succeeded, or had even already succeeded against that data.It's a great programming model, but perhaps? too difficult to implement efficiently?I don't know. One hole in my experience is working with or implementing systems that infer types,except as a user of C++ templates, which does involve a significant amount of type inference.But it's not e.g. SML or a high end efficient compilation Scheme/Lisp.
Meanwhile, the mailing lists are still down.
Later, - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Do I remember well... > Date: Mon, 25 Feb 2008 19:47:03 -0800> From: mika at async.caltech.edu> > > I believe the main reason the compiler is slow on most platforms> is that it sleeps for 0.1 seconds every time it spawns a process.> My private version of the compiler has that sleep taken out and> runs probably 20x faster (for a typical compile).> > Jay, I still say you are ignorant of a huge part of the history of> Computer Science---in this you are joined by 99% of people who use> computers, by the way. You should in fact not start with the Green> Book, but with this:> > http://www.masswerk.at/algol60/report.htm> > And reflect upon these words (again, from "The Humble Programmer", Dijkstra's> 1972 Turing Award lecture):> > The fourth project to be mentioned is ALGOL 60. While up to the> present day FORTRAN programmers still tend to understand their> programming language in terms of the specific implementation they> are working with hence the prevalence of octal and hexadecimal> dumps, while the definition of LISP is still a curious mixture of> what the language means and how the mechanism works, the famous> Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine> effort to carry abstraction a vital step further and to define a> programming language in an implementation-independent way. One could> argue that in this respect its authors have been so successful that> they have created serious doubts as to whether it could be implemented> at all! The report gloriously demonstrated the power of the formal> method BNF, now fairly known as Backus-Naur-Form, and the power of> carefully phrased English, a least when used by someone as brilliant> as Peter Naur. I think that it is fair to say that only very few> documents as short as this have had an equally profound influence> on the computing community. The ease with which in later years the> names ALGOL and ALGOL-like have been used, as an unprotected trade> mark, to lend some of its glory to a number of sometimes hardly> related younger projects, is a somewhat shocking compliment to its> standing. The strength of BNF as a defining device is responsible> for what I regard as one of the weaknesses of the language: an> over-elaborate and not too systematic syntax could now be crammed> into the confines of very few pages. With a device as powerful as> BNF, the Report on the Algorithmic Language ALGOL 60 should have> been much shorter... [talk about parameter-passing in Algol 60]> > How large a data structure a given program can process is clearly> part of its interface, like so: > > PROCEDURE A(VAR r : ARRAY OF INTEGER);> (* A causes operation op to occur on r. > It requires that r be no larger than 10 elements *)> > Whether that particular bit of information can be represented in a> machine-readable form or not is open to question, but irrelevant.> > C and C++ don't get much in the way of static verification not> because they have messy syntax but because they have poorly understood> (sometimes, plainly undefined, I am told) semantics. And yes that> is why they started with Modula-3. The readers and writers (Rd and> Wr) libraries, as they came out of SRC, have been statically verified> to be entirely free of deadlock and I believe also incorrect data> accesses. I was at a talk that Greg Nelson gave about this at> Caltech a few years ago, but I don't remember all the details---just> that they found a few previously unknown bugs. This is what all> those <* LL *> pragmas are all about. The ESC project continued> with Java. I think the people are all at Microsoft now, but ESC> is still available, I believe both for Modula-3 and Java (I think> the Java version is still written in Modula-3). Btw, the example> that Greg Nelson showed when he gave his demo (live on a laptop!)> *did* catch a problem with + vs. - (well it was an array index that> was off by 1, and it was caught statically, but it clearly depended> on the checker's knowing about + vs. -).> > And yes you are right, of course, testing never shows much. Another> Dijkstraism (from 1970):> > Program testing can be used to show the presence of bugs, but never to> show their absence!> > It is clear that if you actually want to be certain your program> is correct (and some people do, some of the time), you will have> to invest in some sort of formal reasoning. In order for it to be> tractable, you need simple languages, languages that are not defined> by their implementations (because trying to understand that would be > hopeless). If you can do that, you can at least divide your bugs into> the categories "application bugs" and "language implementation bugs".> It is *not* a feature or shortcoming of Modula-3 that its arithmetic> rolls over instead of raising an exception on overflow. The language spec> is clear on it: in Modula-3, overflows are to be checked runtime errors.> It is a compiler shortcoming (or bug) that they aren't checked. > > And yes, Modula-3 was far ahead, in exactly the same way that Backus,> Bauer, Green, Katz, McCarthy, Naur, Perlis, Rutishauser, Samuelson,> Vauquois, Wegstein, van Wijngaarden, and Woodger were---in 1960.> But no, absolutely no one has caught up. The utterly vast majority> of people who deal with computers still have absolutely no understanding> of how to handle system complexity. I am sure that this sad state> of affairs is familiar enough to every reader of this email that I> don't have to multiply examples.> > Finally, I'm really not talking about language features.. safe vs.> unsafe, avoidance of bus errors, etc. It's a question of tools of> the human mind more than it is a question of compiler implementation> and runtime systems---not, where do you want to go today? but, do> you UNDERSTAND where you are going today? Remember that programming> languages are for HUMANS, not computers. Computers couldn't care> less what language you are programming in. In fact they would be> "happier" if you just typed in the machine code directly!> > Mika> > > > Jay writes:> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >Mika, I do need to reread that book, yes. Most of my reading of it was year=> >s 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 mai=> >nly about how things perhaps are not.> >=20> >However..I still believe the implementation is the interface.> >I don't see how Modula-3 fixes that.> >=20> >> 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.> >=20> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace 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 implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.> >=20> > > 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=> >=20> >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 an=> >d 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 chec=> >k 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 o=> >r 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 stati=> >c 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 n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t 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 fa=> >ils to compile and gives a good error message).> >=20> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady 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 we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. 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 =3D> more bugs, even if that code is=> > meant to find bugs, such as assertion failures" =3D> people put in incorre=> >ct assertions, oops, they trigger, let's go and remove or loosen the assert=> >ion.> >=20> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)> >=20> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.> >=20> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.> >=20> >Ok, I'm repeating myself now, sorry.> >=20> >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.> >=20> >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. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.> >=20> >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=> >@async.caltech.edu> > Jay,> > Sometimes I wonder if you have never read the=> > Green Book!!!> > The very first section of the Modula-3 definition, Sectio=> >n 2.1 of> the Green Book, talks about the distinction between "checked runt=> >ime> errors" and "unchecked runtime errors" and ends with the sentence> "Un=> >checked 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 me=> >mory usage or expose> a previously unknown race condition"..> > The whole p=> >oint of Modula-3 is that Modula-3 is part of a family> of tools, a way of t=> >hinking, even, under which this isn't true.> > If you use the garbage colle=> >ctor alluded to by Knuth, timing changes> in your program CANNOT cause it t=> >o run out of memory.> > If you use the Extended Static Checker (coded by so=> >me of the same people> who did Modula-3), timing changes to your program CA=> >NNOT expose unknown> race conditions because there ARE no race conditions i=> >n your program!> > And if you use Modula-3 the way you're supposed to---tha=> >t is, use the> safe features almost exclusively and use UNSAFE code so spar=> >ingly that> it is obviously (i.e., provably) correct, you will have NO unch=> >ecked> 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, bu=> >t the WHOLE> POINT of Modula-3 is to be a stepping-stone to this type of> p=> >erfection!!!! All of its users are longing to one day be programming> in th=> >e Elysian Fields where there are no race conditions, heap> overflows due to=> > lazy garbage collectors, nor any unchecked runtime> errors. Will we ever g=> >et there? I don't know. But for me at> least, one of the reasons I use Modu=> >la-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 satis=> >fies> the same properties.> > Integer overflow: the Green Book says that th=> >e language catches it.> Implementations generally don't, as far as I know.>=> > > The specification is really only fifty pages long...> > Mika> > Jay wrot=> >e:> >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 vis=> >ible to software. > > The most common one is an "access violation". There's=> > also "stack overflow". And others.> > They can be raised by code via Raise=> >Exception though.> > > > There is a similar syntax for catching them -- __t=> >ry / __except. > > > > Now, maybe Modula-3 runtime errors are "more orderly=> >" and so more "catchable"?> > In particular, Win32 structured exceptions fa=> >ll into two or three classes:> > Someone called RaiseException. These are o=> >rderly and reasonable to catch, but rare. > > (Even if C++ exceptions are i=> >mplemented via RaiseException.) > > Someone has some corrupted data and "ac=> >cess 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, so=> >me 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 t=> >he stack. It could be something small that I'm not going to touch. Heck, ma=> >ybe it was merely a NULL deref and nothing "very" > >corrupt. I suggest a N=> >ULL deref might be the third class, but not clear.> > > >If Modula-3 does a=> >n 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 cod=> >e or some unsafe Modula-3, oops.> > > >What about integer overflow? I wonde=> >r. :)> > > > - Jay=20> >_________________________________________________________________> >Climb to the top of the charts!=A0Play the word scramble challenge with sta=> >r power.> >http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja=> >n=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_> >Content-Type: text/html; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> ><html>> ><head>> ><style>> >.hmmessage P> >{> >margin:0px;> >padding:0px> >}> >body.hmmessage> >{> >FONT-SIZE: 10pt;> >FONT-FAMILY:Tahoma> >}> ></style>> ></head>> ><body class=3D'hmmessage'>Mika, I do need to reread that book, yes. Most of=> > my reading of it was years ago.<BR>> >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 mai=> >nly about how things perhaps are not.<BR>> > <BR>> >However..I still believe the implementation is the interface.<BR>> >I don't see how Modula-3 fixes that.<BR>> > <BR>> >> If you use the garbage collector alluded to by Knuth, timing changes<B=> >R>> in your program CANNOT cause it to run out of memory.<BR><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=> > one time, and that amount might grow or shrink as changes are made to the => >code.<BR>> > <BR>> >How about this backwards example: Let's say I have some code that does a he=> >ap allocation and handles arbitrarily large data. I find it is slow and I r=> >eplace 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 implementatio=> >n detail not revealed in the .i3 file. The .i3 file, like, the "binary" int=> >erface. If you get those to match, well, great, your stack won't be unbalan=> >ced, safe code will be safe, but nothing will necessarily be correct.<BR>> > <BR>> > > If you use the Extended Static Checker (coded by some of the sam=> >e people <BR> > who did Modula-3), timing changes to your program C=> >ANNOT expose unknown <BR><BR>> >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 an=> >d 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 chec=> >k 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 o=> >r 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 stati=> >c 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 n=> >ever checks much. Generalized automatic checking never checks much. The bes=> >t 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 fa=> >ils to compile and gives a good error message).<BR>> > <BR>> >I guess, to put a positive light on things, the best we can hope for is som=> >e sort of composition of larger systems out of available parts that are alr=> >eady 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 we=> >ll tested parts. And so on down the line. And no layer or part is free of b=> >ugs. 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 =3D> more bugs, even if that code=> > is meant to find bugs, such as assertion failures" =3D> people put in i=> >ncorrect assertions, oops, they trigger, let's go and remove or loosen the => >assertion.<BR>> > <BR>> >I just don't see static checking making all that much headway against the t=> >remendous variety of things programmers do wrong. "Safety" is a nice step, => >get the easy things, the buffer overflows, but that still leaves lots of ro=> >om for error (look at how my "safe" m3path.m3 broke the tinderbox for examp=> >le....)<BR>> > <BR>> >I think Modula-3 was very far ahead of its time. I think a lot of systems h=> >ave caught up.<BR>> >I grant that most of the systems that have caught up might not catch all th=> >e way up, they are either not as safe or not as performant.<BR>> > <BR>> >Again, really, I think correctness is about far more than safety, and that => >implementation is interface, because safety or no safety, code can depend o=> >n nearly arbitrary characteristics of the code it uses.<BR>> > <BR>> >Ok, I'm repeating myself now, sorry.<BR>> > <BR>> >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.<BR>> > <BR>> >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. Howev=> >er on non-NT386 the gcc backend all but ruins this perf. The integrated com=> >piler is just way way way way faster than the gcc backend... you (all) shou=> >ld try it.<BR>> > <BR>> >Gotta go,<BR>> > - Jay<BR><BR><BR>> >> ><HR id=3DstopSpelling>> ><BR>> >> To: jayk123 at hotmail.com<BR>> CC: m3devel at elegosoft.com<BR>> Subj=> >ect: Re: [M3devel] Do I remember well... <BR>> Date: Mon, 25 Feb 2008 18=> >:19:16 -0800<BR>> From: mika at async.caltech.edu<BR>> <BR>> Jay,<BR>=> >> <BR>> Sometimes I wonder if you have never read the Green Book!!!<B=> >R>> <BR>> The very first section of the Modula-3 definition, Section => >2.1 of<BR>> the Green Book, talks about the distinction between "checked=> > runtime<BR>> errors" and "unchecked runtime errors" and ends with the s=> >entence<BR>> "Unchecked runtime errors can occur only in unsafe modules.=> >"<BR>> <BR>> If I may make one of those philosophical diversions that=> > so often<BR>> lead to Language Wars (but in this case isn't intended to=> >), you<BR>> mentioned something a while back along the lines of (I am no=> >t quoting<BR>> you verbatim) "every line of code is part of an applicati=> >on's<BR>> interface, because it can cause...a change in memory usage or => >expose<BR>> a previously unknown race condition"..<BR>> <BR>> The => >whole point of Modula-3 is that Modula-3 is part of a family<BR>> of too=> >ls, a way of thinking, even, under which this isn't true.<BR>> <BR>> => >If you use the garbage collector alluded to by Knuth, timing changes<BR>&gt=> >; in your program CANNOT cause it to run out of memory.<BR>> <BR>> If=> > you use the Extended Static Checker (coded by some of the same people<BR>&=> >gt; who did Modula-3), timing changes to your program CANNOT expose unknown=> ><BR>> race conditions because there ARE no race conditions in your progr=> >am!<BR>> <BR>> And if you use Modula-3 the way you're supposed to---t=> >hat is, use the<BR>> safe features almost exclusively and use UNSAFE cod=> >e so sparingly that<BR>> it is obviously (i.e., provably) correct, you w=> >ill have NO unchecked<BR>> runtime errors!<BR>> <BR>> Now it is tr=> >ue that we live in an imperfect world, and that neither<BR>> any mortal => >nor any product of any mortal is perfect, but the WHOLE<BR>> POINT of Mo=> >dula-3 is to be a stepping-stone to this type of<BR>> perfection!!!! All=> > of its users are longing to one day be programming<BR>> in the Elysian => >Fields where there are no race conditions, heap<BR>> overflows due to la=> >zy garbage collectors, nor any unchecked runtime<BR>> errors. Will we ev=> >er get there? I don't know. But for me at<BR>> least, one of the reasons=> > I use Modula-3 is because it tries, and<BR>> I can see how one might fi=> >ll in the gaps and get it all the way.<BR>> I know of no other programmi=> >ng environment that comes to within<BR>> several orders of magnitude of => >Modula-3's performance and satisfies<BR>> the same properties.<BR>> <=> >BR>> Integer overflow: the Green Book says that the language catches it.=> ><BR>> Implementations generally don't, as far as I know.<BR>> <BR>&gt=> >; The specification is really only fifty pages long...<BR>> <BR>> Mik=> >a<BR>> <BR>> Jay wrote:<BR>> >This sounds very much how Windows=> > has been but finally changed. <BR>> > <BR>> > It used to be in=> > C++ you could do: <BR>> > <BR>> > try { printf("%s\n", (char*)=> > 1); } /* access violation, reading from address 1 */ <BR>> > else ca=> >tch (...) { printf("caught exception\n"); } <BR>> > <BR>> > now=> > you can't. <BR>> > Now catch (...) catches all C++ exceptions but no=> >t these "Win32 structured exceptions". <BR>> > "Win32 structured exce=> >ptions" are generally "hardware exceptions" made visible to software. <BR>&=> >gt; > The most common one is an "access violation". There's also "stack => >overflow". And others.<BR>> > They can be raised by code via RaiseExc=> >eption though.<BR>> > <BR>> > There is a similar syntax for cat=> >ching them -- __try / __except. <BR>> > <BR>> > Now, maybe Modu=> >la-3 runtime errors are "more orderly" and so more "catchable"?<BR>> &gt=> >; In particular, Win32 structured exceptions fall into two or three classes=> >:<BR>> > Someone called RaiseException. These are orderly and reasona=> >ble to catch, but rare. <BR>> > (Even if C++ exceptions are implement=> >ed via RaiseException.) <BR>> > Someone has some corrupted data and "=> >access violated" (aka: some sort of signal/tap on Unix) <BR>> > This => >is the more common case, and if you catch such an exception, you have to wo=> >nder, uh, some data is corrupt..which data? What can I possily do at this p=> >oint, given that some dat<BR>> >a somewhere is corrupt? It could be t=> >he heap. It could be the stack. It could be something small that I'm not go=> >ing to touch. Heck, maybe it was merely a NULL deref and nothing "very" <BR=> >>> >corrupt. I suggest a NULL deref might be the third class, but not=> > clear.<BR>> > <BR>> >If Modula-3 does an adequate job of notic=> >ing 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<BR>&gt=> >; >e, as long as you haven't called out to some buggy C code or some uns=> >afe Modula-3, oops.<BR>> > <BR>> >What about integer overflow? => >I wonder. :)<BR>> > <BR>> > - Jay <BR><BR><br /><hr />Climb to => >the top of the charts!=A0Play the word scramble challenge with star power. => ><a href=3D'http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmail=> >textlink_jan' target=3D'_new'>Play now!</a></body>> ></html>=> >> >--_06ec8a4a-fb05-49f6-9c53-baf326e30ec3_--
_________________________________________________________________
Need to know the score, the latest news, or you need your Hotmail®-get your "fix".
http://www.msnmobilefix.com/Default.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080226/0397053b/attachment-0002.html>