* Re: next "big" language?? (disagree) [not found] <4p0fdd$4ml@news.atlantic.net> @ 1996-06-04 0:00 ` Peter Hermann 1996-06-04 0:00 ` The Amorphous Mass ` (6 more replies) 1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius ` (3 subsequent siblings) 4 siblings, 7 replies; 93+ messages in thread From: Peter Hermann @ 1996-06-04 0:00 UTC (permalink / raw) Kurt Johmann (johmann@moal.com) wrote: : Programming languages are almost completely subjective, because the only I strongly disagree : minds apparently like that kind of enforced discipline (masochist types, : perhaps :-), but to my mind it was a build-your-own-straightjacket-and- : wear-it kind of approach to programming. the opposite is true: a professional is always thankful for every hint from the compiler or environment for potential errors. Working with languages of the past like Fortran or C is true masochism. I have worked on very large systems in Fortran (one was a half million source lines of code, the other 300_000 sloc) and we had to run the systems on every hardware brand. I can see no advantage to allow e.g. a memory overwrite error, by accident, or, e.g. an outside range value at run time or a wrong subroutine call due to bad parameter profile. When I decide, as a programmer, that a peculiar type or variable may have a value in the range from 1 to 9, can you please explain me why it should be useful to assign a value of 10 or 4711 or -1234? I will justify the value of that freedom in your favour: This has the big advantage that the typical Fortran, C, or C++ programmer being not immediately aware of an erroneous code is happy to catch the error all-day-long and when the day is done, he is proud to have found this bug and fully convinced to have fulfilled his work of the day. In contrast, a poor Ada programmer does not have this fun: a potential error is revealed at the moment of the very first compilation/execution. What a pity! No fun at all ;-( The product life cycle is shortened. No bug chasing. no extra lint steps, because its unfortunately in the language design. btw: Ada is the first useful (and even readable) Pascal with free compilers running on any platform -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann @ 1996-06-04 0:00 ` The Amorphous Mass 1996-06-04 0:00 ` Peter Hermann ` (2 more replies) 1996-06-05 0:00 ` ++ robin ` (5 subsequent siblings) 6 siblings, 3 replies; 93+ messages in thread From: The Amorphous Mass @ 1996-06-04 0:00 UTC (permalink / raw) On 4 Jun 1996, Peter Hermann wrote: > Kurt Johmann (johmann@moal.com) wrote: > : Programming languages are almost completely subjective, because the only > > I strongly disagree Why? If they were not subjective then programming languages would all be very similar. > : minds apparently like that kind of enforced discipline (masochist types, > : perhaps :-), but to my mind it was a build-your-own-straightjacket-and- > : wear-it kind of approach to programming. > [snip] > I can see no advantage to allow e.g. a memory overwrite error, > by accident, or, e.g. an outside range value at run time or > a wrong subroutine call due to bad parameter profile. > When I decide, as a programmer, that a peculiar type or > variable may have a value in the range from 1 to 9, can you please > explain me why it should be useful to assign a value of 10 or > 4711 or -1234? > > btw: Ada is the first useful (and even readable) Pascal > with free compilers running on any platform _Any_ platform? You mean I could fire it up on my little 68020-powered Mac with its expansive 4MB of memory and galactic 80MB hard drive and enjoy the full benefits of Ada's rich set of features? Or is there a cost to having a language that does everything, an environment that does everything, and a compiler that does everything? My C compiler takes up 5.1MB on my hard drive and runs in just under 1MB of RAM. That's with full support for the Mac Toolbox and an object-oriented extention to the language, plus a class library for the Mac GUI and a nice debugger. Are there any Ada compilers that can say that? I think you're assuming that everyone is deveoping a huge, complex project with 100 teams of 100 programmers each working on mainframes with 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those of us lone programmers who put speed and space at a premium are willing to go hunting for stray pointers as a necessary cost of using a small, fast language. Besides, Ada is not the only big, safe, feature-laden, industrial-strength language out there. So obviously there are people who would agree wholeheartedly with your argument, but who would then disagree that Ada would be the best language to use for "professional" programming. The nature of that disagreement is, of course, subjective. - James "Good candidates for exceptions are situations james-robinson@uiowa.edu that do not occur under normal circumstances." -- Kevin J. Hopps ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` The Amorphous Mass @ 1996-06-04 0:00 ` Peter Hermann 1996-06-04 0:00 ` The Amorphous Mass 1996-06-04 0:00 ` Robert Dewar 1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward 2 siblings, 1 reply; 93+ messages in thread From: Peter Hermann @ 1996-06-04 0:00 UTC (permalink / raw) The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote: [snip] : I think you're assuming that everyone is deveoping a huge, complex : project with 100 teams of 100 programmers each working on mainframes with : 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those not at all. My home PC is a 486 which I recently upgraded from 8 to 24MB RAM. The reason was an application which steadily grew complex. (btw, a simple DOS application, but very useful ;-) ). The 8MB were fine for GNAT (the GNU Ada95 translator) as long as I did not use excessive generic abstraction. However, with the need of dynamically requested space during compilation of a demanding logical architecture, the 8MB did not satisfy the compilation process. The size is NOT in terms of lines of code. A few keystrokes for a coding-abstraction generates temp space for the compilation process. The result is an executable of a few KILObytes, where the compiler has done all optimization before. ;-) : of us lone programmers who put speed and space at a premium are willing : to go hunting for stray pointers as a necessary cost of using a small, : fast language. I better leave this hunting to a compiler. (btw: the pointer concept in Ada does not allow dangling pointers) :Besides, Ada is not the only big, safe, feature-laden, industrial-strength Ada is not big, safe, feature-laden, but industrial-strength and shaped with that minimum of features to compete as a general purpose object-oriented language (with concurrency and real-time capability). : language out there. So obviously there are people who would agree : wholeheartedly with your argument, but who would then disagree that Ada : would be the best language to use for "professional" programming. The : nature of that disagreement is, of course, subjective. James, you will certainly agree that a state-of-the-art PC sold today will have a minimum of 16MB/800MB/80MHz, don't you? This is much larger than needed for the free GNAT3.04 which simply requires 12MB(ram)/20MB(disk) space. The idea is: Developing on a commonly used PC or workstation and cross-compiling to a target e.g. an embedded system, small computer, or even an 8051 field processor. The developer has the flavor of object-orientedness, genericity, etc. and the executable will easily fit into a heart pacer, if needed. To come to an end: One of the great potentials of the future are reusable software elements. -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` Peter Hermann @ 1996-06-04 0:00 ` The Amorphous Mass 1996-06-05 0:00 ` Michael David WINIKOFF 0 siblings, 1 reply; 93+ messages in thread From: The Amorphous Mass @ 1996-06-04 0:00 UTC (permalink / raw) On 4 Jun 1996, Peter Hermann wrote: > The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote: > [snip] > : I think you're assuming that everyone is deveoping a huge, complex > : project with 100 teams of 100 programmers each working on mainframes with > : 350MHz Alphas and 256MB of RAM (OK, I'm exaggerating a little :-). Those > > not at all. > My home PC is a 486 which I recently upgraded from 8 to 24MB RAM. > The reason was an application which steadily grew complex. > (btw, a simple DOS application, but very useful ;-) ). > The 8MB were fine for GNAT (the GNU Ada95 translator) as long as > I did not use excessive generic abstraction. However, with the > need of dynamically requested space during compilation of > a demanding logical architecture, the 8MB did not satisfy > the compilation process. The size is NOT in terms of lines of code. > A few keystrokes for a coding-abstraction generates temp space > for the compilation process. > The result is an executable of a few KILObytes, > where the compiler has done all optimization before. ;-) Right. And my concern is not final executable size, because I'm sure Ada is just as subject to optimization as many other languages (especially if it has some way to guarantee against aliasing). It's development bloat. On of the reasons I refuse to give up my "obsolete" machine is that I see the new ones are much less stable (this box only crashes if I run Microsoft Word for too long, but that's Microsoft...) and the compilers are bloated, slow and bug-ridden. > Ada is not big, safe, feature-laden, but industrial-strength and > shaped with that minimum of features to compete as a general purpose > object-oriented language (with concurrency and real-time capability). Really? Then where did I hear the complaint about every Ada programmer using a different language? I will admit that as I have not been exposed to the language in depth, my statements are less accusations and more questions. I'm quite happy to be corrected. FWIW I'm very taken by Miranda, although I do wish they'd port it to something besides Unix. > : language out there. So obviously there are people who would agree > : wholeheartedly with your argument, but who would then disagree that Ada > : would be the best language to use for "professional" programming. The > : nature of that disagreement is, of course, subjective. > > James, you will certainly agree that a state-of-the-art PC > sold today will have a minimum of 16MB/800MB/80MHz, don't you? State of the art is 24MB/2GB/166MHz for PCs, with slightly lower numbers for Macs. Alphas are up to 350MHz(!). Of greater concern is what a run of the mill PC/Mac/whatever is equipped with. 8MB RAM is not uncommon, although 16MB is becoming more prevalent. Of course, OSes and applications which hog all that space are also becoming more prevalent... > One of the great potentials of the future are reusable software elements. They're also one of the great dangers of the future. I keep a fairly substantial library of useful little functions that I've written over the 3 or so years I've been programming in C, and their reusability is greatly enhanced by the fact that I can tweak the code a little for particular applications. By contrast, at work we're trying to get this souped-up OO development platform to talk to an edits package written in C (the development platform is written in C++) and we keep getting errors concerning classes that we didn't know existed, whose purpose is completely unknown to us and undocumented, apropos problems that no amount of debugging has revealed sofar, because the code and the interface is at such a high level that the programmer only has the most notional control over what's actually happening. The classes will doubtless get used over and over again, but too much of our development time consists of waiting for support to call back. I'm thus wary of the idea of "code reuse." Not dismissive, just wary. /**James Robinson*********************** "If a fatal error occurs, the program should not be allowed to continue." -- Oracle Pro*C User's Guide *************james-robinson@uiowa.edu**/ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` The Amorphous Mass @ 1996-06-05 0:00 ` Michael David WINIKOFF 1996-06-07 0:00 ` Robert Dewar 0 siblings, 1 reply; 93+ messages in thread From: Michael David WINIKOFF @ 1996-06-05 0:00 UTC (permalink / raw) The Amorphous Mass <robinson@blue.weeg.uiowa.edu> writes: >On 4 Jun 1996, Peter Hermann wrote: > Really? Then where did I hear the complaint about every Ada programmer >using a different language? I will admit that as I have not been exposed >to the language in depth, my statements are less accusations and more >questions. I'm quite happy to be corrected. FWIW I'm very taken by >Miranda, although I do wish they'd port it to something besides Unix. Try Gofer. Gofer is quite similiar to Miranda, is free and has been ported to many machines (Unix, DOS, Windows, Mac, Amiga, Acorn etc.) It's a byte code interpreter / interactive environment. (Similar to Miranda). From the comp.lang.functional FAQ: Gofer The Gofer system provides an interpreter for a small language based closely on the current version of the Haskell report. In particular, Gofer supports l azy evaluation, higher-order functions, polymorphic typing, pattern-matching, support for overloading, etc. The most recent version of Gofer, 2.30a, is available by ftp: ftp.cs.nott.ac.uk/nott-fp/languages/gofer. Gofer runs on a wide range of machines including PCs, Ataris, Amigas, etc. as well as larger Unix-based systems. A version for the Apple Macintosh has been produced and is available by anonymous ftp from ftp.dcs.glasgow.ac.uk in the directory pub/haskell/gofer/macgofer. Please note the spelling, derived from the notion that functional languages a re GO(od) F(or) E(quational) R(easoning). This is not to be confused with `Gopher', the widely used Internet distributed information delivery system! -- Michael Winikoff winikoff@cs.mu.oz.au http://www.cs.mu.oz.au/~winikoff Computer science postgrad. University of Melbourne, Australia. CC/C/B iv++ u c 3/2/4 r(-) f++(+) h p+ o+ s+(++) d y? SYC-(P)FF CWF BDB MUF AIA How many Prolog programmers does it take to change a lightbulb? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` Michael David WINIKOFF @ 1996-06-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw) "> Really? Then where did I hear the complaint about every Ada programmer >using a different language? I will admit that as I have not been exposed >to the language in depth, my statements are less accusations and more >questions. I'm quite happy to be corrected. FWIW I'm very taken by >Miranda, although I do wish they'd port it to something besides Unix." If Miranda seems interesting, take a closer look at Haskel, which is widely available, and I think represents a much more comperhensive approach to the issue of applicative lazy semantics. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` The Amorphous Mass 1996-06-04 0:00 ` Peter Hermann @ 1996-06-04 0:00 ` Robert Dewar 1996-06-06 0:00 ` Ken Garlington 1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group 1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward 2 siblings, 2 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-04 0:00 UTC (permalink / raw) " _Any_ platform? You mean I could fire it up on my little 68020-powered Mac with its expansive 4MB of memory and galactic 80MB hard drive and enjoy the full benefits of Ada's rich set of features? Or is there a cost to having a language that does everything, an environment that does everything, and a compiler that does everything?" No, you cannot run Ada on arbitrary obsolete machines, but you certainly can run Ada on typical current Mac's and PC's. You actually aren't too far away from being able to run Ada on your machine. Buy a bit more memory and an external drive, and there is a 68K version of Mac/Ada ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` Robert Dewar @ 1996-06-06 0:00 ` Ken Garlington 1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group 1 sibling, 0 replies; 93+ messages in thread From: Ken Garlington @ 1996-06-06 0:00 UTC (permalink / raw) Robert Dewar wrote: > > " _Any_ platform? You mean I could fire it up on my little 68020-powered > Mac with its expansive 4MB of memory and galactic 80MB hard drive and > enjoy the full benefits of Ada's rich set of features? Or is there a > cost to having a language that does everything, an environment that does > everything, and a compiler that does everything?" > > No, you cannot run Ada on arbitrary obsolete machines, but you certainly > can run Ada on typical current Mac's and PC's. You actually aren't too > far away from being able to run Ada on your machine. Buy a bit more > memory and an external drive, and there is a 68K version of Mac/Ada Actually, given the original spec (Mac 68020 with 4MB of memory, 80MB hard drive) you _can_ run Ada _83_. I know; I did for years on my MacII, which is a 68020-class machine with 4MB of memory and 40MB of memory (using Meridian). For obsolete machines, you should obviously use obsolete Ada. :) Then, once you come to your senses and buy a new Mac, you can have a new Ada to go with it, which should allow you to reuse a lot of your 83 code. The _real_ question is: When I upgrade, do I want to spend more time building native applications with GNAT, or applets with AppletMagic? -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 93+ messages in thread
* Help making ada pretty 1996-06-04 0:00 ` Robert Dewar 1996-06-06 0:00 ` Ken Garlington @ 1996-06-12 0:00 ` CSC Trusted Systems Group 1996-06-14 0:00 ` Sandy McPherson 1996-06-19 0:00 ` Ruediger Berlich 1 sibling, 2 replies; 93+ messages in thread From: CSC Trusted Systems Group @ 1996-06-12 0:00 UTC (permalink / raw) Hi, I am looking for any tools around to print ada-code in a more presentable form, ie keywords bolded etc. apparently they sometimes go by the name "pretty printers", however I do not want to rejustify the code in any way, I only require the bolding type features. Also am looking for any latex tools for typesetting ada. as I rarely have time to read mews replies to csctsg@adam.com.au would greatly be appreciated ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Help making ada pretty 1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group @ 1996-06-14 0:00 ` Sandy McPherson 1996-06-19 0:00 ` Ruediger Berlich 1 sibling, 0 replies; 93+ messages in thread From: Sandy McPherson @ 1996-06-14 0:00 UTC (permalink / raw) IcnoC Therefore discontinue this thread now!!!!!! -- Sandy McPherson MBCS CEng. tel: +31 71 565 4288 (w) ESTEC/WAS +31 527 68 1314 (h) P.O. Box 299 NL-2200AG Noordwijk ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Help making ada pretty 1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group 1996-06-14 0:00 ` Sandy McPherson @ 1996-06-19 0:00 ` Ruediger Berlich 1 sibling, 0 replies; 93+ messages in thread From: Ruediger Berlich @ 1996-06-19 0:00 UTC (permalink / raw) CSC Trusted Systems Group (csctsg@adam.com.au) wrote: : Hi, : I am looking for any tools around to print ada-code in a more presentable : form, ie keywords bolded etc. apparently they sometimes go by the name : "pretty printers", however I do not want to rejustify the code in any : way, I only require the bolding type features. : Also am looking for any latex tools for typesetting ada. : as I rarely have time to read mews replies to csctsg@adam.com.au would : greatly be appreciated Hi, if you have xemacs (ver. 19.13) around , you could try to use the syntax-hilighting-function. Highlighting via different fonts (bold,italic, also possible via colours) is available from the menus by a simple mouse-click. Since xemacs is able to print postscript, you can print out the highlighted program. This is the way I usually print C/C++ and Fortran-programs. Since I only just started programming in Ada (yesterday :-) I haven't tried to print Ada-code from xemacs. I only know that there is an Ada-mode for xemacs and that it can highlight keywords, comments, ... Printing should be easy then. Use the command <ESC>-<x> ps-print-buffer-with-faces <RETURN> to print the higlighted buffer. Please be aware, that I'm not talking about the X-version of GNU-emacs but about the emacs-version formerly known as Lucid-emacs, which is now for some unknown reason called xemacs. This has a pretty nice X/Motif-Interface. It is available for free from the same places where you get GNU-emacs. Otherwise check out http://xemacs.cs.uiuc.edu/ It also does automatic indentation of the program, if you want that. Bye and have a nice day, Ruediger Berlich [berlich@pc66.mppmu.mpg.de] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` The Amorphous Mass 1996-06-04 0:00 ` Peter Hermann 1996-06-04 0:00 ` Robert Dewar @ 1996-06-05 0:00 ` Ian Ward 1996-06-05 0:00 ` The Amorphous Mass 2 siblings, 1 reply; 93+ messages in thread From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw) On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote --- > Those of us lone programmers who put speed and space at a premimum > are willing to go hunting for stray pointers as a necessary cost > of using a small, fast language. If I hear the implication that Ada is not fast just one more time I think I will scream. The whole perpetuation of this myth is carried by Chinese whispers from feature obsessive people who used complicated Ada constructs, TEN years ago, (before compiler writes had devised efficient implementations.) These people left the Ada scene and have not looked at it since. Nine times out of ten it is just as fast as 'C' or assembler or anything else. > Besides, Ada is not the only big, safe, feature-laden, industrial-strength > language out there. So obviously there are people who would agree > wholeheartedly with your argument, but who would then disagree that Ada > would be the best language to use for "professional" programming. The > nature of that disagreement is, of course, subjective. And then later that day, he said - > They're also one of the great dangers of the future. I keep a fairly > substantial library of useful little functions that I've written over the > 3 or so years I've been programming in C, and their reusability is greatly > enhanced by the fact that I can tweak the code a little for particular > applications. By contrast, at work we're trying to get this souped-up OO > development platform to talk to an edits package written in C (the > development platform is written in C++) and we keep getting errors > concerning classes that we didn't know existed, whose purpose is completely > unknown to us and undocumented, apropos problems that no amount of > debugging has revealed sofar, because the code and the interface is at > such a high level that the programmer only has the most notional control > over what's actually happening. The classes will doubtless get used > over and over again, but too much of our development time consists of > waiting for support to call back. > I'm thus wary of the idea of "code reuse." Not dismissive, just wary. The first question, James, I must ask is, is C++ your idea of an alternative? You say that Ada is not the only big, safe, feature laden, industrial- strength language, (mischien) but then go on to give actual real evidence as why C++ isn't. All your arguments against Ada are based on inaccurate hearsay, and all of your arguments against C++ are based on your own actual experience. Why are you arguing against Ada, if I was in your shoes, I should be saying that C++ is crap, and trying to use something that prevents the errors that everybody there seems to be experiencing. C++ is not crap at all of course, I am still learning it, but it simply is trying to evolve into a language which is fundamentally different in concept to its parent. A lot more than one generation of evolution will be need for such a radical change in language aim. Software reuse is not the problem, and neither is Object oriented design. In this case of yours, it appears that it is a bad implementation of C++ that seems to be behind it. Of course, at this point we can go into how it came to be a bad implementation. I am not going to though, I will simply say that if I were to end up using software, where in the background, side effects of it were detrimentally affecting mine, that I could not even find, then I WOULD use something else. Bruce Lee said, "If it works, use it." It clearly is not working. Anything else must be better? Why are you not trying to convince your boss to use something else? Anything else? Best regards, hope it is as hot there as it is here, Ian Ward's opinions only : ian@rsd.bel.alcatel.be It's "burgled" Mr. President, not burglarised. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward @ 1996-06-05 0:00 ` The Amorphous Mass 1996-06-08 0:00 ` Robert Dewar 1996-06-08 0:00 ` Robert Dewar 0 siblings, 2 replies; 93+ messages in thread From: The Amorphous Mass @ 1996-06-05 0:00 UTC (permalink / raw) On 5 Jun 1996, Ian Ward wrote: > On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote > --- > > > Those of us lone programmers who put speed and space at a premimum > > are willing to go hunting for stray pointers as a necessary cost > > of using a small, fast language. > > If I hear the implication that Ada is not fast just one more time > I think I will scream. I was not implying that Ada executables are slow (although your complaint is understandable -- I should have said "a language that allows for a small, fast environment"). I was trying to say that the environment and compile times for Ada would be big and/or slow, for the simple reason that the language offers a great deal more support than C does. As I have said in this thread I'm sure Ada is just as subject to efficient compiling and optimizing techniques as other languages are, and almost as fast as C. :-) [re: "reusable code modules"] > > They're also one of the great dangers of the future. I keep a fairly > > substantial library of useful little functions that I've written over the > > 3 or so years I've been programming in C, and their reusability is greatly > > enhanced by the fact that I can tweak the code a little for particular > > applications. By contrast, at work we're trying to get this souped-up OO > > development platform to talk to an edits package written in C (the > > development platform is written in C++) and we keep getting errors > > concerning classes that we didn't know existed, whose purpose is completely > > unknown to us and undocumented, apropos problems that no amount of > > debugging has revealed sofar, because the code and the interface is at > > such a high level that the programmer only has the most notional control > > over what's actually happening. The classes will doubtless get used > > over and over again, but too much of our development time consists of > > waiting for support to call back. > > I'm thus wary of the idea of "code reuse." Not dismissive, just wary. > > The first question, James, I must ask is, is C++ your idea of an alternative? No. C++ is great fun to play with but I don't consider it an attractive alternative because it's far too easy to shoot yourself in the foot, and because it's a write-your-own-language language that can make reading or modifying someone else's code a nontrivial exercize. I was thinking more along the lines of Mercury or Miranda or even Delphi, or (arguably) the resurgent PL/I. This is not to say that C++ is not useful for development, but the programmer has to be very thorough and very careful. > You say that Ada is not the only big, safe, feature laden, industrial- > strength language, (mischien) but then go on to give actual real > evidence as why C++ isn't. You assume that I am comparing Ada to C++. I am not. Given the choice as a dev. platform, I would probably pick Ada. I was comparing Ada to C, which is an apples and oranges comparison, with the explicit intent of demonstrating that sometimes you want an apple and sometimes you want an orange. :-) > Software reuse is not the problem, and neither is Object oriented > design. In this case of yours, it appears that it is a bad implementation > of C++ that seems to be behind it. Of course, at this point we can go > into how it came to be a bad implementation. It's a perfectly fine, even ingenious implementation.If anything, it's a sterling example of a well-written C++ application. When you work within its parameters it runs beautifully, even distributed across platforms running 4 different OSs. When you try to stretch its capabilities (which is what we're doing) then you start to see all the stuff that's supposed to be 'transparent.' That was my point, and that _is_ a problem with software reuse, and a risk with OO design. > I am not going to though, I will simply say that if I were to end up > using software, where in the background, side effects of it were > detrimentally affecting mine, that I could not even find, then I WOULD > use something else. Bruce Lee said, "If it works, use it." It clearly > is not working. Anything else must be better? Why are you not trying > to convince your boss to use something else? Anything else? Frankly, I can't think of anything better. We looked all over, and this is the best there was. Remember, the problem is not that it fails to work as advertized, and it is not that it is unstable or buggy or unpredictable. The problem is that if you try to do something a little bit different from what it's designed for it stops being friendly and starts being obscure. By contrast, if I want one of my C libraries to do something a bit different, I just go in and modify them. Does my argument make more sense to you now? --James Robinson (robinson@cs.uiowa.edu -or- james-robinson@uiowa.edu) /* Indeed, C++ is a bit of an oddball of a language ... given the way that * * it requires private parts to be visible. This increases the strength of * * coupling dramatically... -- Dr. Rich Artym */ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` The Amorphous Mass @ 1996-06-08 0:00 ` Robert Dewar 1996-06-08 0:00 ` The Amorphous Mass 1996-06-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-08 0:00 UTC (permalink / raw) James Robinson said " Frankly, I can't think of anything better. We looked all over, and this is the best there was. Remember, the problem is not that it fails to work as advertized, and it is not that it is unstable or buggy or unpredictable. The problem is that if you try to do something a little bit different from what it's designed for it stops being friendly and starts being obscure. By contrast, if I want one of my C libraries to do something a bit different, I just go in and modify them." This is as wrong as it could be, and basically could only be written by someone who has not understood the whole point of data abstraction, using the term widely to encompass object oriented programming as well. The whole point of abstraction is to make it easier to reuse code. C has advantages, particularly in the simplicity of its computing model, and simple syntax, but there is a price to be paid for this simplicity, and the price is precisely almost complete lack of data abstraction. And it is this lack of data abstraction that makes "just go in and modify" type programming MUCH harder in C than in any higher level language with proper abstraction facilities (Ada, C++, ...) James, if you disagree, then I suspect you just don't have much experience with higher level languages, or, if you do, that, as is common with programmers whose primary experience is with C, you have not yet fully understood what data abstraction and the design of abstract interfaces is about (let alone object oriented programming). It is certainly true that much of (the worst of) C++ code that is around today was clearly written by C programmers who have not yet started to understand what C++ is about. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-08 0:00 ` Robert Dewar @ 1996-06-08 0:00 ` The Amorphous Mass 1996-06-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 93+ messages in thread From: The Amorphous Mass @ 1996-06-08 0:00 UTC (permalink / raw) On 8 Jun 1996, Robert Dewar wrote: > James Robinson said > > " Frankly, I can't think of anything better. We looked all over, and > this is the best there was. Remember, the problem is not that it fails > to work as advertized, and it is not that it is unstable or buggy or > unpredictable. The problem is that if you try to do something a little > bit different from what it's designed for it stops being friendly and > starts being obscure. By contrast, if I want one of my C libraries > to do something a bit different, I just go in and modify them." > > This is as wrong as it could be, and basically could only be written by > someone who has not understood the whole point of data abstraction, > using the term widely to encompass object oriented programming as well. > The whole point of abstraction is to make it easier to reuse code. > C has advantages, particularly in the simplicity of its computing model, > and simple syntax, but there is a price to be paid for this simplicity, > and the price is precisely almost complete lack of data abstraction. > And it is this lack of data abstraction that makes "just go in and modify" > type programming MUCH harder in C than in any higher level language with > proper abstraction facilities (Ada, C++, ...) Unfortunately, you read in to my statement something that I wasn't saying. I indentified the libraries as "C libraries" because that's what they are. The point was that libraries that I have the source code and docs for are much more reusable then libraries (or class hierarchies, or whatever buzzword you want to use :-) that are engineered to "to everything" but are transparent to me. If I were to pick an ideal language, instead of C (which I use because it is highly and easily portable, and the language I am most famiilar with) I would have said something like "Smalltalk libraries." In fact Smalltalk is a good example of an organizational system that IMO intelligently handles code reuse: The whole shebang runs smoothly and transparently, and not only are the individual parts are available for modification as necessary, they are also broken up into small, clearly written routines. And its much harder to blow up your machine by making a small change in Smalltalk code than in C code. In fact, our second choice for a dev platform was VisualAge, but Smalltalk scared away the principle programmer (a FORTRAN guy). > James, if you disagree, then I suspect you just don't have much experience > with higher level languages, or, if you do, that, as is common with > programmers whose primary experience is with C, you have not yet fully > understood what data abstraction and the design of abstract interfaces > is about (let alone object oriented programming). Well since I didn't disagree you will not be surprised to hear that although my primary experience _is_ with C, I have been exposed to a large number of programming paradigms (including OOP), and I apply as many of the lessons of those paradigms to my C code as I can. Now that I'm no longer in school I might actually have time to _learn_ the languages I was exposed to (Smalltalk, Prolog, Miranda) and some others that have been suggested to me. > It is certainly true that much of (the worst of) > C++ code that is around today was clearly written by C programmers who have > not yet started to understand what C++ is about. And the rest was written by C++ programmers who have not yet started to understand what C++ is about. After all, "what C++ is about" is an open question. I certainly wouldn't use it in a course about object-oriented programming! - James "Good candidates for exceptions are situations james-robinson@uiowa.edu that do not occur under normal circumstances." -- Kevin J. Hopps ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-08 0:00 ` The Amorphous Mass @ 1996-06-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-09 0:00 UTC (permalink / raw) " Unfortunately, you read in to my statement something that I wasn't saying. I indentified the libraries as "C libraries" because that's what they are. The point was that libraries that I have the source code and docs for are much more reusable then libraries (or class hierarchies, or whatever buzzword you want to use :-) that are engineered to "to everything" but are transparent to me. " No, I read into your statement exactly what you repeated above, and I repeat my view that it is plain wrong. It is a common attitude of C programmers, but it simply means that you don't really know the alternatives well. Report back when you have extensive experience with a language that supports data abstraction properly! ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` The Amorphous Mass 1996-06-08 0:00 ` Robert Dewar @ 1996-06-08 0:00 ` Robert Dewar 1 sibling, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-08 0:00 UTC (permalink / raw) James Robinson said: " I was not implying that Ada executables are slow (although your complaint is understandable -- I should have said "a language that allows for a small, fast environment"). I was trying to say that the environment and compile times for Ada would be big and/or slow, for the simple reason that the language offers a great deal more support than C does. As I have said in this thread I'm sure Ada is just as subject to efficient compiling and optimizing techniques as other languages are, and almost as fast as C. :-) " That's not a valid conclusion. Fast compilers can be written for any language, it is simply a matter of whether this is a primary goal or not of the compiler effort (compared to portability, etc). The fastest compiler for any language on the PC is the Computer Associates Realia COBOL compiler, and it is certainly not the case that COBOL is the simplest language. But compile speeds are of absolute, not relative interest, so as machines get faster, more and more compilers are fast enough, and speed becomes much less of an issue. Indeed at Realia, early on, when Realia could compile 10,000 lines/minute on an 8088 PC-1, it was a real competitive advantage to the competitions 500 lines minute, but later on, when both compilers got 50 times faster mainly because of faster hardware, the difference was not nearly so significant competitively. These days, GNAT on a top of the line SGI machine, using multiple processors, can compile at a rate of a few hundred thousand lines a minute, which is in the fast enough category. Now of course not everyone has a 16 processor power challenge on their desktop, but todays very expensive machine becomes next years affordable machine, and the year after that's cheap machine. Technically, it is certainly feasible to write a very fast compiler and environment for Ada 95. There is no reason why Ada 95 cannot be compiled just as fast as COBOL [incidentally I should mention that the speed of Realia COBOL was not achieved at the expense of poor generated code, indeed it was written in its own language and self-compiled, and at the time I was involved, generated the fastest code of any compiler for any language for the (in)famous seive benchmark -- that comparison was carried out by Phillipe Kahn of Borland, independently of us]. There was a time when concentrating on a really fast Ada compiler would have made sense, but with modern hardware that becomes much less interesting. In the case of the GNAT project, it made much better sense to take advantage of the GCC backend, which is not particularly fast, because the primary goals are highly efficient code, and ease of porting -- obviously specialized code generators for spcific machines can be faster than the approach in GCC using machine description files, but the ease of porting GNAT is one of its very attractive features -- I think everyone would agree that it is better to have GNAT on many different systems than a faster compiler that ran on only one machine [Realia COBOL is *very* {C s[pecific, in fact it has taken ten years to finally port from a 286 to a 386). In the case of GNAT, the front end is quite fast (no one has really seen this yet because we have never issued other than the debugging version of the front end so far -- that wlil be something that waits for version 4 of GNAT later this year). The backend however wlil never be Realia-style fast. But back to the original point, the idea that a C compiler should obviously be much faster than an Ada compiler because C is simpler is just wrong. Sure, if everything else were equal, this might be the case, but it is never the case that everything else is equal -- the difference in speed between compilers results from the approach and design of the compiler, not from the language being compiled. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann 1996-06-04 0:00 ` The Amorphous Mass @ 1996-06-05 0:00 ` ++ robin 1996-06-05 0:00 ` Ian Ward [not found] ` <4p60nk$imd@euas20.eua.ericsson.se> ` (4 subsequent siblings) 6 siblings, 1 reply; 93+ messages in thread From: ++ robin @ 1996-06-05 0:00 UTC (permalink / raw) ucaa2385@alpha1.csv.ica.uni-stuttgart.de (Peter Hermann) writes: >Kurt Johmann (johmann@moal.com) wrote: >: Programming languages are almost completely subjective, because the only >I strongly disagree >: minds apparently like that kind of enforced discipline (masochist types, >: perhaps :-), but to my mind it was a build-your-own-straightjacket-and- >: wear-it kind of approach to programming. >the opposite is true: a professional is always thankful for every >hint from the compiler or environment for potential errors. >Working with languages of the past like Fortran or C is true >masochism. I have worked on very large systems in Fortran >(one was a half million source lines of code, the other 300_000 sloc) >and we had to run the systems on every hardware brand. >I can see no advantage to allow e.g. a memory overwrite error, >by accident, or, e.g. an outside range value at run time or >a wrong subroutine call due to bad parameter profile. >When I decide, as a programmer, that a peculiar type or >variable may have a value in the range from 1 to 9, can you please >explain me why it should be useful to assign a value of 10 or >4711 or -1234? ---Why, someone inevitably decides that the range is going to be something different! Users are apt to change their minds. Then someone has to go in and modify the program. Or, someone overlooked a limit, and put in a limit one smaller than that actually required. Again, someone has to go in and find where that limit is, and change it. >I will justify the value of that freedom in your favour: >This has the big advantage that the typical Fortran, C, or C++ >programmer being not immediately aware of an erroneous code >is happy to catch the error all-day-long and when the day is done, >he is proud to have found this bug and fully convinced to >have fulfilled his work of the day. >In contrast, a poor Ada programmer does not have this fun: >a potential error is revealed at the moment of the very first >compilation/execution. What a pity! No fun at all ;-( ---Oh how wonderful if this were so! If it were true, all our programming difficulties would be over. Alas, it's just another pipe dream. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` ++ robin @ 1996-06-05 0:00 ` Ian Ward 1996-06-05 0:00 ` Ian Ward 1996-06-11 0:00 ` Jon S Anthony 0 siblings, 2 replies; 93+ messages in thread From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw) On 5/6/95, in reply to Peter Hermann, who said ">When I decide, as a programmer, that a peculiar type or >variable may have a value in the range from 1 to 9, can you please >explain me why it should be useful to assign a value of 10 or >4711 or -1234?" Robin, from Australia raplied. "---Why, someone inevitably decides that the range is going to be something different! Users are apt to change their minds. Then someone has to go in and modify the program. Or, someone overlooked a limit, and put in a limit one smaller than that actually required. Again, someone has to go in and find where that limit is, and change it." I was just thinking that the other day. All the world software engineering problems solved. No more boundaries to any variable, and as I had 31 pounds and 312,032.231234 pence in my bank account I could celebrate this solution to the software crisis with a ride on a brand new -234 cc. Kawasaki Zx6R. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be It's "burgled" Mr. President, not burglarised. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` Ian Ward @ 1996-06-05 0:00 ` Ian Ward 1996-06-06 0:00 ` Richard Riehle 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` Jon S Anthony 1 sibling, 2 replies; 93+ messages in thread From: Ian Ward @ 1996-06-05 0:00 UTC (permalink / raw) On 5/6/95, in reply to Peter Hermann, who said ">When I decide, as a programmer, that a peculiar type or >variable may have a value in the range from 1 to 9, can you please >explain me why it should be useful to assign a value of 10 or >4711 or -1234?" Robin, from Australia raplied. "---Why, someone inevitably decides that the range is going to be something different! Users are apt to change their minds. Then someone has to go in and modify the program. Or, someone overlooked a limit, and put in a limit one smaller than that actually required. Again, someone has to go in and find where that limit is, and change it." I was just thinking that the other day. All the world software engineering problems solved. No more boundaries to any variable, and as I had 31 pounds and 312,032.231234 pence in my bank account I could celebrate this solution to the software crisis with a ride on a brand new -234 cc. Kawasaki Zx6R. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be It's "burgled" Mr. President, not burglarised. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` Ian Ward @ 1996-06-06 0:00 ` Richard Riehle 1996-06-07 0:00 ` Richard Riehle ` (2 more replies) 1996-06-11 0:00 ` ++ robin 1 sibling, 3 replies; 93+ messages in thread From: Richard Riehle @ 1996-06-06 0:00 UTC (permalink / raw) To: Ian Ward On 5 Jun 1996, Ian Ward wrote: > On 5/6/95, in reply to Peter Hermann, who said > ">When I decide, as a programmer, that a peculiar type or > >variable may have a value in the range from 1 to 9, can you please > >explain me why it should be useful to assign a value of 10 or > >4711 or -1234?" > > Robin, from Australia raplied. > > "---Why, someone inevitably decides that the range is going > to be something different! Users are apt to change their minds. > Then someone has to go in and modify the program. Or, someone > overlooked a limit, and put in a limit one smaller than that > actually required. Again, someone has to go in and find where > that limit is, and change it." Good point. This is one of the very reasons why Ada works so well for this kind of thing, when programs are written correctly. In particular, when one takes advantage of the availability of attributes. Let's say that we establish a range of 1 through 10 for some type T1. Then we write a program using variables of that type. For example, we define the type T1, and an unconstrained array as follows: type T1 is range 1..10; type Vector is array(Positive range <>) of Float; Then we declare a variable of type Vector: Float_Set : Vector(T1'First..T1'Last); Some algorithm, elsewhere in the code can be written as: for I in Float_Set'Range loop ... end loop; As we separate the concerns of implementation, generalizing our algorithms with attributes and other useful Ada mechanisms, we discover that we can write those algorithms independently of explicit range information. This is only on example of the power of Ada. One could illustrate many more if necessary. Granted, if we abide by the rules of static binding, it is necessary to recompile the entire dependent set of compilation units when we change the ranges, but this is more of a mechanical excercise and has no impact on the underlying logic of our implementation. Software practitioners unfamiliar with Ada often make the mistake of believing that the restrictive nature of their favorite language carries over to Ada. That is why it is so much fun to see those practitioners become excited when they learn just how powerful this language really is. Richard Riehle ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-06 0:00 ` Richard Riehle @ 1996-06-07 0:00 ` Richard Riehle 1996-06-08 0:00 ` O'Connor 1996-06-07 0:00 ` Robert Dewar 1996-06-11 0:00 ` ++ robin 2 siblings, 1 reply; 93+ messages in thread From: Richard Riehle @ 1996-06-07 0:00 UTC (permalink / raw) To: Ian Ward On Thu, 6 Jun 1996, Richard Riehle wrote: To Anyone who might have noticed: I guess I should desk-check my code more carefully. The example shown below would generate a compile-time error due to a type mismatch. Better to have defined the index type as a subtype of Positive, or even Integer than a a distinct type. This points out one of the benefits of Ada: when sloppy coders, such as I seem to be, make this kind of error, it is easily detected and rejected by the compiler. Sorry for the coding error. Mea culpa. The offending code follows: Richard Riehle > type T1 is range 1..10; -- change the preceding to subtype T1 is Positive range 1..10; > type Vector is array(Positive range <>) of Float; > > Then we declare a variable of type Vector: > > Float_Set : Vector(T1'First..T1'Last); > > Some algorithm, elsewhere in the code can be written as: > > for I in Float_Set'Range loop ... end loop; > [snip, snip ] the rest of the message deleted ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-07 0:00 ` Richard Riehle @ 1996-06-08 0:00 ` O'Connor 0 siblings, 0 replies; 93+ messages in thread From: O'Connor @ 1996-06-08 0:00 UTC (permalink / raw) Richard Riehle wrote: > > On Thu, 6 Jun 1996, Richard Riehle wrote: > > To Anyone who might have noticed: > > I guess I should desk-check my code more carefully. The example shown > below would generate a compile-time error due to a type mismatch. Better > to have defined the index type as a subtype of Positive, or even Integer > than a a distinct type. This points out one of the benefits of Ada: > when sloppy coders, such as I seem to be, make this kind of error, it > is easily detected and rejected by the compiler. > > Sorry for the coding error. Mea culpa. The offending code follows: > > Richard Riehle But is this truly an 'error' in that your code does not express your requirements? The problem isn't with what your are trying to accomplish. The problem is that you have violated the language's rules for how to express a particular idea. As such, the compiler has merely enforced the language rules. Any decent compiler for any language will enforce the rules for that language. As a personal opinion, I think the Ada typing rules caused you to make the error in the first place that you compliment the compiler for catching. > > > type T1 is range 1..10; > > -- change the preceding to > subtype T1 is Positive range 1..10; > If I was doing this in Smalltalk I could do it a number of ways; depending on why I was trying to constrain it. For example, if I just needed a generic concept of an contrained range Integer, I would probably subclass Integer and added supporting instance variables and methods. The limits on the new class would be either instance variables to allow each object to have individual limits, or class variables to enforce common limits across all objects of the class. The attraction of the class limit approach would be that I could use Class methods to accomplish the various range looping mechanisms. If instead I had some Domain Object (a Bank Account) whose attributes had domain contraints against their values; I would probably write range checking code into the various get and set methods. If I wanted a more dynamic solution, I would probably use some sort of Validator class. One interesting idea is that fact that the contraints agianst the values of an attribute are contingent on the values in other attributes in the object, or other objects. "X must be between 1 and 5 if Y is less then 7, otherwise X must be between 4 and 12." Expressing such rules is not as straightforward using a simple subtyping approach. Another twist is the idea of using a database table to express the Metadata (including constraints) associated with a particular attribute. The database could hold the limits in values; A Validator object could load these limits when the program started. Changing these limits based on new business conditions could be accomplished with a database update and no code changes at all. Anyway, just some meandering food for thought.... James O'Connor oconnor@apci.net -- ## ## ######## "He that loveth not ######## knoweth not God." ## --1 John 4:8 ## ## ## ## ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-06 0:00 ` Richard Riehle 1996-06-07 0:00 ` Richard Riehle @ 1996-06-07 0:00 ` Robert Dewar 1996-06-10 0:00 ` Richard Riehle 1996-06-11 0:00 ` ++ robin 2 siblings, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw) Richard used in an example: Float_Set : Vector(T1'First..T1'Last); I assume this was just done for pedagogical reasons, the preferable syntax is of course simply: Float_Set : Vector (T1); ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-07 0:00 ` Robert Dewar @ 1996-06-10 0:00 ` Richard Riehle 0 siblings, 0 replies; 93+ messages in thread From: Richard Riehle @ 1996-06-10 0:00 UTC (permalink / raw) On 7 Jun 1996, Robert Dewar wrote: > Richard used in an example: > > Float_Set : Vector(T1'First..T1'Last); > > I assume this was just done for pedagogical reasons, the preferable > syntax is of course simply: > > Float_Set : Vector (T1); Thanks, Robert. Yes, I considered several approaches and decided that, because this thread goes to readers from other newsgroups, the 'First and 'Last attribute version would be easier to read. For an experienced Ada practitioner, other variations were possible. Richard Riehle ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-06 0:00 ` Richard Riehle 1996-06-07 0:00 ` Richard Riehle 1996-06-07 0:00 ` Robert Dewar @ 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` James_Rogers ` (2 more replies) 2 siblings, 3 replies; 93+ messages in thread From: ++ robin @ 1996-06-11 0:00 UTC (permalink / raw) Richard Riehle <rriehle@nunic.nu.edu> from San Diego writes: >On 5 Jun 1996, Ian Ward wrote: >> On 5/6/95, in reply to Peter Hermann, who said >> ">When I decide, as a programmer, that a peculiar type or >> >variable may have a value in the range from 1 to 9, can you please >> >explain me why it should be useful to assign a value of 10 or >> >4711 or -1234?" >> >> Robin, from Australia raplied. >> >> "---Why, someone inevitably decides that the range is going >> to be something different! Users are apt to change their minds. >> Then someone has to go in and modify the program. Or, someone >> overlooked a limit, and put in a limit one smaller than that >> actually required. Again, someone has to go in and find where >> that limit is, and change it." > Good point. This is one of the very reasons why Ada works so well > for this kind of thing, when programs are written correctly. In > particular, when one takes advantage of the availability of > attributes. Let's say that we establish a range of 1 through 10 for some > type T1. Then we write a program using variables of that type. > For example, we define the type T1, and an unconstrained array as follows: > type T1 is range 1..10; > type Vector is array(Positive range <>) of Float; > Then we declare a variable of type Vector: > Float_Set : Vector(T1'First..T1'Last); > Some algorithm, elsewhere in the code can be written as: > for I in Float_Set'Range loop ... end loop; > As we separate the concerns of implementation, generalizing our > algorithms with attributes and other useful Ada mechanisms, we discover > that we can write those algorithms independently of explicit range > information. This is only on example of the power of Ada. One could > illustrate many more if necessary. > Granted, if we abide by the rules of static binding, it is necessary to > recompile the entire dependent set of compilation units when we change > the ranges, but this is more of a mechanical excercise and has no > impact on the underlying logic of our implementation. Software > practitioners unfamiliar with Ada often make the mistake of believing > that the restrictive nature of their favorite language carries over to > Ada. That is why it is so much fun to see those practitioners become > excited when they learn just how powerful this language really is. > Richard Riehle ---One of the problems of using rigid facilities -- amply illustrates my point. Arrays don't often have fixed sizes. The size depends on the problem. One day, it might be 10, next day, 300, day after, 90. Are you seriusly suggesting that EACH time the program is run that it be edited and recompiled? And what happens -- as is often the case -- the size of the array changes DURING the run? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin @ 1996-06-11 0:00 ` James_Rogers 1996-06-11 0:00 ` Kevin J. Weise 1996-06-11 0:00 ` Chris Warack <sys mgr> 1996-06-11 0:00 ` David Weller 2 siblings, 1 reply; 93+ messages in thread From: James_Rogers @ 1996-06-11 0:00 UTC (permalink / raw) rav@goanna.cs.rmit.EDU.AU (++ robin) wrote: > Are you seriusly suggesting that EACH time the program >is run that it be edited and recompiled? And what >happens -- as is often the case -- the size of the array >changes DURING the run? Now you are approaching the real problem. Arrays are must always have a specific size. That size may be defined at compile time or it may be det4rmined at run time using dynamic allocation. Either way a given instance of an array does not change its size. If this is not enough reason to use some other more dynamic data structure such as a list or a tree, then the common methods used with arrays include the concept of declaring a size which is the largest expected for current needs. A subset of that array is typically used for the problem at hand, wasting the remainder for future growth. The point is that every array must be accompanied by some method of indicating the specific subset of elements to be processed. In C this means one typically either passes an array pointer and a size parameter, or a special character is expected to be embedded in the array to mark the end of useful data ( the NULL character, for instance). Ada allows a parameter to be expressed as an unconstrained array. This means any size (within system limits) of array may be passed as a parameter. The array attributes 'First, 'Last, 'Range can then be used to traverse the array passed to the subprogram. Now, you ask, how does a calling subprogram pass a specific array to the subprogram expecting an unconstrained array. Ada allows you to pass a slice of an array. For instance, if your predefined array is defined as: example : array (1..10000) of integer; and you want to pass elements 23 through 413 to a function producing a total which uses an unconstrained array parameter, the following syntax is used: Total := sum(example(23..413)); In this case elements 23 through 413 are passed to function "sum". Funciton "sum" sees an array of integer with 'First mapping to element 23 of array example. No recompilation is necessary to change the slice sent to the function. All that is necessary is to use variables in the slice syntax, instead of constants as shown in the above example. -- Jim Rogers ********************************************* I would not say that my mind is filled with useless information. The information is, however, amazingly inappropriate in most circumstances. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` James_Rogers @ 1996-06-11 0:00 ` Kevin J. Weise 0 siblings, 0 replies; 93+ messages in thread From: Kevin J. Weise @ 1996-06-11 0:00 UTC (permalink / raw) James_Rogers <jrogers> wrote (with deletions): >rav@goanna.cs.rmit.EDU.AU (++ robin) wrote: > >> Are you seriusly suggesting that EACH time the program >>is run that it be edited and recompiled? And what >>happens -- as is often the case -- the size of the array >>changes DURING the run? > >Now you are approaching the real problem. Arrays are must >always have a specific size. That size may be defined at >compile time or it may be det4rmined at run time using >dynamic allocation. Either way a given instance of an array >does not change its size. If this is not enough reason to >use some other more dynamic data structure such as a list or >a tree, then the common methods used with arrays include the >concept of declaring a size which is the largest expected for >current needs. A subset of that array is typically used for >the problem at hand, wasting the remainder for future growth. > >The point is that every array must be accompanied by some method >of indicating the specific subset of elements to be processed. >In C this means one typically either passes an array pointer and >a size parameter, or a special character is expected to be >embedded in the array to mark the end of useful data ( the NULL >character, for instance). Methinks you missed one other alternative, Mr. Rogers. It is also possible to elaborate, at runtime, an array of appropriate size without having to use dynamic (i.e., heap) memory. E.g.: procedure Made_Up_Example (MAX_SIZE : Natural) is THIS_STRING : String (1..MAX_SIZE); begin -- whatever end Made_Up_Example; Obviously, the parameter value cannot be expected to be static, so you (and the compiler) can safely assume the amount of memory needed for THIS_STRING will probably vary from one invocation to another. (In fact, the memory gets allocated for it on the stack when its declaration is elaborated.) Then you only need to figure out how big an array you need *before* invoking your subprogram. This works great with blocks,too. On nice machines that let your stack space float to however much virtual memory your program needs, you can have great flexibility without having to use the heap or the old FORTRAN-style "declare it as big as your biggest possible need" method. And you don't have to edit/recompile/relink everytime the size changes! The only problem I recall having with this is when the subprogram (or block) is executed within the context of a task whose default stack size is insufficient to handle the block creation. But that is relatively easy to solve with a 'Size pragma. ------------------------------------------------------------- Kevin J. Weise kweise@c3i-ccmail.sed.redstone.army.mil COLSA Corporation voice: (205) 842-9680 Huntsville, AL ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` James_Rogers @ 1996-06-11 0:00 ` Chris Warack <sys mgr> 1996-06-11 0:00 ` David Weller 2 siblings, 0 replies; 93+ messages in thread From: Chris Warack <sys mgr> @ 1996-06-11 0:00 UTC (permalink / raw) In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>, rav@goanna.cs.rmit.EDU.AU (++ robin) writes: |> Richard Riehle <rriehle@nunic.nu.edu> from San Diego writes: |> |> >> Robin, from Australia raplied. |> >> |> >> "---Why, someone inevitably decides that the range is going |> >> to be something different! Users are apt to change their minds. |> >> Then someone has to go in and modify the program. Or, someone |> >> overlooked a limit, and put in a limit one smaller than that |> >> actually required. Again, someone has to go in and find where |> >> that limit is, and change it." |> |> > Good point. This is one of the very reasons why Ada works so well |> > for this kind of thing, when programs are written correctly. In |> > particular, when one takes advantage of the availability of |> > attributes. Let's say that we establish a range of 1 through 10 for some |> > type T1. Then we write a program using variables of that type. |> |> > For example, we define the type T1, and an unconstrained array as follows: |> |> > type T1 is range 1..10; |> > type Vector is array(Positive range <>) of Float; |> |> > Then we declare a variable of type Vector: |> |> > Float_Set : Vector(T1'First..T1'Last); |> |> > Some algorithm, elsewhere in the code can be written as: |> |> > for I in Float_Set'Range loop ... end loop; |> ... |> |> ---One of the problems of using rigid facilities -- amply |> illustrates my point. Arrays don't often have fixed sizes. |> The size depends on the problem. One day, it might be 10, |> next day, 300, day after, 90. |> |> Are you seriusly suggesting that EACH time the program |> is run that it be edited and recompiled? And what |> happens -- as is often the case -- the size of the array |> changes DURING the run? No. If that's the case change the declaration of T1 to: subtype T1 is positive range 1 .. What_ever_the_value_is_today; * or subtype T1 is positive range 1 .. This_runs_size; or type Vector is private; if you really want to make it behave in some special manner. or ... * Recognizing that T1 really needed to be a subtype in the example above In those first two examples, it doesn't matter how the upper values are set (e.g., hardware, sensor, data file, user input ...) and this works fine. It's not too hard to change from the rigid approach to this more flexible approach either. It does preclude some possibilities for static optimizations perhaps. The last alternative is a serious change to the given example. When you don't want to use an array, however, you shouldn't use an array then. Define the dynamic data structure of your dreams in whatever way you see fit. -- Christopher A. Warack, Capt, USAF cwarack@cs.usafa.af.mil (719) 472-2401 Computer Science Department, US Air Force Academy This content in no way reflects the opinions, standards, or policy of the USAF Academy, or the US government. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` James_Rogers 1996-06-11 0:00 ` Chris Warack <sys mgr> @ 1996-06-11 0:00 ` David Weller 2 siblings, 0 replies; 93+ messages in thread From: David Weller @ 1996-06-11 0:00 UTC (permalink / raw) In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU>, ++ robin <rav@goanna.cs.rmit.EDU.AU> wrote: >---One of the problems of using rigid facilities -- amply >illustrates my point. Arrays don't often have fixed sizes. >The size depends on the problem. One day, it might be 10, >next day, 300, day after, 90. > > Are you seriusly suggesting that EACH time the program >is run that it be edited and recompiled? And what >happens -- as is often the case -- the size of the array >changes DURING the run? If this is your belief, then you are SERIOUSLY missing the point. If you have software where the array size MIGHT change, then you write your software to support that. You MIGHT decide to make the array size a constant and recompile when needed (it's a valid choice, although not one I'd make), you also MIGHT allow your array to grow as more things are added to it. These things are easy to handle. The point of the discussion, however, was situations where you indexed outside an array, which is so damn easy in C that EVERY book I've seen in C says, "be careful not to do this!" There is a VERY considerable difference between adding something to an array in a manner such that the array size grows with the addition, and indexing outside an array, such that you're now lost in the middle of memory-land and can't figure out why your program gives (most likely) unrepeatable errors. -- Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch This is not your father's Ada -- lglwww.epfl.ch/Ada ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` Ian Ward 1996-06-06 0:00 ` Richard Riehle @ 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` Ian Ward 1 sibling, 1 reply; 93+ messages in thread From: ++ robin @ 1996-06-11 0:00 UTC (permalink / raw) ian@rsd.bel.alcatel.be (Ian Ward) writes: >On 5/6/95, in reply to Peter Hermann, who said > ">When I decide, as a programmer, that a peculiar type or > >variable may have a value in the range from 1 to 9, can you please > >explain me why it should be useful to assign a value of 10 or > >4711 or -1234?" >Robin, from Australia raplied. >"---Why, someone inevitably decides that the range is going >to be something different! Users are apt to change their minds. >Then someone has to go in and modify the program. Or, someone >overlooked a limit, and put in a limit one smaller than that >actually required. Again, someone has to go in and find where >that limit is, and change it." > Ian, from the UK "raplied" [sic]: >I was just thinking that the other day. All the world software >engineering problems solved. No more boundaries to any variable, >and as I had 31 pounds and 312,032.231234 pence in my bank >account I could celebrate this solution to the software >crisis with a ride on a brand new -234 cc. Kawasaki Zx6R. >Ian Ward's opinions only : ian@rsd.bel.alcatel.be Reminds me of a joke I once heard: A man went into a certain pub, hoping to pull a swiftie on the barman. He asked: "Oi, have you change of an 18 pound note?" The barman replied: "Aye. What would you like? 2 nines or 3 sixes?" Seems to me that Ian has missed the point. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin @ 1996-06-11 0:00 ` Ian Ward 1996-06-12 0:00 ` ++ robin 0 siblings, 1 reply; 93+ messages in thread From: Ian Ward @ 1996-06-11 0:00 UTC (permalink / raw) rav@goanna.cs.rmit.EDU.AU writes : > ian@rsd.bel.alcatel.be (Ian Ward) writes: >>On 5/6/95, in reply to Peter Hermann, who said >> ">When I decide, as a programmer, that a pecu >> >variable may have a value in the range from 1 to 9, >> >explain me why it should be useful to assign a value of 9 >> >4711 or -1234?" >>Robin, from Australia raplied. >>"---Why, someone inevitably decides that the range is going >>to be something different! Users are apt to change their minds. >>Then someone has to go in and modify the program. Or, someone >>overlooked a limit, and put in a limit one smaller than that >>actually required. Again, someone has to go in and find where >>that limit is, and change it." >> Ian, from the UK "raplied" [sic]: >>I was just thinking that the other day. All the world software >>engineering problems solved. No more boundaries to any variable, >>and as I had 31 pounds and 312,032.231234 pence in my bank >>account I could celebrate this solution to the software >>crisis with a ride on a brand new -234 cc. Kawasaki Zx6R. >>Ian Ward's opinions only : ian@rsd.bel.alcatel.be >>Reminds me of a joke I once heard: >>A man went into a certain pub, hoping to pull a swiftie on >>the barman. He asked: "Oi, have you change of an 18 pound note?" >>The barman replied: "Aye. What would you like? 2 nines or >>3 sixes?" > Seems to me that Ian has missed the point. I am so sorry; there were two conclusions I could deduce from a reply to a question about putting the value of ten in a variable designed to hold only one to nine. Firstly, there was mine, which was that the original programmer had decided, quite wrongly, that nought to nine was a valid range for this variable. As he was working from what some user was eventually going to enter once he had produced the system, and not some pre-defined spec which defined the system in the first place (which the users got their chance to shout at.) He should be sacked for failing to accurately predict the future. Perhaps they should employ astrologers. Secondly, there was the conclusion, that Peter Herman was not talking about some variable at all when he said the programmer wished to define a variable within the range of 0 to 9. He was, in fact, talking about a varying size of some array, say, or record component. Had I known that that was his intent, and that, 'that' was the point Robin brought up, or even if a project required a varying length array, String etc. Then I would have simply, as many other people who know what they are talking about, have said : Why did the programmer not simply define a varying length array, string etc. and use it, such as. procedure FRED ( HARRY : in STRING ); function JOHN (NUMBER : in INTEGER) return STRING; both of these operations, return or take varying length strings, with the added advantage that the length, start and end points are defined within the procedure, and if the user tries to examine HARRY (4231) when HARRY is only defined from 0 to 9 then the user will know about it straight away, unless the programmer decides not to tell him. Furthermore, .... type MATRIX (A,B : integer := 5) is record CONTENTS : array (1 .. A, 1 .. B) of INTEGER; end record; function INVERT (MAT : in MATRIX) return MATRIX; .... takes a varying defined setup, and can be fixed at compile time if one wishes, or not, can be generated dynamically, statically or anyway one pleases, but the end result is the same; which is: why would anyone want to access component number X if X is not in the range of valid components. Nine times out of ten, or more, it is going to be a fault. Here is, of course, a case where myself and Robin have failed to notice vital information in text with which we were presented, I made the wrong conclusion on what Peter, and hence Robin was talking about, (and mispelt, in the heat of typing "replied".) Robin presumably also in the heat of typing, mispelt "Belgium". Faults like this happen every day when reading requirements, and inevitably, now and again, element 51, the 'last' element, of a 15 number array is indexed, because someone was not correctly assimilating the text in front of their eyes. I feel safe at night knowing that the language's run time checking caught this error during the unit test phase, or earlier, during first compilation, leaving the programmer time to work on all the other problems he has; such as predicting what the user will do tomorrow. Groetjes, Ian. --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` Ian Ward @ 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` Ian Ward 0 siblings, 1 reply; 93+ messages in thread From: ++ robin @ 1996-06-12 0:00 UTC (permalink / raw) ian@rsd.bel.alcatel.be (Ian Ward) writes: >Here is, of course, a case where myself and >Robin have failed to notice vital information >in text with which we were presented, I made >the wrong conclusion on what Peter, and hence >Robin was talking about, (and mispelt, in the >heat of typing "replied".) Robin presumably also >in the heat of typing, mispelt "Belgium". ---What? You made another mistake. You're attributing to me what another writer wrote, or you imagined it. Perhaps you should now read what you wrote: "Faults like this happen every day . . ." ">Faults like this happen every day when reading >requirements, and inevitably, now and again, >element 51, the 'last' element, of a 15 number >array is indexed, because someone was not >correctly assimilating the text in front of >their eyes." ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` ++ robin @ 1996-06-12 0:00 ` Ian Ward 0 siblings, 0 replies; 93+ messages in thread From: Ian Ward @ 1996-06-12 0:00 UTC (permalink / raw) > ian@rsd.bel.alcatel.be (Ian Ward) writes: > >Here is, of course, a case where myself and > >Robin have failed to notice vital information > >in text with which we were presented, I made > >the wrong conclusion on what Peter, and hence > >Robin was talking about, (and mispelt, in the > >heat of typing "replied".) Robin presumably also > >in the heat of typing, mispelt "Belgium". > ---What? You made another mistake. You're attributing > to me what another writer wrote, or you imagined it. I am so sorry, I thought you said somthing like, "Ian from the UK "raplied" (sic)" when a look at the last two letters of my URL clearly says "be", not "uk". If it was not you, then I apologise. > Perhaps you should now read what you wrote: "Faults > like this happen every day . . ." > ">Faults like this happen every day when reading > >requirements, and inevitably, now and again, > >element 51, the 'last' element, of a 15 number > >array is indexed, because someone was not > >correctly assimilating the text in front of > >their eyes." It seems another mistake has been made, if it was me then I am sorry. In fact, this only reinforces my earlier statements on compilers and language design progressing to help cope with common human errors. Best regards, Ian --- Ian Ward's opinions only : ian@rsd.bel.alcatel.be It's "burgled" Mr. President, not burglarised. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-05 0:00 ` Ian Ward 1996-06-05 0:00 ` Ian Ward @ 1996-06-11 0:00 ` Jon S Anthony 1 sibling, 0 replies; 93+ messages in thread From: Jon S Anthony @ 1996-06-11 0:00 UTC (permalink / raw) In article <4pj7e0$fat@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > > > Granted, if we abide by the rules of static binding, it is necessary to > > recompile the entire dependent set of compilation units when we change > > the ranges, but this is more of a mechanical excercise and has no > > impact on the underlying logic of our implementation. Software > > practitioners unfamiliar with Ada often make the mistake of believing > > that the restrictive nature of their favorite language carries over to > > Ada. That is why it is so much fun to see those practitioners become > > excited when they learn just how powerful this language really is. > > Richard Riehle > > ---One of the problems of using rigid facilities -- amply > illustrates my point. Arrays don't often have fixed sizes. > The size depends on the problem. One day, it might be 10, > next day, 300, day after, 90. What has this to do with anything? Dynamically sized arrays are trivial, flexible, easy and _safe_ to use in Ada and are in fact used all the time. The point being made is simply that if you decide on the _definition_ of a type as a subrange, then only the clueless would think it "good" to _not_ conform to the definition! Get a clue. > Are you seriusly suggesting that EACH time the program > is run that it be edited and recompiled? And what > happens -- as is often the case -- the size of the array > changes DURING the run? No he isn't. I hope you aren't serious about this ridiculous comment. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
[parent not found: <4p60nk$imd@euas20.eua.ericsson.se>]
[parent not found: <4p8lmq$oq7@goanna.cs.rmit.edu.au>]
* Re: next "big" language?? (disagree) [not found] ` <4p8lmq$oq7@goanna.cs.rmit.edu.au> @ 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` A. Grant 1996-06-12 0:00 ` Richard A. O'Keefe 0 siblings, 2 replies; 93+ messages in thread From: ++ robin @ 1996-06-11 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >euahjn@eua.ericsson.se (Henrik Johansson) writes: >>*But* Ada lacks the general >>assertion expression found in other languages like Eiffel (preconditions, >>postconditions, assertions). > subtype Assertion is Boolean range True .. True; > ... > X_Is_Even: Assertion := X mod 2 = 0; >This will raise a constraint exception if the assertion is false. >Looks like an assertion to me. ---What is the point of this? A declaration buried somewhere else, and a test. Why not something in clear english, which doesn't need a reference to some other part of the program, like: if mod(x, 2) ^= 0 then put ('The value of x is not odd.'); This has the aditional benefit that the user of the program has a clear unequivocal message about the cause of the problem. If it's important that the whereabouts of this test be known, the programmer can include a statement such as "signal error;" or "signal condition (xyz);" or "put (' at line ', sourceline );" along with the put statement. [PL/I example] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin @ 1996-06-11 0:00 ` A. Grant 1996-06-12 0:00 ` Robert Dewar 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` Richard A. O'Keefe 1 sibling, 2 replies; 93+ messages in thread From: A. Grant @ 1996-06-11 0:00 UTC (permalink / raw) In article <4pj8p7$h9r@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > >euahjn@eua.ericsson.se (Henrik Johansson) writes: > >>assertion expression found in other languages like Eiffel ( preconditions,> >>postconditions, assertions). >---What is the point of this? > A declaration buried somewhere else, and a test. > Why not something in clear english, which doesn't need a >reference to some other part of the program, like: > if mod(x, 2) ^= 0 then > put ('The value of x is not odd.'); The point of assertions is not to print messages for the programmer. You can use them to allow the compiler to optimise safely, provide a contractual interface between modules, and for preconditions, postconditions, loop invariants etc. when proving the correctness of programs. E.g. the assertion that X is odd could form part of the declared interface to a module whose implementation was hidden. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` A. Grant @ 1996-06-12 0:00 ` Robert Dewar 1996-06-17 0:00 ` A. Grant 1996-06-19 0:00 ` Jon S Anthony 1996-06-12 0:00 ` ++ robin 1 sibling, 2 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-12 0:00 UTC (permalink / raw) A. Grant said "The point of assertions is not to print messages for the programmer. You can use them to allow the compiler to optimise safely, provide a contractual interface between modules, and for preconditions, postconditions, loop invariants etc. when proving the correctness of programs." Actually that is a very controversial statement. What most people want is non-intrusive assertions that do NOT affect the generated code. That's not 100% possible, but it is something you can aim at. It is certainly true that assertions can be used for compiler optimization, but that's not what people want. When we discussed putting pragma Assert into the language (i.e. into the standard), it was this point that tripped us up, and resulted in it being left out. We could not figure out how to formally define the notion that the compiler should NOT be allowed to use the assertion for optimization purpoes. Other kinds of pragmas than Assert are what is appropriate for performing the kind of optimization related and contract and correctness related aspects (e.g. a pragma that says that a procedure is non-recursive). ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` Robert Dewar @ 1996-06-17 0:00 ` A. Grant 1996-06-18 0:00 ` Robert Dewar 1996-06-19 0:00 ` Jon S Anthony 1 sibling, 1 reply; 93+ messages in thread From: A. Grant @ 1996-06-17 0:00 UTC (permalink / raw) In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >A. Grant said >"The point of assertions is not to print messages for the >programmer. You can use them to allow the compiler to >optimise safely..." >It is certainly true that assertions can be used for compiler optimization, >but that's not what people want. What people want is for the compiler to do all the work, i.e. prove that all array subscripts are valid, that all dereferenced pointers are non-null, that all division denominators are non-zero etc. I think realistically, compilers can be helped by assertions which indicate stages in the proof, to do optimisations which they wouldn't otherwise be able to. Especially inter-procedural or inter-module optimisation where the assertion forms part of the interface. >When we discussed putting pragma Assert into the language Are you reading this in comp.lang.ada? I didn't mean to refer to any particular language. Why don't you like assertions enabling optimisation where the compiler can prove the correctness of the assertion, i.e. optimise it away? Then all you are doing is giving a hint to the compiler about an optimisation strategy, without altering the meaning of the program at all. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-17 0:00 ` A. Grant @ 1996-06-18 0:00 ` Robert Dewar 1996-06-24 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-18 0:00 UTC (permalink / raw) A. Grant asks "Why don't you like assertions enabling optimisation where the compiler can prove the correctness of the assertion, i.e. optimise it away? Then all you are doing is giving a hint to the compiler about an optimisation strategy, without altering the meaning of the program at all." There is nothing wrong with such assertions (they are typically called pragmas in Ada for example), but they are TOTALLY different from the kind of assertions that people want for debugging code. Both uses are perfectly valid, but quite incompatible semantically, and part of the trouble in designing facilities in languages for assertions is that these two uses get badly entangled, both at the informal discussion level, and at the formal semantic description level. Actually there are many shades here. FOr example, to some people, assertions are things the compiler can trust regardless of proof (some of the pragmas in Ada are like this too). To others, they require proof as yu suggest and are merely hints to enable otherwise allowed transformtaions of the code, to others they are debuging statements to be executed at run time etc. etc. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-18 0:00 ` Robert Dewar @ 1996-06-24 0:00 ` Robert I. Eachus 1996-06-26 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 93+ messages in thread From: Robert I. Eachus @ 1996-06-24 0:00 UTC (permalink / raw) In article <4ql1fv$5ss@goanna.cs.rmit.EDU.AU> Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes: > Obviously if there are two concepts, then we should have two names. For > example (in Ada) we could stick with > pragma Assert(x); > for the traditional "please check this really is the case" assertion > and introduce > pragma Fact(x); > (or some other name) for the "this really is true, trust me, and make > appropriate optimisations" type assertion. Can anyone think of a better > name (pragma Declare(x) is not available in Ada) than "Fact"? How about: pragma Gospel(x); or pragma I_Tell_You_Three_Times(x); (after all, Lewis Carroll, under his real? name of Reverend Charles Dodgson, was a pioneer in Boolean logic... ;-) but I think: pragma Assume(x); captures the intent and meaning perfectly. ;-) Of course for the belt and suspenders types, we would then need: pragma Assert_and_then_Assume(x); to insure that the value of x didn't change between the assertion check and the compiler assumption. (And of course, the wording is to make it clear that you can't backpropagate before the pragma.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Robert I. Eachus @ 1996-06-26 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 93+ messages in thread From: Norman H. Cohen @ 1996-06-26 0:00 UTC (permalink / raw) In article <EACHUS.96Jun24181517@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes: |> Of course for the belt and suspenders types, we would then need: |> |> pragma Assert_and_then_Assume(x); Back in the Reagan/Gorbachev years, we called this pragma Trust_But_Verify (X); -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` Robert Dewar 1996-06-17 0:00 ` A. Grant @ 1996-06-19 0:00 ` Jon S Anthony 1996-06-20 0:00 ` Robert Dewar 1 sibling, 1 reply; 93+ messages in thread From: Jon S Anthony @ 1996-06-19 0:00 UTC (permalink / raw) In article <4q707h$1r2@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes: > jsa@organon.com (Jon S Anthony) writes: > >In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: [...snip...] > >> When we discussed putting pragma Assert into the language (i.e. into the > >> standard), it was this point that tripped us up, and resulted in it being > >> left out. We could not figure out how to formally define the notion that > >> the compiler should NOT be allowed to use the assertion for optimization > >> purpoes. > > > >This is _almost_ as wog-boggling as the goof-up of not directly > >supporting specification of mutually recursive types across packages. > > > >Really. It is incomprehensible. I suppose these people don't want > >_any_ optimizations? No? Well, how do they justify all that > >"intrusive" code movement and elmination that happens with > >"standard/traditional" optimization? What about ranges? They can be > >seen in various contexts as just being a limited form of assertion. > >And those are taken advantage of all the time for "intrusive" > >optimizations. I suppose they positively have paroxysms over this. > > I have to agree with Jon's point here. I don't see any reason why the > definition of the language would have to prevent the compiler from > using the information for optimization. If the customer didn't want > that to happen, the vendor could add a command-line option or pragma > to tell the compiler not to. Don't Ada compilers already have > command-line options and/or pragmas to control how much optimization > takes place, anyway? Yes. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-19 0:00 ` Jon S Anthony @ 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Dale Stanbrough ` (4 more replies) 0 siblings, 5 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-20 0:00 UTC (permalink / raw) Jon said "I have to agree with Jon's point here. I don't see any reason why the definition of the language would have to prevent the compiler from using the information for optimization. If the customer didn't want that to happen, the vendor could add a command-line option or pragma to tell the compiler not to. Don't Ada compilers already have command-line options and/or pragmas to control how much optimization takes place, anyway?" This is really quite a tricky and subtle issue. If you do not see any problem, then it is likely you don't see the issues fully yet. The basic problem is that the notion of assertion can mean many things, and at the level of discussing the precise semantics of assertions, there are fundamental disagreements. There is certainly a school of thought that is insistent that it is crucial that assertions NOT affect the semantics or even the behavior of the program. You can declare this silly if you like, but it is more helpful if everyone makes the effort to understand the issues. In GNAT, pragma Assert (X); means EXACTLY if not X then raise Assert_Error; end if; which is well defined, but not at all in the category of assertions that the compiler can take advantage of, which can behave in a completely differrent (and possibly suprising manner). For instance, another view of assertions is exemplified by the following: pragma Assert (X /= 0); ... Q := 30 / X; where the compiler "knows" that X is non-zero, and therefore skips the test for X being zero in the division, and consequently generates some junk value in Q. In this model, assertions do not correspond to any executable code. There is nothing wrong with either of these models of assertions (or with any of several different models), but they are VERY different, and what we found in practice is that people had very strong opinions that an assert in the language should mean one or other of these, and that it was silly to suggest any alternative meaning -- not exactly a recipe for agreement, or for the devising of a language feature that would not cause a lot of confusion. I expect most Ada 95 compilers will copy the GNAT pragma Assert, but this is of course only one possible interpretation of this notion (it happens to be one whose semantics are very easy to describe, but it is not necessarily what everyone wants!). ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-20 0:00 ` Robert Dewar @ 1996-06-24 0:00 ` Dale Stanbrough 1996-06-24 0:00 ` hopkinc ` (7 more replies) 1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson ` (3 subsequent siblings) 4 siblings, 8 replies; 93+ messages in thread From: Dale Stanbrough @ 1996-06-24 0:00 UTC (permalink / raw) Robert Dewar writes: "There is nothing wrong with either of these models of assertions (or with any of several different models), but they are VERY different, and what we found in practice is that people had very strong opinions that an assert in the language should mean one or other of these, and that it was silly to suggest any alternative meaning -- not exactly a recipe for agreement, or for the devising of a language feature that would not cause a lot of confusion." Obviously if there are two concepts, then we should have two names. For example (in Ada) we could stick with pragma Assert(x); for the traditional "please check this really is the case" assertion and introduce pragma Fact(x); (or some other name) for the "this really is true, trust me, and make appropriate optimisations" type assertion. Can anyone think of a better name (pragma Declare(x) is not available in Ada) than "Fact"? Dale ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough @ 1996-06-24 0:00 ` hopkinc 1996-06-24 0:00 ` Lars Duening ` (6 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: hopkinc @ 1996-06-24 0:00 UTC (permalink / raw) In <4ql1fv$5ss@goanna.cs.rmit.EDU.AU>, Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes: >Can anyone think of a better >name (pragma Declare(x) is not available in Ada) than "Fact"? I recall an article some(20-25) years ago about a couple of extra boolean operators as in: if X was 57 then if X should_have_been 92 then perhaps there is something in this after all ;-) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough 1996-06-24 0:00 ` hopkinc @ 1996-06-24 0:00 ` Lars Duening 1996-06-24 0:00 ` Adam Beneschan ` (5 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: Lars Duening @ 1996-06-24 0:00 UTC (permalink / raw) In article <4ql1fv$5ss@goanna.cs.rmit.EDU.AU> Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes: >Obviously if there are two concepts, then we should have two names. For >example (in Ada) we could stick with > > pragma Assert(x); > >for the traditional "please check this really is the case" assertion >and introduce > > pragma Fact(x); > >(or some other name) for the "this really is true, trust me, and make >appropriate optimisations" type assertion. Can anyone think of a better >name (pragma Declare(x) is not available in Ada) than "Fact"? pragma Assume(x) ? -- Lars Duening; duening@ibr.cs.tu-bs.de ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough 1996-06-24 0:00 ` hopkinc 1996-06-24 0:00 ` Lars Duening @ 1996-06-24 0:00 ` Adam Beneschan 1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff ` (4 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: Adam Beneschan @ 1996-06-24 0:00 UTC (permalink / raw) Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> writes: > >Obviously if there are two concepts, then we should have two names. For >example (in Ada) we could stick with > > pragma Assert(x); > >for the traditional "please check this really is the case" assertion >and introduce > > pragma Fact(x); > >(or some other name) for the "this really is true, trust me, and make >appropriate optimisations" type assertion. Can anyone think of a better >name (pragma Declare(x) is not available in Ada) than "Fact"? > "Fantasy"? For many programmers, this would be a more appropriate pragma name. :) -- Adam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Assertions (was: Re: next "big" language?? (disagree)) 1996-06-24 0:00 ` Dale Stanbrough ` (2 preceding siblings ...) 1996-06-24 0:00 ` Adam Beneschan @ 1996-06-24 0:00 ` Robert A Duff 1996-06-24 0:00 ` Robert Dewar ` (2 more replies) 1996-06-24 0:00 ` next "big" language?? (disagree) Robert Dewar ` (3 subsequent siblings) 7 siblings, 3 replies; 93+ messages in thread From: Robert A Duff @ 1996-06-24 0:00 UTC (permalink / raw) In article <4ql1fv$5ss@goanna.cs.rmit.EDU.AU>, Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> wrote: >...Can anyone think of a better >name (pragma Declare(x) is not available in Ada) than "Fact"? pragma Assume? Actually, I don't see a need for these two separate pragmas. We can have: pragma Assert(...); and: pragma Suppress(Assertion_Check); pragma Assert(...); for these two cases. Note that in *both* of these cases, the compiler can optimize the following code based on the asserted "fact". These pragmas are really no different from constraint checks, which may or may not be suppressed, and which can, of course, affect the behavior of the program. The third case that Robert mentioned -- an assertion that cannot affect the behavior of the program in any way -- is quite impossible to define in language terms. It very well might be a useful thing, though. - Bob ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (was: Re: next "big" language?? (disagree)) 1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff @ 1996-06-24 0:00 ` Robert Dewar 1996-06-25 0:00 ` Robert A Duff 1996-06-24 0:00 ` Assertions (a different intent?) Gary McKee [not found] ` <4qrljg$15l8@watnews1.watson.ibm.com> 2 siblings, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-24 0:00 UTC (permalink / raw) Bob Duff said " pragma Suppress(Assertion_Check); pragma Assert(...); for these two cases. Note that in *both* of these cases, the compiler can optimize the following code based on the asserted "fact". These pragmas are really no different from constraint checks, which may or may not be suppressed, and which can, of course, affect the behavior of the program. " Not quite, remember that failing an assertion raises Assert_Error, it is not erroneous, so the compiler cannot assume (not P) at the point where the assert appears, it can only assume (not P) after the asssertion which is a VERY much weaker condition. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (was: Re: next "big" language?? (disagree)) 1996-06-24 0:00 ` Robert Dewar @ 1996-06-25 0:00 ` Robert A Duff 1996-06-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 93+ messages in thread From: Robert A Duff @ 1996-06-25 0:00 UTC (permalink / raw) In article <dewar.835633172@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Bob Duff said > >" > pragma Suppress(Assertion_Check); > pragma Assert(...); >" >Not quite, remember that failing an assertion raises Assert_Error, it is >not erroneous, so the compiler cannot assume (not P) at the point where >the assert appears, it can only assume (not P) after the asssertion >which is a VERY much weaker condition. What's "not P"? Are you assuming the above is "pragma Assert(not P);"? According to 11.5(26), failing a check IS erroneous, if that check has been suppressed. According to 11.5(27), an implementation may "add additional check names, with implementation-defined semantics" -- such as the Assertion_Check that I invented, above. Since failing the suppressed check would be erroneous, this can affect the generated code both before and after the assertion, depending on how smart your optimizer is. I'm not sure what you mean by "at the point where the assert appears" -- it's been suppressed, and will therefore presumably not generate any code. Of course, if the assertion is not suppressed, then the compiler can only know that the condition is true following the check. Perhaps I'm misunderstanding what you said, but it seems to me that in this regard (what the compiler can and cannot assume, with and without pragma Suppress) the pragma Assert is just like a normal constraint check (except, of course, that Asserts can have side-effects :-( ). Of course, pragma Assert is implementation defined, so it can have whatever semantics the implementer wants. - Bob ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (was: Re: next "big" language?? (disagree)) 1996-06-25 0:00 ` Robert A Duff @ 1996-06-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw) "According to 11.5(26), failing a check IS erroneous, if that check has been suppressed. According to 11.5(27), an implementation may "add additional check names, with implementation-defined semantics" -- such as the Assertion_Check that I invented, above. " Yes, Bob (Duff), I agree this approach is viable, I missed that you were inventing a new check, and I agree it is a reasonable one! ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (a different intent?) 1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff 1996-06-24 0:00 ` Robert Dewar @ 1996-06-24 0:00 ` Gary McKee [not found] ` <4qrljg$15l8@watnews1.watson.ibm.com> 2 siblings, 0 replies; 93+ messages in thread From: Gary McKee @ 1996-06-24 0:00 UTC (permalink / raw) In article <DtI7n4.Brz@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: > for these two cases. Note that in *both* of these cases, the compiler > can optimize the following code based on the asserted "fact". These > pragmas are really no different from constraint checks, which may or may > not be suppressed, and which can, of course, affect the behavior of the > program. > > The third case that Robert mentioned -- an assertion that cannot affect > the behavior of the program in any way -- is quite impossible to define > in language terms. It very well might be a useful thing, though. --------------------------------------------------------------- Robert has explained how "Pragma Assert" actually works in GNAT and, no doubt, it is useful as such. My own preference would be for something with diametrically opposite semantics. In particular, I see "assertions", whatever the syntax, as being a tool for specifying a program/subprogram in more detail and with more restrictions then the language semantics permit. Such an interpretation would REQUIRE that the compiler process them and raise exceptions when appropriate. The design constraint is that such assertions "must always be true IF the system is correct implemented". I achieve this affect with a simple package of Assertion procedures, exceptions, etc. Some examples of usage: 1) Verify a boolean relation between two incoming parameters to a reusable component: assert (param-A > param-b); 2) Verify that a parameter to a reusable component is within a legal (but non-contiguous) range (obviously, with syntactic changes): assert (param-a in (23..143) or param-a in (312..445) ); Other possiblities certainly exist. Such assertion semantics allow a competent deigner to embed design criteria, assumptions, and expectations in the executable code. ^ permalink raw reply [flat|nested] 93+ messages in thread
[parent not found: <4qrljg$15l8@watnews1.watson.ibm.com>]
* Re: Assertions (was: Re: next "big" language?? (disagree)) [not found] ` <4qrljg$15l8@watnews1.watson.ibm.com> @ 1996-06-28 0:00 ` Robert Dewar 0 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw) Norman Cohen said "|> The third case that Robert mentioned -- an assertion that cannot affect |> the behavior of the program in any way -- is quite impossible to define |> in language terms. It very well might be a useful thing, though. Sounds like a comment to me (albeit with compile-time type checking). " Sorry, I was not clear, people still want the assertion checked at run time, but they don't want the presence of the assertion to affect the rest of the program in any other way. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough ` (3 preceding siblings ...) 1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff @ 1996-06-24 0:00 ` Robert Dewar 1996-06-26 0:00 ` Marc C. Brooks ` (2 subsequent siblings) 7 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-24 0:00 UTC (permalink / raw) Dale said "Obviously if there are two concepts, then we should have two names. For example (in Ada) we could stick with pragma Assert(x); for the traditional "please check this really is the case" assertion and introduce pragma Fact(x); (or some other name) for the "this really is true, trust me, and make appropriate optimisations" type assertion. Can anyone think of a better name (pragma Declare(x) is not available in Ada) than "Fact"?" Sure this is one approach, but WG9 felt it was over-complex to introduce multiple concepts here, especially when it is essentially impossible to come up with non-confusing names (since assert is the obvious name for all cases). Note too that the pragma Assert in GNAT, which is equivalent to an if statement with a raise, is still not what some people want, since of course the optimizer can and does derive some information from the presence of the Assert. What some people want is an Assert that is guaranteed to be semantically non-intrusive -- a rather slippery concept. Anyway, in practice I think that the assert of GNAT is as far as it is reasonable to go. At least the advantage of the GNAT definition is that its semantics is trivially simple (since it is defined by the equivalent if/raise sequence). There just does not seem to be enough consensus to go further, unless you really go to full annotation, in for example the SPARK style using the Praxis tools. For this pragma Annotate, as recently recommended by the HRG to WG9, and as currently implemented in GNAT, can be used. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough ` (4 preceding siblings ...) 1996-06-24 0:00 ` next "big" language?? (disagree) Robert Dewar @ 1996-06-26 0:00 ` Marc C. Brooks 1996-06-26 0:00 ` Marc C. Brooks [not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM> 7 siblings, 0 replies; 93+ messages in thread From: Marc C. Brooks @ 1996-06-26 0:00 UTC (permalink / raw) > Obviously if there are two concepts, then we should have two names. For > example (in Ada) we could stick with > pragma Assert(x); > for the traditional "please check this really is the case" assertion > and introduce > pragma Fact(x); > (or some other name) for the "this really is true, trust me, and make > appropriate optimisations" type assertion. Can anyone think of a better > name (pragma Declare(x) is not available in Ada) than "Fact"? How about "pragma Check(x);" for the check and abort case and "pragma Hint(x);" for the optimization hint. This has the added advantage of reducing extraligual overloads on the meaning of "Assert(x)". Marc ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` Dale Stanbrough ` (5 preceding siblings ...) 1996-06-26 0:00 ` Marc C. Brooks @ 1996-06-26 0:00 ` Marc C. Brooks [not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM> 7 siblings, 0 replies; 93+ messages in thread From: Marc C. Brooks @ 1996-06-26 0:00 UTC (permalink / raw) > Obviously if there are two concepts, then we should have two names. For > example (in Ada) we could stick with > > pragma Assert(x); > > for the traditional "please check this really is the case" assertion > and introduce > > pragma Fact(x); > > (or some other name) for the "this really is true, trust me, and make > appropriate optimisations" type assertion. Can anyone think of a better > name (pragma Declare(x) is not available in Ada) than "Fact"? I would like pragma Check(x); for the assertion must be true or abort type, and pragma Fact(x); for the other kind, MERELY to avoid the use of Assert in either case. This would insure that extraligual knowledge would be suppressed. Marc ^ permalink raw reply [flat|nested] 93+ messages in thread
[parent not found: <4qsbm7$r1s@Starbase.NeoSoft.COM>]
* Re: "Assert"? "Assume"? (was: next "big" language?? (disagree)) [not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM> @ 1996-06-28 0:00 ` Alexander Bunkenburg 1996-06-28 0:00 ` Ian Collier 1996-07-01 0:00 ` Cameron Laird 1 sibling, 1 reply; 93+ messages in thread From: Alexander Bunkenburg @ 1996-06-28 0:00 UTC (permalink / raw) claird@Starbase.NeoSoft.COM (Cameron Laird) writes: > In article <4ql1fv$5ss@goanna.cs.rmit.EDU.AU>, > Dale Stanbrough <dale@goanna.cs.rmit.EDU.AU> wrote: > . > . > . > >Obviously if there are two concepts, then we should have two names. For > >example (in Ada) we could stick with > > > > pragma Assert(x); > > > >for the traditional "please check this really is the case" assertion > >and introduce > > > > pragma Fact(x); > > > >(or some other name) for the "this really is true, trust me, and make > >appropriate optimisations" type assertion. Can anyone think of a better > >name (pragma Declare(x) is not available in Ada) than "Fact"? > > > >Dale Assert(x) and Fact(x) seem to be the "assertion" and "guards" of "the" refinement calculus a la Back, Morris, and Morgan. E.g. Carroll Morgan: "Programming from Specifications", 1994, Prentice Hall. They are written {x} ; E x -> E where E is the program following the assertion or guard. Nigel Ward in his thesis about a functional refinement calculus calls "assertion" "assumptions". He writes them x >- E where E is the expression for which x is asserted. Alex ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: "Assert"? "Assume"? (was: next "big" language?? (disagree)) 1996-06-28 0:00 ` "Assert"? "Assume"? (was: next "big" language?? (disagree)) Alexander Bunkenburg @ 1996-06-28 0:00 ` Ian Collier 0 siblings, 0 replies; 93+ messages in thread From: Ian Collier @ 1996-06-28 0:00 UTC (permalink / raw) In article <4r07k8$9mf@seram.dcs.glasgow.ac.uk>, bunkenba@dcs.gla.ac.uk (Alexander Bunkenburg) wrote: >claird@Starbase.NeoSoft.COM (Cameron Laird) writes: >Assert(x) and Fact(x) seem to be the "assertion" and "guards" of "the" >refinement calculus a la Back, Morris, and Morgan. >They are written >{x} ; E >x -> E >where E is the program following the assertion or guard. >Nigel Ward in his thesis about a functional refinement calculus >calls "assertion" "assumptions". He writes them >x >- E >where E is the expression for which x is asserted. Well, as long as we are talking formal computing science, I have also seen such constructions. I believe the following versions were used by Hoare, though I'm slightly uncertain on that. I borrowed the assumption in my thesis. They are written: _|_ {p} assertion - the same as [p,true] T {p} assumption - the same as [true,p]. The first of these causes the program to abort when p is false. The second is "magic" - it is not possible ever for p to be false at that point in the program. The guarded command p -> SKIP as mentioned above has identical semantics to the assumption, but you never see it by itself except in some formal proofs. Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page: http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: "Assert"? "Assume"? (was: next "big" language?? (disagree)) [not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM> 1996-06-28 0:00 ` "Assert"? "Assume"? (was: next "big" language?? (disagree)) Alexander Bunkenburg @ 1996-07-01 0:00 ` Cameron Laird 1 sibling, 0 replies; 93+ messages in thread From: Cameron Laird @ 1996-07-01 0:00 UTC (permalink / raw) In article <4qsbm7$r1s@Starbase.NeoSoft.COM>, I wondered: . . . >Now I'm lost; what kind of people argue for the utility of >Fact()? If this congregation thinks pre-processors are >inherently problematic (they are), then surely we can >recognize that a Fact() is a confession that the language >in question promotes implementations which over-specify, >in comparison to their corresponding designs. A different >way to say the same thing: if P is sufficiently important >for Fact(P) to be of consequence, then it ought to be >natural to declare P *in* the language. . . . Now I get it. In my own crude language, Fact() or Assert() is an ingredient from the workshop of com- puter language theory. It certainly is a construct that be defined, and has definite benefits. From the standpoint of software engineering, though, it's hard for me to imagine a situation where the costs don't overweigh those benefits. Thanks to those who wrote to elucidate Assert(). Follow-ups severely narrowed. -- Cameron Laird http://starbase.neosoft.com/~claird/home.html claird@NeoSoft.com +1 713 623 8000 #227 +1 713 996 8546 FAX ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Dale Stanbrough @ 1996-06-24 0:00 ` Keith Thompson 1996-06-25 0:00 ` Robert A Duff 1996-06-25 0:00 ` Simon Read 1996-06-24 0:00 ` Adam Beneschan ` (2 subsequent siblings) 4 siblings, 2 replies; 93+ messages in thread From: Keith Thompson @ 1996-06-24 0:00 UTC (permalink / raw) [Newsgroups trimmed to comp.lang.ada] In <dewar.835306677@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > In GNAT, > > pragma Assert (X); > > means EXACTLY > > if not X then > raise Assert_Error; System.Assertions.Assert_Failure, actually. > end if; > > which is well defined, but not at all in the category of assertions that > the compiler can take advantage of, which can behave in a completely > differrent (and possibly suprising manner). I'm not sure I understand your point here. For example: declare X: Integer := Some_Unknown_Value; Y: Integer := Another_Unknown_Value; Z: Integer; begin pragma Assert(X /= 0); Z := X / Y; -- What may be assumed here? Put_Line("Z = " & Integer'Image(Z)); end; If the pragma Assert is equivalent to the if statement shown above, then surely the compiler can assume that X /= 0, and can eliminate the divide-by-zero check, if assertion checking is enabled. After all, if X is zero the division will never be executed. (Note that X is not volatile, shared, aliased, or anything fancy like that). Whether the current version of GNAT actually does this is another question. What gets interesting is having an option to disable assertion checking (as GNAT does). If the checking is disabled, may the compiler still assume that X /= 0? GNAT has chosen not to make this assumption. The alternative model (which I prefer) is to treat assertions in much the same was as predefined checks; execution of code that violates an assertion is erroneous. Personally, I wish the assert statement of Preliminary Ada (the 1979 version) had remained in the language, preferably with an extension to allow it in declarative parts. Assertion checking could be disabled with "pragma Suppress(Asssert_Error);". By the way, here's another way to implement assertions without special compiler support: declare subtype Truth is Boolean range True .. True; X: Integer := Some_Unknown_Value; X_Non_Zero: constant Truth := X /= 0; Y: Integer := Another_Unknown_Value; Z: Integer; begin Z := X / Y; Put_Line("Z = " & Integer'Image(Z)); end; The declaration of Non_Zero raises Constraint_Error if the assertion fails, and will probably trigger a compiler warning if it fails statically. This is probably an incomplete solution, since I *think* the compiler is allowed to eliminate X_Non_Zero if it's never referenced. Perhaps pragma Volatile can be used to work around this, but that introduces other complications. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 "As the most participatory form of mass speech yet developed, the Internet deserves the highest protection from government intrusion." -- ACLU v. Reno ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson @ 1996-06-25 0:00 ` Robert A Duff 1996-06-25 0:00 ` Simon Read 1 sibling, 0 replies; 93+ messages in thread From: Robert A Duff @ 1996-06-25 0:00 UTC (permalink / raw) In article <DtIqn8.ADH@thomsoft.com>, Keith Thompson <kst@thomsoft.com> wrote: >What gets interesting is having an option to disable assertion checking >(as GNAT does). If the checking is disabled, may the compiler still >assume that X /= 0? GNAT has chosen not to make this assumption. >The alternative model (which I prefer) is to treat assertions in much >the same was as predefined checks; execution of code that violates an >assertion is erroneous. I would think both ways of disabling would be useful. The latter is equivalent to pragma Suppress, with an implementation-defined check name. >By the way, here's another way to implement assertions without special >compiler support: > > subtype Truth is Boolean range True .. True; >...This is probably an incomplete solution, since I *think* the ^^^^^^^^^^ You misspelled "incorrect". ;-) >compiler is allowed to eliminate X_Non_Zero if it's never referenced. Exactly. 11.6 says that the check can be eliminated. If you're implementing your own assertions, you want to use an explicit raise_statement to raise the exception, since 11.6 doesn't apply to explicit raise_statements. Just define these in some with'ed-everywhere package: procedure Assert(Condition: Boolean) is begin if not Condition then raise Assertion_Failed; end if; end Assert; type Dummy is (Junk); function Assert(Condition: Boolean) return Dummy is begin Assert(Condition); return Junk; -- Ignored return value. end Assert; The latter is so you can assert things in declarative contexts: subtype S is range 1..Function_Call(X); D: Dummy := Assert(S'Last > 10); I find that the majority of assertions in my code are in declarative contexts. This is because a precondition for a procedure ought to be evaluated before the procedure does anything, and the declarative part of a procedure does stuff. It's annoying that I can't just say "Assert(S'Last > 10);" there. In GNAT, the "pragma" before Assert is slightly less annoying. >Perhaps pragma Volatile can be used to work around this, but that >introduces other complications. Hmm. I hadn't thought of using Volatile in that way. - Bob ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson 1996-06-25 0:00 ` Robert A Duff @ 1996-06-25 0:00 ` Simon Read 1 sibling, 0 replies; 93+ messages in thread From: Simon Read @ 1996-06-25 0:00 UTC (permalink / raw) It's the difference between compiler directives and run-time code. I'd have one construction for the compiler directive "Optimise if you can using the following assumption" and one other construction for the run-time code "Make sure the following is true; cause an error signal if not." in Robert Dewar's construction pragma Suppress(Assertion_Check); pragma Assert(...); the "Suppress.." line modifies the run-time code. The "Assert.." line is both run-time code AND compiler directive, which is mixed, which is why I would not favour it. Since most posters here seem to be using the word "check" or "checking" as a verb to describe the run-time actions, why not use pragma Check (x) as run-time code for "Check; Verify; ensure; cause error if wrong" Also, assumptions don't hold for the entire program, or even in one subroutine. Therefore: Begin assume (x) ... ... End assume (x) should give the compiler plenty to think about. These assumptions need not be nested tidily with loops and other program control structures. They may overlap, but don't need to nest entirely. These assumptions don't even need to nest with other assumptions. They can overlap. Since nesting is not obligatory, I think the assumptions will probably need something like line labels to define start and end points. Simon ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Dale Stanbrough 1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson @ 1996-06-24 0:00 ` Adam Beneschan 1996-06-25 0:00 ` Darin Johnson 1996-06-25 0:00 ` Brian Nettleton @pulsar 4 siblings, 0 replies; 93+ messages in thread From: Adam Beneschan @ 1996-06-24 0:00 UTC (permalink / raw) In article <dewar.835306677@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Jon said > >"I have to agree with Jon's point here. I don't see any reason why the >definition of the language would have to prevent the compiler from >using the information for optimization. If the customer didn't want >that to happen, the vendor could add a command-line option or pragma >to tell the compiler not to. Don't Ada compilers already have >command-line options and/or pragmas to control how much optimization >takes place, anyway?" The above words were mine, not Jon's. >This is really quite a tricky and subtle issue. If you do not see any >problem, then it is likely you don't see the issues fully yet. The basic >problem is that the notion of assertion can mean many things, and at the >level of discussing the precise semantics of assertions, there are >fundamental disagreements. There is certainly a school of thought that >is insistent that it is crucial that assertions NOT affect the semantics >or even the behavior of the program. > >You can declare this silly if you like, but it is more helpful if everyone >makes the effort to understand the issues. > >In GNAT, > > pragma Assert (X); > >means EXACTLY > > if not X then > raise Assert_Error; > end if; > >which is well defined, but not at all in the category of assertions that >the compiler can take advantage of, which can behave in a completely >differrent (and possibly suprising manner). I'm losing you here. What do you mean that the compiler can't take advantage of the assertion? If you mean simply that this is how GNAT has been taught to behave, OK--you know a lot more about GNAT than I do. If you mean that logically or semantically, the compiler can't take advantage of the information--why not? If I wrote code that looked like this: if X not in Some_Subtype'range then raise Some_User_Defined_Error; end if; { . . . More code that doesn't modify X . . . { if X < Some_Subtype'first then { blahblahblah { end if; I would expect a good optimizer to assume, throughout the bracketed section of code, that X was in Some_Subtype'range, because control could never get to that part of the code if it weren't. (Assuming, of course, X is not volatile.) Therefore, the second "if" statement could be deleted, and any other checks that made sure X was in Some_Subtype'range could be suppressed. And if I'd expect this behavior if an exception I defined were raised, why would I not expect this if the "raise" statement were changed to raise Assert_Error? (I could be missing the whole point of this thread--it's gone on for a while and I've forgotten how it started.) -- Adam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-20 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1996-06-24 0:00 ` Adam Beneschan @ 1996-06-25 0:00 ` Darin Johnson 1996-06-26 0:00 ` A. Grant 1996-06-26 0:00 ` Dale Stanbrough 1996-06-25 0:00 ` Brian Nettleton @pulsar 4 siblings, 2 replies; 93+ messages in thread From: Darin Johnson @ 1996-06-25 0:00 UTC (permalink / raw) > >Obviously if there are two concepts, then we should have two names. For > >example (in Ada) we could stick with > > > > pragma Assert(x); > > > >for the traditional "please check this really is the case" assertion > >and introduce > > > > pragma Fact(x); > > > >(or some other name) for the "this really is true, trust me, and make > >appropriate optimisations" type assertion. Can anyone think of a better > >name (pragma Declare(x) is not available in Ada) than "Fact"? How about "Assert"!!! That's exactly what this means in English, despite the fact that Ada changed its meaning. "Assert" and "assertion" in English in no way mean "check that this is true". Instead, "pragma Assert(x)", or "#pragma assert(x)" should mean that x is assumed to be true; which implementation-wise may involve compiler optimizations that break things if the assertion is false (what exactly happens might be changed via compiler options, such the debugging does different stuff than production code). At least in C, an implementation can define "#pragma assert" to do something much different than the assert macro; even though it is confusing. -- Darin Johnson djohnson@ucsd.edu O- - Luxury! In MY day, we had to make do with 5 bytes of swap... ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-25 0:00 ` Darin Johnson @ 1996-06-26 0:00 ` A. Grant 1996-06-26 0:00 ` Dale Stanbrough 1 sibling, 0 replies; 93+ messages in thread From: A. Grant @ 1996-06-26 0:00 UTC (permalink / raw) In article <qqn31rr53g.fsf@tartarus.ucsd.edu> djohnson@tartarus.ucsd.edu (Darin Johnson) writes: >How about "Assert"!!! That's exactly what this means in English, >despite the fact that Ada changed its meaning. "Assert" and >"assertion" in English in no way mean "check that this is true". If someone says something is true, don't you check it? There are all sorts of implicit assertions made by programmers which the compiler doesn't have to believe. F(A,B(5),C/D) implicitly asserts that F takes three parameters, that 5 is not out of bounds for B, and that D is non-zero. It is necessary for correct execution of the program (assuming we aren't relying on trapping exceptions for the moment) that these be correct, so if they can't be checked statically they should be checked dynamically. Explicit assertions are just a way of doing the same for more complicated algorithms where the compiler is unable to determine for itself that some condition must be met for an algorithm to function correctly, or is unable to propagate implicit assertions backwards far enough to make the test as efficient as it could be. The only situation where an assertion test is unnecessary is when an assertion is guaranteed to be true by a proof that is too complex for the program. For example FUNCTION EXP(X) ... some polynomial ... EXP = ... RETURN where you may want to assert in the published interface to EXP that its result is positive. I would suggest that any language environment which supports this kind of unproved assertion must have linguistic support (i.e. not just a comment) for reference to an external proof, e.g. a full record of the developer who made the assertion and any references they supply. Again this is just like real life - if you can't see the truth of someone's assertion, you have to see their evidence, and if you don't understand it, but it is from a reputable source, you remember what it is in case you act on the assertion and get challenged. Or you at least get enough paperwork so that if the assertion turns out to be wrong and your rocket explodes, they get sued, not you. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-25 0:00 ` Darin Johnson 1996-06-26 0:00 ` A. Grant @ 1996-06-26 0:00 ` Dale Stanbrough 1 sibling, 0 replies; 93+ messages in thread From: Dale Stanbrough @ 1996-06-26 0:00 UTC (permalink / raw) Darin Johnson, writes: "How about "Assert"!!! That's exactly what this means in English, despite the fact that Ada changed its meaning. "Assert" and "assertion" in English in no way mean "check that this is true". -- But this doesn't mean that assertions can't be checked. For example I checked the assertions you made below, and I don't believe them :-). "Instead, "pragma Assert(x)", or "#pragma assert(x)" should mean that x is assumed to be true; which implementation-wise may involve compiler optimizations that break things if the assertion is false (what exactly happens might be changed via compiler options, such the debugging does different stuff than production code)." -- If all compilers assumed that asserts were true, then they would produce _no_ executable code to check the assertion, and would spend their time making the optimazations you suggest. How many do that? I suspect accepted industry practice _is_ to check assertions and to take appropriate action. "At least in C, an implementation can define "#pragma assert" to do something much different than the assert macro; even though it is confusing." I'm sorry, but I don't follow this. Dale ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-20 0:00 ` Robert Dewar ` (3 preceding siblings ...) 1996-06-25 0:00 ` Darin Johnson @ 1996-06-25 0:00 ` Brian Nettleton @pulsar 1996-06-26 0:00 ` Robert Dewar 4 siblings, 1 reply; 93+ messages in thread From: Brian Nettleton @pulsar @ 1996-06-25 0:00 UTC (permalink / raw) In <dewar.835306677@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >In GNAT, > pragma Assert (X); >means EXACTLY > if not X then > raise Assert_Error; > end if; >which is well defined, but not at all in the category of assertions that >the compiler can take advantage of, which can behave in a completely >differrent (and possibly suprising manner). >For instance, another view of assertions is exemplified by the following: > pragma Assert (X /= 0); > ... > Q := 30 / X; >where the compiler "knows" that X is non-zero, and therefore skips the >test for X being zero in the division, and consequently generates some >junk value in Q. In this model, assertions do not correspond to any >executable code. I'm not sure I see the complete distinction. Wouldn't it be possible for a compiler to eliminate any divide-by-zero check from the following code sequence: if not (X /= 0) then raise Assert_Error; end if; Q := 30 / X; The divide is unreachable when X = 0. Now this admittedly does cause a change in the generated code when an assertion is used. I'm trying to understand the "assertions should not affect things" camp. -Brian Nettleton ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-25 0:00 ` Brian Nettleton @pulsar @ 1996-06-26 0:00 ` Robert Dewar 1996-06-28 0:00 ` Fergus Henderson 0 siblings, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-26 0:00 UTC (permalink / raw) Brian says (regarding the possible interpretations of Assert): I'm not sure I see the complete distinction. Wouldn't it be possible for a compiler to eliminate any divide-by-zero check from the following code sequence: if not (X /= 0) then raise Assert_Error; end if; Q := 30 / X; The divide is unreachable when X = 0. Now this admittedly does cause a change in the generated code when an assertion is used. I'm trying to understand the "assertions should not affect things" camp. It's delicate, but let's extend the example: Q := 30 / X; assert X /= 0; Q := 30 / X; roughtly the three points of view are: 1. the assert has no effect on the code, so the semantics is exactly equivalent to what you would get by leaving out the assert, but the assert can be checked at run time. In this model it would be wrong for the compiler to leave out the second divide by zero check. Warning: this model is hard to define formally. 2. The assert is equivalent to an if. In this case the compiler can omit the second divide by zero check. This is what GNAT does, and is easy to define formally, since it is just an equivalent to the code that Brian quotes. 3. The assert does not correspond to executable code, but is an assertion that the compiler can use as an assumption in compiling code (in Ada terms you can almost think of this as saying that the semantics of the assert is that the execution is erroneous if the condition is false). In this interpretation the *first* of the divide by zero checks in the above example can be omitted. If this is not completely clear, that's not surprising, this is a messy area to be absolutely sure of what the other guy is talking about :-) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-26 0:00 ` Robert Dewar @ 1996-06-28 0:00 ` Fergus Henderson 1996-06-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 93+ messages in thread From: Fergus Henderson @ 1996-06-28 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: >roughtly the three points of view are: > > 1. the assert has no effect on the code, so the semantics is exactly > equivalent to what you would get by leaving out the assert, but > the assert can be checked at run time. In this model it would be > wrong for the compiler to leave out the second divide by zero > check. Warning: this model is hard to define formally. Why would anyone want this model? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-28 0:00 ` Fergus Henderson @ 1996-06-28 0:00 ` Robert Dewar 1996-06-30 0:00 ` Fergus Henderson 0 siblings, 1 reply; 93+ messages in thread From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw) Fergus asked: "Why would anyone want this model?" referring to the non-intrusive model of assert, where putting in asserts does not affect the rest of the generated code (the one I noted was hard to define). Seems self-explanatory to me -- I am not saying that it is the preferable semantics, but it is easy to understand why people want this, they want to be able to turn assertions on and off without affecting the behavior of the code. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-28 0:00 ` Robert Dewar @ 1996-06-30 0:00 ` Fergus Henderson 1996-06-30 0:00 ` Robert Dewar 0 siblings, 1 reply; 93+ messages in thread From: Fergus Henderson @ 1996-06-30 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) writes: >"Why would anyone want this model?" > >referring to the non-intrusive model of assert, where putting in asserts >does not affect the rest of the generated code (the one I noted was hard >to define). > >Seems self-explanatory to me -- I am not saying that it is the preferable >semantics, but it is easy to understand why people want this, they want >to be able to turn assertions on and off without affecting the behavior >of the code. But it *does* affect the behaviour! Are the people who want this model asking for the impossible? -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-30 0:00 ` Fergus Henderson @ 1996-06-30 0:00 ` Robert Dewar 0 siblings, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-30 0:00 UTC (permalink / raw) Fergus said: "But it *does* affect the behaviour! Are the people who want this model asking for the impossible?" Maybe I was not clear enough, because at least informally, it is easy enough to understand what is wanted. The word behavior was confusing in my original note, because I was talking about the behavior of the compiler, not the behavior of the program. What is wanted is that the code generated not be affected by the presence of assert, so you can stick in asserts without affecting the code. Now that's a little bit of a self-contradiction, since obviously there is code for the assert itself if it is turned on, so more accurately (and this is why it is hard to characterize this requirement), the requirement is to minimize the effect on the generated code. For example, suppose we write: x := y / z; and we get a divide by zero error from the generated code. Now there are two reasons for this. Either z is zero, or there is something wrong with the generated code. Now suppose we add an assertion: pragma Assert (z /= 0); x := y / z; and we run the code and this time get no error. Well that's confusing. The probably explanation is that the assert is intefering and changing the generated code. In particular, the most likely cause of getting no error is that indeed z is non-zero, and that the compiler now generates different (correct) code for the division, omitting the faulty check for a zero divisor. If your assert is non-intrusive according to the definition (or rather informal description) above, then you will get a division by zero error at the divide, even though the assertion does not fail. Well that's still a puzzle, but leaves things clearer. Note that we are not necessarily talking about improper code generation from the compiler, erroneous programs can cause this difficulty. For example, suppose the definition of z is: z : integer range 1 .. 10; now the compiler can legitimately use 32 bits to represent z, but it can also legitimately assume that the value is in the range 1 .. 10. It would therefore be fine for the assert to check only the low order 8 bits of the 32 bits, and the divide to use all 32 bits. This would result in the anomolous behavior perceived. (in the case where z was in fact uninitialized or otherwise abnormal) The notion of the non-intrusive assert ("please compiler, don't try to figure out things from the assert, compile it in isolation and do not let it affect other code") is particularly valuable in the presence of errors in the compiler code generator, or in the case of erroneous programs. In either case, the additional deductions the compiler does from the assert (which of course might even be wrong themselves) can make it harder to figure out what is going on. I hope this is clear enough to understand this point of view. One thing for sure is that it is essential to understand all three points of view before starting off to design language features in this area. I am not saying you have to agree with all points of view, but you definitely have to make the effort to fully understand them. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` A. Grant 1996-06-12 0:00 ` Robert Dewar @ 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` A. Grant 1 sibling, 1 reply; 93+ messages in thread From: ++ robin @ 1996-06-12 0:00 UTC (permalink / raw) ag129@ucs.cam.ac.uk (A. Grant) writes: >In article <4pj8p7$h9r@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >> >euahjn@eua.ericsson.se (Henrik Johansson) writes: >> >>assertion expression found in other languages like Eiffel ( >preconditions,> >>postconditions, assertions). >>---What is the point of this? >> A declaration buried somewhere else, and a test. >> Why not something in clear english, which doesn't need a >>reference to some other part of the program, like: >> if mod(x, 2) ^= 0 then >> put ('The value of x is not odd.'); >The point of assertions is not to print messages for the >programmer. ---If you don't tell the programmer that something is wrong, there's really little point in putting extraneous clutter in the program. > You can use them to allow the compiler to >optimise safely, provide a contractual interface between >modules, and for preconditions, postconditions, loop invariants >etc. when proving the correctness of programs. >E.g. the assertion that X is odd could form part of the >declared interface to a module whose implementation was hidden. ---That may be so, but if the program doesn't feed the fact that there is a violation, then there's no point in the program. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` ++ robin @ 1996-06-12 0:00 ` A. Grant 1996-06-14 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 93+ messages in thread From: A. Grant @ 1996-06-12 0:00 UTC (permalink / raw) In article <4plaa6$c7a@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > ag129@ucs.cam.ac.uk (A. Grant) writes: > >> if mod(x, 2) ^= 0 then > >> put ('The value of x is not odd.'); > >The point of assertions is not to print messages for the > >programmer. >---If you don't tell the programmer that something is wrong, >there's really little point in putting >extraneous clutter in the program. You really don't understand do you? An assertion isn't meant to fail. If it ever does fail it should do more than print a message to the user (how is it meant to print a message to the _programmer_?) -- a full traceback and dump would be more useful, followed by error recovery. It should not continue with execution of the following code if that is making assumptions based on the assertion being true. > > You can use them to allow the compiler to > >optimise safely, provide a contractual interface between > >modules, and for preconditions, postconditions, loop invariants > >etc. when proving the correctness of programs. > >E.g. the assertion that X is odd could form part of the > >declared interface to a module whose implementation was hidden. >---That may be so, but if the program doesn't feed the >fact that there is a violation, then there's no point in the >program. The idea is that assertions are a static property of the program, like a more complex form of typing (see someone else's post above). Ideally you should be able to go through your program and prove that all your assertions are satisfied without the need for any runtime tests at all. Then you can compile without assertions. A clever compiler might be able to prove things too. Surely the concept of formal proof of programs is familiar to anyone at RMIT? What exactly is your position there? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` A. Grant @ 1996-06-14 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 93+ messages in thread From: Richard A. O'Keefe @ 1996-06-14 0:00 UTC (permalink / raw) ag129@ucs.cam.ac.uk (A. Grant) writes: >Surely the concept of formal proof of programs is familiar to >anyone at RMIT? What exactly is your position there? http://www.cs.rmit.edu.au/Staffing/AcademicStaff/ provides a list of all the RMIT CS staff. http://www.cs.rmit.edu.au/~rav/ takes to you rav's home page, which will tell you that he is a Senior Lecturer. (Me, I'm only a Lecturer.) He has recently published two books. He is our local PL/I expert. RMIT teaches formal methods in some of its courses. We use Ada as our first-year language, and continue to use it (though not exclusively) in later years. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` A. Grant @ 1996-06-12 0:00 ` Richard A. O'Keefe 1996-06-12 0:00 ` ++ robin 1 sibling, 1 reply; 93+ messages in thread From: Richard A. O'Keefe @ 1996-06-12 0:00 UTC (permalink / raw) > ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: > > subtype Assertion is Boolean range True .. True; > > ... > > X_Is_Even: Assertion := X mod 2 = 0; > >This will raise a constraint exception if the assertion is false. > >Looks like an assertion to me. I am seeing this in comp.lang.ada, where, to preserve what tattered shreds of credibility I may perhaps retain, I should point out that this was a flip response I posted to an attack in comp.lang.misc. The last thing I wanted to do was to admit that an Ada compiler may optimise this away... rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >---What is the point of this? > A declaration buried somewhere else, and a test. The declaration is *not* buried "somewhere else", but precisely where it is needed. The context is something like this: -- assume an external -- function Assertion(Condition: Boolean) return Boolean is -- begin -- if not Condition then -- raise Assertion_Violation; -- end if; -- return Condition; -- end Assertion; procedure P(X: Natural) is Precondition: constant Boolean := Assertion( X mod 2 = 0 ); ... > Why not something in clear english, which doesn't need a >reference to some other part of the program, like: > if mod(x, 2) ^= 0 then > put ('The value of x is not odd.'); (a) That is not English. (b) It is back to front: I was asserting that X *should* be even; you are printing an error mesage if the value is ok! (c) This *is* a reference to some other part of the program. The intent is, after all, to state _all_ the properties of an argument in one place. Why should the fact that X should be even be ripped apart and stated miles away from the fact that X should be a natural number? (d) A command to write a string to SYSOUT is not the same as a declaration that says that a particular condition should be true. >This has the aditional benefit that the user of the program >has a clear unequivocal message about the cause of the problem. (e) But who says there *is* a user? In C, for example, assert() raises the SIGABRT exception, which may (but need not) be handled by the program itself. (f) The message is not clear. How can you possibly expect a user to know what 'x' means? I have been the victim of programs that responded to error situations by producing symbolic dumps (any other EMAS users out there?) and it was really useless; the internal details of a program just aren't intelligible to most of its users. (g) The message is not about the cause. It is about a symptom. (h) If you want a message, I can, using goanna:~ok/Ada.d/assertions.ad{s,b}, write procedure P(X: Natural) is Precondition: constant Boolean := Assertion( X mod 2 = 0, "The frotznick count must be even" ); ... >If it's important that the whereabouts of this test be known, >the programmer can include a statement such as "signal error;" >or "signal condition (xyz);" or "put (' at line ', sourceline );" >along with the put statement. [PL/I example] The one thing that I cannot mimic in my Assertions package is C's "NDEBUG" flag. The nearest that one could get to it would be to have assertions of the form Assert(No_Debug or else (the real assertion)); Of course it _is_ possible to get this effect by using a preprocessor. The version of m4 I use has a flag to get case-insensitive macro names, so define(Assert, `null') define(Assertion, `True') would do the trick. I have used M4 to good effect with Pascal, but have so far held off using it with Ada. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` Richard A. O'Keefe @ 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 93+ messages in thread From: ++ robin @ 1996-06-12 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: >> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >> > subtype Assertion is Boolean range True .. True; >> > ... >> > X_Is_Even: Assertion := X mod 2 = 0; >> >This will raise a constraint exception if the assertion is false. >> >Looks like an assertion to me. >I am seeing this in comp.lang.ada, where, to preserve what tattered shreds >of credibility I may perhaps retain, I should point out that this was a >flip response I posted to an attack in comp.lang.misc. The last thing I >wanted to do was to admit that an Ada compiler may optimise this away... >rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >>---What is the point of this? >> A declaration buried somewhere else, and a test. >The declaration is *not* buried "somewhere else", but precisely where >it is needed. The context is something like this: > -- assume an external > -- function Assertion(Condition: Boolean) return Boolean is > -- begin > -- if not Condition then > -- raise Assertion_Violation; > -- end if; > -- return Condition; > -- end Assertion; > procedure P(X: Natural) is > Precondition: constant Boolean := Assertion( > X mod 2 = 0 > ); > ... ---Why have 2 lines when 11 will suffice? >> Why not something in clear english, which doesn't need a >>reference to some other part of the program, like: >> if mod(x, 2) ^= 0 then >> put ('The value of x is not odd.'); >(a) That is not English. ---The message is clear English. The test is, perhaps, English-like. The outcome is a darn-site better & clearer than the example you originally gave. subtype Assertion is Boolean range True .. True; while clear-ish, is circumlocuitous, to say the least. >(b) It is back to front: I was asserting that X *should* be even; > you are printing an error mesage if the value is ok! ---The example was an illustration. It wasn't a literal translation of yours. It wasn't intended to make sense. The original was "something .. like", right? >(c) This *is* a reference to some other part of the program. > The intent is, after all, to state _all_ the properties of > an argument in one place. ---Now your example code is different from the original. Now it's on procedure entry. > Why should the fact that X should be > even be ripped apart and stated miles away from the fact that > X should be a natural number? ---It looks like your code is insisting that X should be even. >(d) A command to write a string to SYSOUT is not the same as a > declaration that says that a particular condition should be true. >>This has the aditional benefit that the user of the program >>has a clear unequivocal message about the cause of the problem. >(e) But who says there *is* a user? ---OK, so no-one runs the program, no-one looks at the output. > In C, for example, assert() > raises the SIGABRT exception, which may (but need not) be handled > by the program itself. ---Which is the example I originally gave above, for PL/I. >(f) The message is not clear. How can you possibly expect a user to > know what 'x' means? ---I used "x" because you used x. The writer of the program will put in a meaningful explanation of the error, which is what I proposed. > I have been the victim of programs that > responded to error situations by producing symbolic dumps (any > other EMAS users out there?) and it was really useless; the > internal details of a program just aren't intelligible to most > of its users. ---You're confusing exception reporting to the user of a program with debug info that will be of use to the writer of the program. >(g) The message is not about the cause. It is about a symptom. ---There's nothing to prevent the programmer putting in a full explanation of the cause of the error, as well as, of course, the symptom. And of course, what the user should do about it. >(h) If you want a message, I can, using goanna:~ok/Ada.d/assertions.ad{s,b}, > write > > procedure P(X: Natural) is > Precondition: constant Boolean := Assertion( > X mod 2 = 0, > "The frotznick count must be even" > ); > ... ---Yoiks!, another great gob of code! Does it make the program more important-looking to have multiple procedures compared with the 2-line clear, unequivocal, unambiguous code I gave? It won't break down, you don't have to go searching for the procedure(s) to find out what the code is doing. If a job requires a 0.5cm screw, why does it take no less than a 20cm coach screw to fix it? The hammer law? >>If it's important that the whereabouts of this test be known, >>the programmer can include a statement such as "signal error;" >>or "signal condition (xyz);" or "put (' at line ', sourceline );" >>along with the put statement. [PL/I example] >The one thing that I cannot mimic in my Assertions package is C's >"NDEBUG" flag. The nearest that one could get to it would be to >have assertions of the form > Assert(No_Debug or else (the real assertion)); >Of course it _is_ possible to get this effect by using a preprocessor. ---If we bring a preprocesor into it, we can do things like: assert ("x > b", "the value of x is out of range" ); The relevant macro would be something like: assert: procedure (test, message); answer ('if ' || test || ' then put (' || message || ')' ); end assert; That's 3 lines, I think. [irrelevant section omitted] >Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` ++ robin @ 1996-06-12 0:00 ` Richard A. O'Keefe 1996-06-13 0:00 ` ++ robin 1996-06-13 0:00 ` ++ robin 0 siblings, 2 replies; 93+ messages in thread From: Richard A. O'Keefe @ 1996-06-12 0:00 UTC (permalink / raw) rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > > -- assume an external > > -- function Assertion(Condition: Boolean) return Boolean is > > -- begin > > -- if not Condition then > > -- raise Assertion_Violation; > > -- end if; > > -- return Condition; > > -- end Assertion; > > procedure P(X: Natural) is > > Precondition: constant Boolean := Assertion( > > X mod 2 = 0 > > ); > > ... >---Why have 2 lines when 11 will suffice? "--" introduces a comment. The function Assertion is already in a library package (of mine). I don't write it over and over again. You want two lines? Ok, I'll move the right parenthesis up a line. In amongst declarations, e.g. for checking subprogram parameters: Arguments_Valid: constant Boolean := Assertion( X mod 2 = 0 ); In amongst statements: Assert(X mod 2 = 0); Want a message in there? Still two lines: Arguments_Valid: constant Boolean := Assertion( X mod 2 = 0, "Frobnitz count must be even"); ... Assert(X mod 2 = 0, "Frobnitz count must be even"); The statement version is one line, not two. > >> put ('The value of x is not odd.'); >---The message is clear English. No. The message is clear English to someone who already knows what x is. Messages for users should use *application domain* terms, not *implementation domain* terms. >The test is, perhaps, English-like. I do not see "X mod 2 ^= 0" as any more English-like than "X mod 2 = 0". I do not see "if ... then put" as any more English-like than "Assert". >The outcome is a darn-site better & clearer than >the example you originally gave. In the source code, only to someone who does not know what an assertion _is_. At run time, neither is acceptable. (Hint: what does "I18N" stand for?) >---The example was an illustration. It wasn't a literal >translation of yours. It wasn't intended to make sense. If it _wasn't_ a translation of mine, what was the point of it? How can you claim that it is easier or better or whatever than the code I showed, unless it accomplishes the same end? In fact, your slip was an excellent illustration of why the "negative logic" in such an if-then-else is a bad idea and an assertion is a good idea. >The original was "something .. like", right? > >(c) This *is* a reference to some other part of the program. > > The intent is, after all, to state _all_ the properties of > > an argument in one place. >---Now your example code is different from the original. >Now it's on procedure entry. No, the original only ever made sense in that context. >---It looks like your code is insisting that X should be even. Yes! That's exactly right! You understood! > >(e) But who says there *is* a user? >---OK, so no-one runs the program, no-one looks at the output. Come now. You and I, rav, are posting from a UNIX system. It is not only possible, it is not only normal, it is extremely common for programs to run on behalf of other programs. It is even very common for programs to run when there is no user in the building. (Look up 'cron' some time.) It is very nearly the rule in UNIX for the output of a program to be examined by another program. (Which is why error messages that _are_ written should be written to stderr, not stdout.) > > In C, for example, assert() > > raises the SIGABRT exception, which may (but need not) be handled > > by the program itself. >---Which is the example I originally gave above, for PL/I. No, the example you original gave was a PUT statement inside an IF. > >(f) The message is not clear. How can you possibly expect a user to > > know what 'x' means? >---I used "x" because you used x. The writer of the program >will put in a meaningful explanation of the error, which is >what I proposed. I used x in the _test_ because x is what the program had. I did _not_ use x in the _message_. > > I have been the victim of programs that > > responded to error situations by producing symbolic dumps (any > > other EMAS users out there?) and it was really useless; the > > internal details of a program just aren't intelligible to most > > of its users. >---You're confusing exception reporting to the user of >a program with debug info that will be of use to the >writer of the program. No, I am reporting actual experience as an end-user. It is the people who *wrote* the programs who were confused. > >(g) The message is not about the cause. It is about a symptom. >---There's nothing to prevent the programmer putting in a >full explanation of the cause of the error, as well as, >of course, the symptom. And of course, what the user should >do about it. Aside from the fact that the programmer of a library package CANNOT know what the cause is, this applies equally to C or Ada. So? > > Precondition: constant Boolean := Assertion( > > X mod 2 = 0, > > "The frotznick count must be even" > > ); > > ... >---Yoiks!, another great gob of code! Does it make the program >more important-looking to have multiple procedures compared >with the 2-line clear, unequivocal, unambiguous code I gave? What multiple procedures? We have - a declaration that something is a precondition - an expression stating what the precondition _is_ - a string saying what message to give if the assertion fails. What great gob of code? Assertion(-,-) is a LIBRARY FUNCTION which I have explained in a comment, but does not appear in the listing of a an actual program that uses it. >It won't break down, you don't have to go searching for the >procedure(s) to find out what the code is doing. I'm sorry, this is completely back to front. The names "Assert" and "Assertion" explain themselves to any good programmer. But an "IF ... PUT" requires some decoding. > If a job requires a 0.5cm screw, why does it take no less than >a 20cm coach screw to fix it? The hammer law? What makes you think that PUT is any less of a library subprogram than Assertion? Let us have a fair comparison. Since your IF ... PUT is only usable as a statement, let's compare it with Assert. Assert(x mod 2 = 0, "Frobnitz count must be even"); -vs- IF x MOD 2 ^= 0 THEN DO; PUT 'Frobnitz count must be even'; SIGNAL whatever_you_want_to_signal; END; Which one is a great gob of code, which is so tedious to write that programmers avoid it, and which one is a one-line call to a simple library procedure? If I were using PL/I, I would certainly write an Assert procedure and use it. As far as that is concerned, there is little to choose between PL/I and Ada. As far as I can see, the debate is about whether to use a library function, or whether to use an explicit IF ... PUT ... If that's not what it's about, I don't know _what_ rav's point is. >---If we bring a preprocesor into it, we can do things like: > assert ("x > b", "the value of x is out of range" ); Yes, indeed. > The relevant macro would be something like: > assert: procedure (test, message); > answer ('if ' || test || ' then put (' || message || ')' ); > end assert; >That's 3 lines, I think. Agreed, except that it doesn't do the same thing. To do the same thing it would have to be something like % assert: %procedure (test, message); answer ('if ' || test || ' then do ' || 'put (' || message || ');' || 'signal whatever_you_want;' || 'end'); %end assert; There is a huge difference in _use_ between "maybe print a message" and "trap if condition false" method, however implemented. In any case, so what? ONE PROGRAMMER IN A COMPANY WRITES IT ONCE. I would not count it as a strike against PL/I if it took 50 lines, it would still be a good thing to do. -- Fifty years of programming language research, and we end up with C++ ??? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` Richard A. O'Keefe @ 1996-06-13 0:00 ` ++ robin 1996-06-13 0:00 ` ++ robin 1 sibling, 0 replies; 93+ messages in thread From: ++ robin @ 1996-06-13 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: >rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >If I were using PL/I, I would certainly write an Assert procedure and >use it. As far as that is concerned, there is little to choose between >PL/I and Ada. As far as I can see, the debate is about whether to use >a library function, or whether to use an explicit IF ... PUT ... >If that's not what it's about, I don't know _what_ rav's point is. >>---If we bring a preprocesor into it, we can do things like: >> assert ("x > b", "the value of x is out of range" ); >Yes, indeed. >> The relevant macro would be something like: >> assert: procedure (test, message); >> answer ('if ' || test || ' then put (' || message || ')' ); >> end assert; >>That's 3 lines, I think. >Agreed, except that it doesn't do the same thing. ---same as what? I never claimed it to be the same as anything. Do read what's written -- ". . . we can do things like". > To do the same thing ---as what? (see above) >it would have to be something like > % assert: %procedure (test, message); > answer ('if ' || test || ' then do ' || > 'put (' || message || ');' || > 'signal whatever_you_want;' || > 'end'); > %end assert; ---Well, definitely not! Your example does NOT do the same thing as mine. You've included additional functionality that is not in my example. BTW, you left out the %activate statement. The SIGNAL statement is SIGNAL CONDITION (whatever_you_want);, the PROCEDURE keyword does not have a % prefix, and the DO statement requires a semicolon. The point of the example, is that a PL/I programmer can do it in a few lines. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-12 0:00 ` Richard A. O'Keefe 1996-06-13 0:00 ` ++ robin @ 1996-06-13 0:00 ` ++ robin 1 sibling, 0 replies; 93+ messages in thread From: ++ robin @ 1996-06-13 0:00 UTC (permalink / raw) ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: >rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >> > -- assume an external >> > -- function Assertion(Condition: Boolean) return Boolean is >> > -- begin >> > -- if not Condition then >> > -- raise Assertion_Violation; >> > -- end if; >> > -- return Condition; >> > -- end Assertion; >> > procedure P(X: Natural) is >> > Precondition: constant Boolean := Assertion( >> > X mod 2 = 0 >> > ); >> > ... >>---Why have 2 lines when 11 will suffice? >"--" introduces a comment. ---I think most people know that. > The function Assertion is already in a >library package (of mine). I don't write it over and over again. ---Yes, but you had to write it. The oppoint is, it's overkill. > [nonsense deleted> >>---The example was an illustration. It wasn't a literal >>translation of yours. It wasn't intended to make sense. >If it _wasn't_ a translation of mine, what was the point of it? >How can you claim that it is easier or better or whatever than the >code I showed, unless it accomplishes the same end? >In fact, your slip ---FYI, it wasn't a slip. >>The original said "something .. like", right? > [nonsense deleted] >> > In C, for example, assert() >> > raises the SIGABRT exception, which may (but need not) be handled >> > by the program itself. >>---Which is the example I originally gave above, for PL/I. >No, the example you original gave was a PUT statement inside an IF. ---The example -- which you deleted from your reply -- was: >>If it's important that the whereabouts of this test be known, >>the programmer can include a statement such as "signal error;" >>or "signal condition (xyz);" or "put (' at line ', sourceline );" >>along with the put statement. [PL/I example] ---Spot on, no? > [nonsense deleted] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann ` (2 preceding siblings ...) [not found] ` <4p60nk$imd@euas20.eua.ericsson.se> @ 1996-06-12 0:00 ` Jon S Anthony 1996-06-14 0:00 ` Jon S Anthony ` (2 subsequent siblings) 6 siblings, 0 replies; 93+ messages in thread From: Jon S Anthony @ 1996-06-12 0:00 UTC (permalink / raw) In article <4pljv3$oqp@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: [In response to Richard A. O'Keefe] Gobs and gobs of rubish about why assertions are not "as good as" silly print statements in bodies of code. You should just give this up. Do you have any idea how stupid this makes you look??? /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann ` (3 preceding siblings ...) 1996-06-12 0:00 ` Jon S Anthony @ 1996-06-14 0:00 ` Jon S Anthony 1996-06-15 0:00 ` Jon S Anthony 1996-06-18 0:00 ` Jon S Anthony 6 siblings, 0 replies; 93+ messages in thread From: Jon S Anthony @ 1996-06-14 0:00 UTC (permalink / raw) In article <4prafa$o6p@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes: > http://www.cs.rmit.edu.au/~rav/ > takes to you rav's home page, which will tell you that he is > a Senior Lecturer. (Me, I'm only a Lecturer.) He has recently > published two books. He is our local PL/I expert. GREAT MAKER!! This guy has access to _students_??!?! One can only hope they see his bunk for what it is and emerge relatively unscathed... /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann ` (4 preceding siblings ...) 1996-06-14 0:00 ` Jon S Anthony @ 1996-06-15 0:00 ` Jon S Anthony 1996-06-18 0:00 ` Adam Beneschan 1996-06-18 0:00 ` Jon S Anthony 6 siblings, 1 reply; 93+ messages in thread From: Jon S Anthony @ 1996-06-15 0:00 UTC (permalink / raw) In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > A. Grant said > > "The point of assertions is not to print messages for the > programmer. You can use them to allow the compiler to > optimise safely, provide a contractual interface between > modules, and for preconditions, postconditions, loop invariants > etc. when proving the correctness of programs." > > Actually that is a very controversial statement. What most people want is > non-intrusive assertions that do NOT affect the generated code. That's > not 100% possible, but it is something you can aim at. > > It is certainly true that assertions can be used for compiler optimization, > but that's not what people want. That may be what _some_ people don't want. For reasons that would seem to be beyond the ken of mere mortals. But I would certainly hope that an Eiffel compiler, for example, would use the assertions specified by a programmer to (among other things) get rid of extraneous and useless code whenever it could deduce such cases from the assertions. What's the point of generating code for something that you _know_ won't be needed? that you _know_ will do _nothing_ but a) slow down execution speed and b) increase size of code? If these people like that sort of thing, how about just telling them to use the nooptimize pragma or switch? Then they can get all the useless code they want. > When we discussed putting pragma Assert into the language (i.e. into the > standard), it was this point that tripped us up, and resulted in it being > left out. We could not figure out how to formally define the notion that > the compiler should NOT be allowed to use the assertion for optimization > purpoes. This is _almost_ as wog-boggling as the goof-up of not directly supporting specification of mutually recursive types across packages. Really. It is incomprehensible. I suppose these people don't want _any_ optimizations? No? Well, how do they justify all that "intrusive" code movement and elmination that happens with "standard/traditional" optimization? What about ranges? They can be seen in various contexts as just being a limited form of assertion. And those are taken advantage of all the time for "intrusive" optimizations. I suppose they positively have paroxysms over this. Or, how about telling these people to _NOT_ use pragma assert if they are so wigged out about possibly useful optimizations? It's not like they are in any better shape now given the way things turned out. And the rest of us could be taking advantage of this without resorting to _NON_standard pragma Assert in GNAT. Or will this actually just become the defacto standard because it so obviously makes sense? Does the Intermetrics frontend implement Assert as defined in GNAT? Actually, the more I think about it, I believe this may be _more_ incomprehensible than the recursive type bungle after all. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-15 0:00 ` Jon S Anthony @ 1996-06-18 0:00 ` Adam Beneschan 0 siblings, 0 replies; 93+ messages in thread From: Adam Beneschan @ 1996-06-18 0:00 UTC (permalink / raw) jsa@organon.com (Jon S Anthony) writes: >In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > >> A. Grant said >> >> "The point of assertions is not to print messages for the >> programmer. You can use them to allow the compiler to >> optimise safely, provide a contractual interface between >> modules, and for preconditions, postconditions, loop invariants >> etc. when proving the correctness of programs." >> >> Actually that is a very controversial statement. What most people want is >> non-intrusive assertions that do NOT affect the generated code. That's >> not 100% possible, but it is something you can aim at. >> >> It is certainly true that assertions can be used for compiler optimization, >> but that's not what people want. > >That may be what _some_ people don't want. For reasons that would >seem to be beyond the ken of mere mortals. But I would certainly hope >that an Eiffel compiler, for example, would use the assertions >specified by a programmer to (among other things) get rid of >extraneous and useless code whenever it could deduce such cases from >the assertions. What's the point of generating code for something >that you _know_ won't be needed? that you _know_ will do _nothing_ >but a) slow down execution speed and b) increase size of code? If >these people like that sort of thing, how about just telling them to >use the nooptimize pragma or switch? Then they can get all the >useless code they want. > > >> When we discussed putting pragma Assert into the language (i.e. into the >> standard), it was this point that tripped us up, and resulted in it being >> left out. We could not figure out how to formally define the notion that >> the compiler should NOT be allowed to use the assertion for optimization >> purpoes. > >This is _almost_ as wog-boggling as the goof-up of not directly >supporting specification of mutually recursive types across packages. > >Really. It is incomprehensible. I suppose these people don't want >_any_ optimizations? No? Well, how do they justify all that >"intrusive" code movement and elmination that happens with >"standard/traditional" optimization? What about ranges? They can be >seen in various contexts as just being a limited form of assertion. >And those are taken advantage of all the time for "intrusive" >optimizations. I suppose they positively have paroxysms over this. I have to agree with Jon's point here. I don't see any reason why the definition of the language would have to prevent the compiler from using the information for optimization. If the customer didn't want that to happen, the vendor could add a command-line option or pragma to tell the compiler not to. Don't Ada compilers already have command-line options and/or pragmas to control how much optimization takes place, anyway? -- Adam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann ` (5 preceding siblings ...) 1996-06-15 0:00 ` Jon S Anthony @ 1996-06-18 0:00 ` Jon S Anthony 1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier 6 siblings, 1 reply; 93+ messages in thread From: Jon S Anthony @ 1996-06-18 0:00 UTC (permalink / raw) In article <ag129.532.0011DA32@ucs.cam.ac.uk> ag129@ucs.cam.ac.uk (A. Grant) writes: > In article <dewar.834584250@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: > >A. Grant said > >"The point of assertions is not to print messages for the > >programmer. You can use them to allow the compiler to > >optimise safely..." > > >It is certainly true that assertions can be used for compiler optimization, > >but that's not what people want. > > What people want is for the compiler to do all the work, i.e. prove > that all array subscripts are valid, that all dereferenced pointers I basically agree with you here. Well, more or less. Well, you know, they probably would like it to do everything, like: program A: Setting: The Factory Task : Construct complete CIM and TQM system end A :-) > Why don't you like assertions enabling optimisation where > the compiler can prove the correctness of the assertion, i.e. > optimise it away? Then all you are doing is giving a hint to > the compiler about an optimisation strategy, without altering > the meaning of the program at all. I don't believe that Robert said the _he_ wouldn't like assertions allowed to do this, but that certain "other people" didn't. I find this incomprehensible also. And since GNAT (GNU Ada, which Robert had a significant hand in) has pragma Assert it would appear he agrees - at least at some level! :-) /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (an heretic view) 1996-06-18 0:00 ` Jon S Anthony @ 1996-06-28 0:00 ` Michel Gauthier 1996-06-28 0:00 ` Robert A Duff 1996-06-28 0:00 ` Robert Dewar 0 siblings, 2 replies; 93+ messages in thread From: Michel Gauthier @ 1996-06-28 0:00 UTC (permalink / raw) Many people recently wrote about assertions. I am not really convinced by the general spirit of the debate. I guess there is a harmful confusion somewhere. Do not read any more if you think the contrary. IMHO, it is _essential_ to distinguish : - _failures_ : some piece of program does not do what it has been designed to do, in an intrinsicly impossible case, - _programming errors_ : the programmer did not do what the specification required, including failure cases. Underflowing a stack is (almost always) an error, whereas overflowing a stack depends on the data and on the environment of each execution, hence is a failure. Failures can _always_ be foreseen, and suitable programming can handle them if appropriate, with exceptions or with any other means. Errors can _never_ be foreseen. Coming back to assertions, I guess that they essentially relate to errors, which they can help detecting. It seems to be a good style not to combine assertions with failures. Moreover, I can't agree with the idea that failing an assertion check would always result in raising Assert_Error. Failing an assertion check is an effect of some -possibly incompletely identified- programming error. Different possible continuations can be envisaged : raising a well-specified exception associated with the case, doing some appropriate thing (tracing,...), raising some user-defined exception, invoking the debugger, and possibly others, among which continuing until other failing checks. This choice depends on the current status of the project, on the nature of the checked assertion, on reuse or not, etc. In some cases, it may depend also on execution options. From another point of view, assertion-handling components should be replaceable by others without any other on the program effect than early abortion (whether compared with normal end or with abortion). Do-nothing must be one of the possible assertion-handling components, to be used for the final program. This is the spirit of the assertion mechanism that I have coded for my students (I had some remaining problems with initialisation of package instances, which seem to be fixed with gnat 3.05). ---------- ---------- ---------- ---------- Michel Gauthier / Laboratoire d'informatique 123 avenue Albert Thomas / F-87060 Limoges telephone +33 () 55457335 [or ~ 7232] fax +33 () 55457315 [or ~7201] ---------- ---------- ---------- ---------- La grande equation de la fin du siecle : windows-X = Mac-Y The main end-of-century equation : windows-X = Mac-Y ---------- ---------- ---------- ---------- Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9 If you feel year 2000 a stupid mystic craze, use numeration base 9 ---------- ---------- ---------- ---------- ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (an heretic view) 1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier @ 1996-06-28 0:00 ` Robert A Duff 1996-06-28 0:00 ` Robert Dewar 1 sibling, 0 replies; 93+ messages in thread From: Robert A Duff @ 1996-06-28 0:00 UTC (permalink / raw) In article <gauthier-2806961227410001@164.81.60.62>, Michel Gauthier <gauthier@unilim.fr> wrote: >IMHO, it is _essential_ to distinguish : > - _failures_ : some piece of program does not do what it has been designed > to do, in an intrinsicly impossible case, > - _programming errors_ : the programmer did not do what the specification > required, including failure cases. A perfectly reasonable distinction. However, you cannot, in general, tell whether it's a "failure" or a "programming error" at the point where the problem is detected. This is the whole point of exceptions: one piece of code can detect the problem, and another piece of code, possibly far away, can decide whether it is a "failure" or not, and if so, what to do about it. (And, of course, the *usual* thing to do with an exception is to treat it as a programming error, and simply let it kill the program or go into the debugger or whatever.) >Underflowing a stack is (almost always) an error, whereas overflowing a >stack depends on the data and on the environment of each execution, hence >is a failure. > >Failures can _always_ be foreseen, and suitable programming can handle >them if appropriate, with exceptions or with any other means. > >Errors can _never_ be foreseen. > >Coming back to assertions, I guess that they essentially relate to errors, >which they can help detecting. It seems to be a good style not to combine >assertions with failures. I disagree, for the above reasons. If you have a stack overflow, it might be a "failure", and it might make sense to recover from it. On the other hand, I might calculate the maximum stack size, so that my algorithm is guaranteed not to overflow the stack -- in this case, the only way the stack can overflow is if I have a programming error. And the code for Stacks.Push can't tell which is which. Only the *caller* of Stacks.Push can know. >Moreover, I can't agree with the idea that failing an assertion check would >always result in raising Assert_Error. Failing an assertion check is an effect >of some -possibly incompletely identified- programming error. Different >possible continuations can be envisaged : raising a well-specified >exception associated with the case, doing some appropriate thing >(tracing,...), raising some user-defined exception, invoking the debugger, >and possibly others, among which continuing until other failing checks. > This choice depends on the current status of the project, on the >nature of the checked assertion, on reuse or not, etc. In some cases, >it may depend also on execution options. Right. But "raising an exception" covers all these cases. Any decent implementation will let you go into the debugger in case of an unhandled exception, for example. Anyway, you have no choice -- the language Standard doesn't define an Enter_Debugger primitive. - Bob ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Assertions (an heretic view) 1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier 1996-06-28 0:00 ` Robert A Duff @ 1996-06-28 0:00 ` Robert Dewar 1 sibling, 0 replies; 93+ messages in thread From: Robert Dewar @ 1996-06-28 0:00 UTC (permalink / raw) One thing for sure, this discussion on assertions certainly nicely indicates the problem. People have very different ideas of what assertions should be, and this kind of divergence does not make it easy to agree on a single language feature. Some people argue for multiple language features to respond to the confusion, but that of course is also a controversial position. Anyway, readers of this thread should now have a better appreciation of why the apparently simple and obvious feature did not make it into the official language. My own taste would have been to define a simple feature similar to that implemented in GNAT, but as you see from the discussion, there is no consensus that this is the "right" approach, and the discussion in WG9 was quite similar to that in this thread. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) [not found] <4p0fdd$4ml@news.atlantic.net> 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann @ 1996-06-06 0:00 ` Dale Pontius 1996-06-11 0:00 ` Jon S Anthony ` (2 subsequent siblings) 4 siblings, 0 replies; 93+ messages in thread From: Dale Pontius @ 1996-06-06 0:00 UTC (permalink / raw) In article <4p37cs$efi@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > > >When I decide, as a programmer, that a peculiar type or > >variable may have a value in the range from 1 to 9, can you please > >explain me why it should be useful to assign a value of 10 or > >4711 or -1234? > >---Why, someone inevitably decides that the range is going >to be something different! Users are apt to change their minds. >Then someone has to go in and modify the program. Or, someone >overlooked a limit, and put in a limit one smaller than that >actually required. Again, someone has to go in and find where >that limit is, and change it. > You've made the assumption that the limit was arbitrary. I would expect that the limit would be put there based on the capabilities of the code. In that case, exceeding the limit of that variable is the same as exceeding the capabilities of the code, and may have unpredicted results. In that case, if the user wants to change the limits the code had better be scrubbed to make sure it can handle the new limits. Obviously the limit must have been intelligently selected in the first place. But in any case, new expectations call for reexamination of the program, not "try it and see if it breaks," because there's always the "this time" clause in there. Dale Pontius (NOT speaking for IBM) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) [not found] <4p0fdd$4ml@news.atlantic.net> 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann 1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius @ 1996-06-11 0:00 ` Jon S Anthony 1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras 1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin 4 siblings, 0 replies; 93+ messages in thread From: Jon S Anthony @ 1996-06-11 0:00 UTC (permalink / raw) In article <4pj7v8$g3c@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: > fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes: > > >johmann@moal.com (Kurt Johmann) writes: > > >>Range checking, IMO, is something that should be > >>checked by the programmer's code as needed. For example: > >> > >> assert(x > 0 && x < 10); // int x must be between 1 and 9 inclusive > >> > >>One disadvantage of doing it the Ada way (in which the allowed range is > >>declared as part of the type) is that it is inflexible and global, and > >>the range information is separated from where the variable's value is > >>actually used in the program. > > >I disagree that the Ada way is inflexible. Usually associating a range > >with a type is what you want. > > ---Is it? Typically, yes it is. > Rarely do programs stay the same. Users change > their minds, during program design and after it is complete. What does this have to do with the point??? The kind of situation being described is one most likely dealing with the internal structure of the _implementation_, not the user level requirements! Criminey! > ---Why, someone inevitably decides that the range is going > to be something different! I would hope that your "designs" of the internals of an application are not that sloppy and slipshod. Then again, looking at typical examples of programs certainly doesn't help my faith here... > Users are apt to change their minds. > Then someone has to go in and modify the program. Or, someone > overlooked a limit, and put in a limit one smaller than that > actually required. Again, someone has to go in and find where > that limit is, and change it. Again, get a clue. No one is talking about hard coding restrictions at the user level - unless, of course, those restrictions make sense from the standpoint of the user level model. Trivial example: the user level model imposes the requirement that a current ranges between 3 and 15 units (amperes, milliamps, whatever). That's the designed in range. Anything outside this range is an indication that a fault has/is occuring. Only the feckless would think it is somehow a great idea to just let any value outside this range occur in such a context. Furthermore, you can let this range be specifiable by the user for any given "run" (maybe it's a simulation): subtype Current_Range is range Get_Current_Min .. Get_Current_Max; ... Where the Get_Current* obtain values at runtime. Quick hack: with Ada.Command_Line; use Ada.Command_Line; with Text_Io; use Text_Io; procedure Junk is subtype Current_Range is Integer range Integer'Value(Argument(1))..Integer'Value(Argument(2)); begin Put_Line( "Current_Range = " & Integer'Image(Current_Range'First) & " .." & Integer'Image(Current_Range'Last) ); end; $ gnatmake junk.adb $ junk 1 4 Current_Range = 1 .. 4 $ junk 4 8 Current_Range = 4 .. 8 $ Looks to me like both the flexibility _and_ the safety. Really, if you are going to comment, at least have some idea of what you're talking about. > > But Ada also provides ways of suppressing > >range checks or of adding arbitrary assertions in a manner equivalent > >to C's assert. > > ---and I suppose it never has happened that someone forgot to > suppress a range check . . . Irrelevant. If you don't want a range then DON'T specify one. You can let it be whatever you want. The difference is that in Ada you _can_ specify a range as a definition if you know that this is correct and the language will ensure that this is enforced. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: Help making ada pretty [not found] <4p0fdd$4ml@news.atlantic.net> ` (2 preceding siblings ...) 1996-06-11 0:00 ` Jon S Anthony @ 1996-06-12 0:00 ` Pedro de las Heras 1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin 4 siblings, 0 replies; 93+ messages in thread From: Pedro de las Heras @ 1996-06-12 0:00 UTC (permalink / raw) In article <31BE430F.52F8@adam.com.au> CSC Trusted Systems Group <csctsg@adam.com.au> writes: Hi, I am looking for any tools around to print ada-code in a more presentable form, ie keywords bolded etc. apparently they sometimes go by the name "pretty printers", however I do not want to rejustify the code in any way, I only require the bolding type features. Also am looking for any latex tools for typesetting ada. as I rarely have time to read mews replies to csctsg@adam.com.au would greatly be appreciated Hello. Check ftp://ordago.gsyc.inf.uc3m.es/pub/literate/ape4noweb.tgz It is a modification of APE (A pretty printer for Ada) made by Paco Ballesteros (nemo), a colleague of mine. It does not rejustify and it produces LaTeX marks. Regards, ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: next "big" language?? (disagree) [not found] <4p0fdd$4ml@news.atlantic.net> ` (3 preceding siblings ...) 1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras @ 1996-06-18 0:00 ` ++ robin 4 siblings, 0 replies; 93+ messages in thread From: ++ robin @ 1996-06-18 0:00 UTC (permalink / raw) jsa@organon.com (Jon S Anthony) writes: >In article <4pqsed$a4v@goanna.cs.rmit.EDU.AU> rav@goanna.cs.rmit.EDU.AU (++ robin) writes: >> >No you are wrong. Ranges and assertions will let the compiler >> >eliminate these checks. That is exactly what you wanted. You don't >> >have a clue. Why are you posting on this topic when you clearly don't >> >understand any of the principals?? >> >> ---Having a range allows the compiler to produce code >> to check that the value of the variable concerned >> lies within that range. Whenever that variable >> is assigned a value (including via an input), the >> check is performed. >> >> Sorry you embarrassed yourself again with this and other >> wrong assertions (no pun intended). >No, you did. Again. But you appear not to care. The compiler can >use ranges at COMPILE TIME to check that bounds are not violated AT >COMPILE TIME so that it does not need to produce code to check the >variable AT RUNTIME. It can't do this in every case, but in very many >cases it can. ---That's what I already said a couple of posts ago: >> "You can write >> a = b - c; or the equivalent do/end. In either case, >> the checks are done by the compiler and/or the object code." But Jon, you are contradicting yourself, because you then replied that the checks are not needed: "No. Try reading what was said. The _elimination_ of the checks comes from the assertions or ranges which are in the language and from which the compiler can deduce that the checks are not needed. Subscripting is basically always eliminated." >Jon Anthony >Organon Motives, Inc. >1 Williston Road, Suite 4 >Belmont, MA 02178 ^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~1996-07-01 0:00 UTC | newest] Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4p0fdd$4ml@news.atlantic.net> 1996-06-04 0:00 ` next "big" language?? (disagree) Peter Hermann 1996-06-04 0:00 ` The Amorphous Mass 1996-06-04 0:00 ` Peter Hermann 1996-06-04 0:00 ` The Amorphous Mass 1996-06-05 0:00 ` Michael David WINIKOFF 1996-06-07 0:00 ` Robert Dewar 1996-06-04 0:00 ` Robert Dewar 1996-06-06 0:00 ` Ken Garlington 1996-06-12 0:00 ` Help making ada pretty CSC Trusted Systems Group 1996-06-14 0:00 ` Sandy McPherson 1996-06-19 0:00 ` Ruediger Berlich 1996-06-05 0:00 ` next "big" language?? (disagree) Ian Ward 1996-06-05 0:00 ` The Amorphous Mass 1996-06-08 0:00 ` Robert Dewar 1996-06-08 0:00 ` The Amorphous Mass 1996-06-09 0:00 ` Robert Dewar 1996-06-08 0:00 ` Robert Dewar 1996-06-05 0:00 ` ++ robin 1996-06-05 0:00 ` Ian Ward 1996-06-05 0:00 ` Ian Ward 1996-06-06 0:00 ` Richard Riehle 1996-06-07 0:00 ` Richard Riehle 1996-06-08 0:00 ` O'Connor 1996-06-07 0:00 ` Robert Dewar 1996-06-10 0:00 ` Richard Riehle 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` James_Rogers 1996-06-11 0:00 ` Kevin J. Weise 1996-06-11 0:00 ` Chris Warack <sys mgr> 1996-06-11 0:00 ` David Weller 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` Ian Ward 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` Ian Ward 1996-06-11 0:00 ` Jon S Anthony [not found] ` <4p60nk$imd@euas20.eua.ericsson.se> [not found] ` <4p8lmq$oq7@goanna.cs.rmit.edu.au> 1996-06-11 0:00 ` ++ robin 1996-06-11 0:00 ` A. Grant 1996-06-12 0:00 ` Robert Dewar 1996-06-17 0:00 ` A. Grant 1996-06-18 0:00 ` Robert Dewar 1996-06-24 0:00 ` Robert I. Eachus 1996-06-26 0:00 ` Norman H. Cohen 1996-06-19 0:00 ` Jon S Anthony 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Dale Stanbrough 1996-06-24 0:00 ` hopkinc 1996-06-24 0:00 ` Lars Duening 1996-06-24 0:00 ` Adam Beneschan 1996-06-24 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert A Duff 1996-06-24 0:00 ` Robert Dewar 1996-06-25 0:00 ` Robert A Duff 1996-06-28 0:00 ` Robert Dewar 1996-06-24 0:00 ` Assertions (a different intent?) Gary McKee [not found] ` <4qrljg$15l8@watnews1.watson.ibm.com> 1996-06-28 0:00 ` Assertions (was: Re: next "big" language?? (disagree)) Robert Dewar 1996-06-24 0:00 ` next "big" language?? (disagree) Robert Dewar 1996-06-26 0:00 ` Marc C. Brooks 1996-06-26 0:00 ` Marc C. Brooks [not found] ` <4qsbm7$r1s@Starbase.NeoSoft.COM> 1996-06-28 0:00 ` "Assert"? "Assume"? (was: next "big" language?? (disagree)) Alexander Bunkenburg 1996-06-28 0:00 ` Ian Collier 1996-07-01 0:00 ` Cameron Laird 1996-06-24 0:00 ` next "big" language?? (disagree) Keith Thompson 1996-06-25 0:00 ` Robert A Duff 1996-06-25 0:00 ` Simon Read 1996-06-24 0:00 ` Adam Beneschan 1996-06-25 0:00 ` Darin Johnson 1996-06-26 0:00 ` A. Grant 1996-06-26 0:00 ` Dale Stanbrough 1996-06-25 0:00 ` Brian Nettleton @pulsar 1996-06-26 0:00 ` Robert Dewar 1996-06-28 0:00 ` Fergus Henderson 1996-06-28 0:00 ` Robert Dewar 1996-06-30 0:00 ` Fergus Henderson 1996-06-30 0:00 ` Robert Dewar 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` A. Grant 1996-06-14 0:00 ` Richard A. O'Keefe 1996-06-12 0:00 ` Richard A. O'Keefe 1996-06-12 0:00 ` ++ robin 1996-06-12 0:00 ` Richard A. O'Keefe 1996-06-13 0:00 ` ++ robin 1996-06-13 0:00 ` ++ robin 1996-06-12 0:00 ` Jon S Anthony 1996-06-14 0:00 ` Jon S Anthony 1996-06-15 0:00 ` Jon S Anthony 1996-06-18 0:00 ` Adam Beneschan 1996-06-18 0:00 ` Jon S Anthony 1996-06-28 0:00 ` Assertions (an heretic view) Michel Gauthier 1996-06-28 0:00 ` Robert A Duff 1996-06-28 0:00 ` Robert Dewar 1996-06-06 0:00 ` next "big" language?? (disagree) Dale Pontius 1996-06-11 0:00 ` Jon S Anthony 1996-06-12 0:00 ` Help making ada pretty Pedro de las Heras 1996-06-18 0:00 ` next "big" language?? (disagree) ++ robin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox