Re: next "big" language?? (disagree)

Re: next "big" language?? (disagree)

[Peter Hermann]

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)

Re: next "big" language?? (disagree)

[The Amorphous Mass]

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

Re: next "big" language?? (disagree)

[Robert Dewar]

"  _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

Re: next "big" language?? (disagree)

[Ken Garlington]

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"

Help making ada pretty

[CSC Trusted Systems Group]

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

Re: Help making ada pretty

[Sandy McPherson]

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

Re: Help making ada pretty

[Ruediger Berlich]

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]

Re: next "big" language?? (disagree)

[Peter Hermann]

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)

Re: next "big" language?? (disagree)

[The Amorphous Mass]

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**/

Re: next "big" language?? (disagree)

[Michael David WINIKOFF]

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?

Re: next "big" language?? (disagree)

[Robert Dewar]

">  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.

Re: next "big" language?? (disagree)

[Ian Ward]

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.

Re: next "big" language?? (disagree)

[The Amorphous Mass]

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          */

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[The Amorphous Mass]

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

Re: next "big" language?? (disagree)

[Robert Dewar]

"  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!

Re: next "big" language?? (disagree)

[++ robin]

	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.

Re: next "big" language?? (disagree)

[Ian Ward]

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.

Re: next "big" language?? (disagree)

[Ian Ward]

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.

Re: next "big" language?? (disagree)

[Richard Riehle]

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

Re: next "big" language?? (disagree)

[Richard Riehle]

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

Re: next "big" language?? (disagree)

[O'Connor]

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
    ##
   ##
  ##
 ##

Re: next "big" language?? (disagree)

[Robert Dewar]

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);

Re: next "big" language?? (disagree)

[Richard Riehle]

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

Re: next "big" language?? (disagree)

[++ robin]

	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?

Re: next "big" language?? (disagree)

[David Weller]

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

Re: next "big" language?? (disagree)

[Chris Warack <sys mgr>]

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.

Re: next "big" language?? (disagree)

[James_Rogers]

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.

Re: next "big" language?? (disagree)

[Kevin J. Weise]

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

Re: next "big" language?? (disagree)

[++ robin]

	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.

Re: next "big" language?? (disagree)

[Ian Ward]

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

Re: next "big" language?? (disagree)

[++ robin]

	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."

Re: next "big" language?? (disagree)

[Ian Ward]

> 	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.

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: next "big" language?? (disagree)

[++ robin]

	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]

Re: next "big" language?? (disagree)

[A. Grant]

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.  

Re: next "big" language?? (disagree)

[Robert Dewar]

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).

Re: next "big" language?? (disagree)

[A. Grant]

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.

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Robert I. Eachus]

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...

Re: next "big" language?? (disagree)

[Norman H. Cohen]

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

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: next "big" language?? (disagree)

[Robert Dewar]

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!).

Re: next "big" language?? (disagree)

[Adam Beneschan]

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

Re: next "big" language?? (disagree)

[Dale Stanbrough]

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

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Adam Beneschan]

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

Assertions (was: Re: next "big" language?? (disagree))

[Robert A Duff]

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

Re: Assertions (was: Re: next "big" language?? (disagree))

[Robert Dewar]

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.

Re: Assertions (was: Re: next "big" language?? (disagree))

[Robert A Duff]

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

Re: Assertions (was: Re: next "big" language?? (disagree))

[Robert Dewar]

"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!

Re: Assertions (a different intent?)

[Gary McKee]

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.

Re: Assertions (was: Re: next "big" language?? (disagree))

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Lars Duening]

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

Re: next "big" language?? (disagree)

[hopkinc]

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 ;-) 

Re: next "big" language?? (disagree)

[Marc C. Brooks]

> 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

Re: next "big" language?? (disagree)

[Marc C. Brooks]

> 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

Re: "Assert"? "Assume"? (was: next "big" language?? (disagree))

[Alexander Bunkenburg]

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

Re: "Assert"? "Assume"? (was: next "big" language?? (disagree))

[Ian Collier]

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

Re: "Assert"? "Assume"? (was: next "big" language?? (disagree))

[Cameron Laird]

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

Re: next "big" language?? (disagree)

[Keith Thompson]

[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

Re: next "big" language?? (disagree)

[Robert A Duff]

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

Re: next "big" language?? (disagree)

[Simon Read]

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

Re: next "big" language?? (disagree)

[Brian Nettleton @pulsar]

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

Re: next "big" language?? (disagree)

[Robert Dewar]

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 :-)

Re: next "big" language?? (disagree)

[Fergus Henderson]

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.

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Fergus Henderson]

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.

Re: next "big" language?? (disagree)

[Robert Dewar]

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.

Re: next "big" language?? (disagree)

[Darin Johnson]

>  >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...

Re: next "big" language?? (disagree)

[Dale Stanbrough]

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

Re: next "big" language?? (disagree)

[A. Grant]

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.

Re: next "big" language?? (disagree)

[++ robin]

	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.

Re: next "big" language?? (disagree)

[A. Grant]

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?

Re: next "big" language?? (disagree)

[Richard A. O'Keefe]

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.

Re: next "big" language?? (disagree)

[Richard A. O'Keefe]

>	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.

Re: next "big" language?? (disagree)

[++ robin]

	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.

Re: next "big" language?? (disagree)

[Richard A. O'Keefe]

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.

Re: next "big" language?? (disagree)

[++ robin]

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]

Re: next "big" language?? (disagree)

[++ robin]

	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.

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: next "big" language?? (disagree)

[Adam Beneschan]

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

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: Assertions (an heretic view)

[Michel Gauthier]

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
----------          ----------          ----------          ----------

Re: Assertions (an heretic view)

[Robert Dewar]

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.

Re: Assertions (an heretic view)

[Robert A Duff]

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

Re: next "big" language?? (disagree)

[Dale Pontius]

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)

Re: next "big" language?? (disagree)

[Jon S Anthony]

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

Re: Help making ada pretty

[Pedro de las Heras]

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,

Re: next "big" language?? (disagree)

[++ robin]

        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

Re: next "big" language?? (disagree)

[Ian Ward]

On June the ?sixth?, James Robinson wrote :

> On 5 Jun 1996, Ian Ward wrote:

> > On June the Fourth, 1996, James Robinson (The Amorphous Mass) wrote

snip....

> > 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. :-)

Of course, the time taken for the compiler to spot syntactic errors 
is much less than that which a person takes. In fact, if the langauge
syntax is cunningly enough design such that different constructs look
sufficiently different, it will also wipe out a large proportion of 
unwitting semantic (&functional) errors as well. This feature more 
than makes up for compile times, which is one of the reasons languages
such as the Pascal family is twice as quick in terms of man hours to
get down to any arbitrary level of bugs. (It stands to reason, if one
does not have to worry about the syntax, one has more time to work
on the semantics.)


> [re: "reusable code modules"]
> > >   They're also one of the great dangers of the future.  I keep a fairly 

snip...

> >  I'm thus wary of the idea of "code reuse." Not dismissive, just wary.

snip...

>   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.

Concur. Like Mother, like Daughter.

> > 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?

Yes, I was miles off track with what I thought you were talking about. It
is at this point that I have to concur with what you are saying, there are
two different types of software reuse.

1. Reusing software, to do the same job for which it was designed.

	- Such as I/O utilities, this usually works well,
          provided the interfaces are well defined.

2. Trying to reuse software for different purpose than it was originally
defined.
	- This can be tragic, if one has no ability to examine the works,
	  then one has no idea what side effects may present themselves;
	  in the worst cases of this it may be better to write one's own.

	- If, of course, one has the sources, it may better to modify
	  them to suit one's own needs, after all, they were not designed
	  to do the job for which they will be used, disk space is cheap,
	  and one will have at the end two pieces of software which gives
	  a better chance in the future that when a component is needed,
	  then there will be a closer match, in a library, somewhere. 
		It is at this point, modification, where code readability
	  comes into its own, trying to modify write only languages can be
	  an exercise in frustration to say the least. Of course, programmer
	  time is the least expensive component of software engineering....
	  or did I dream it?

>  --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          */

Best regards, 
Ian.

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be
It's "burgled" Mr. President, not burglarised.

Re: next "big" language?? (disagree)

[O'Connor]

Ian Ward wrote:
> 
> Of course, the time taken for the compiler to spot syntactic errors
> is much less than that which a person takes. In fact, if the langauge
> syntax is cunningly enough design such that different constructs look
> sufficiently different, it will also wipe out a large proportion of
> unwitting semantic (&functional) errors as well. This feature more
> than makes up for compile times, which is one of the reasons languages
> such as the Pascal family is twice as quick in terms of man hours to
> get down to any arbitrary level of bugs. (It stands to reason, if one
> does not have to worry about the syntax, one has more time to work
> on the semantics.)
> 
> Best regards,
> Ian.

This is precisely why I enjoy Smalltalk so much.  With very few 
syntactical rules to worry about, whether I'm writing code or reading 
someone elses, I can concentrate more on the intent of the code.  "What 
needs to be accomplished" rather than "What language rules do I have to 
remember for this situation".
 
James O'Connor
oconnor@apci.net


          ##
         ##
  ########	 "He that loveth not
 ########		 knoweth not God."
     ##			--1 John 4:8
    ##
   ##
  ##
 ##

Re: next "big" language?? (disagree)

[Matt Kennel]

O'Connor (oconnor@apci.net) wrote:
: Ian Ward wrote:
: > 
: > Of course, the time taken for the compiler to spot syntactic errors
: > is much less than that which a person takes. In fact, if the langauge
: > syntax is cunningly enough design such that different constructs look
: > sufficiently different, it will also wipe out a large proportion of
: > unwitting semantic (&functional) errors as well. This feature more
: > than makes up for compile times, which is one of the reasons languages
: > such as the Pascal family is twice as quick in terms of man hours to
: > get down to any arbitrary level of bugs. (It stands to reason, if one
: > does not have to worry about the syntax, one has more time to work
: > on the semantics.)
: > 
: > Best regards,
: > Ian.

: This is precisely why I enjoy Smalltalk so much.  With very few 
: syntactical rules to worry about, whether I'm writing code or reading 
: someone elses, I can concentrate more on the intent of the code.  "What 
: needs to be accomplished" rather than "What language rules do I have to 
: remember for this situation".

And by doing so turns what would otherwise be superficial syntactic or
linguistic errors into programs with run-time bugs. 

``Youse pays yer money and youse takes yer choice.''

That is a complaint have re C++:  nightmare programs from hell are dense
in the space of dream programs.
  
: James O'Connor
: oconnor@apci.net


:           ##
:          ##
:   ########	 "He that loveth not
:  ########		 knoweth not God."
:      ##			--1 John 4:8
:     ##
:    ##
:   ##
:  ##

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility.

Re: next "big" language?? (disagree)

[Robb Nebbe]

I believe it was Von Neuman who said: "If you don't know what you are
talking about then there is no reason for precision."

I suppose you could apply this to programming and say that if you don't
know why your code works then there is no reason for precision. Things
like types as well as pre- and postconditions are just extra work; aren't
they? ;-|

Matt Kennel wrote:
> 
> O'Connor (oconnor@apci.net) wrote:
> 
> : This is precisely why I enjoy Smalltalk so much.  With very few
> : syntactical rules to worry about, whether I'm writing code or reading
> : someone elses, I can concentrate more on the intent of the code.  "What
> : needs to be accomplished" rather than "What language rules do I have to
> : remember for this situation".
> 
> And by doing so turns what would otherwise be superficial syntactic or
> linguistic errors into programs with run-time bugs.

Re: next "big" language?? (disagree)

[Ian Ward]

In reply to my earlier statements along the lines of having the 
compiler hammer out the syntax checking ...

James O'Connor wrote :

: This is precisely why I enjoy Smalltalk so much.  With very few 
: syntactical rules to worry about, whether I'm writing code or reading 
: someone elses, I can concentrate more on the intent of the code.  "What 
: needs to be accomplished" rather than "What language rules do I have to 
: remember for this situation".

Firstly, I didn't say there were no syntax rules to Ada, there
are, and they are there for the reason that they help eradicate
errors in program production, (note that James O'Connor hasn't 
specifically stated this about Smalltalk either but as I only
have a finite time to learn languages I am not qualified to 
make a guess what he meant by it.)

Which then brings me to Mathew B. Kennel's retort 

> And by doing so turns what would otherwise be superficial syntactic or
> linguistic errors into programs with run-time bugs. 

If he is talking about Ada here, then I think his argument is flawed
because it, in my opinion, assumes that the rate of errors per SLOC
a programmer makes is independent of language.

I don't think that for every syntax error a programmer spots in
his code as a result of a compiler listing, another semantic error
is created instead, (or is even present.)

It is more likely that a given programmer generally has N syntax
errors/1000SLOC and M semantic errors/1000SLOC (where M and N
vary on the ability of the programmer, his interest in his work,
and the difficulty of it.)

In this situation, a good compiler, will point out his N syntax errors,
which he will correct. In the process of correcting these, it is
also likely that he will spot a few of the semantic errors.
This would then leave < M semantic errors for the programmer to
track down at run-time.

All the language would then need is some kind of run time checking
to help him out.

---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be

Re: next "big" language?? (disagree)

[Norman H. Cohen]

In article <4pjl57$cn0@btmpjg.god.bel.alcatel.be>, ian@rsd.bel.alcatel.be
(Ian Ward) writes:

|> Which then brings me to Mathew B. Kennel's retort
|>
|> > And by doing so turns what would otherwise be superficial syntactic or
|> > linguistic errors into programs with run-time bugs.
|>
|> If he is talking about Ada here, then I think his argument is flawed
|> because it, in my opinion, assumes that the rate of errors per SLOC
|> a programmer makes is independent of language.
|>
|> I don't think that for every syntax error a programmer spots in
|> his code as a result of a compiler listing, another semantic error
|> is created instead, (or is even present.)
|>
|> It is more likely that a given programmer generally has N syntax
|> errors/1000SLOC and M semantic errors/1000SLOC (where M and N
|> vary on the ability of the programmer, his interest in his work,
|> and the difficulty of it.)
|>
|> In this situation, a good compiler, will point out his N syntax errors,
|> which he will correct. In the process of correcting these, it is
|> also likely that he will spot a few of the semantic errors.
|> This would then leave < M semantic errors for the programmer to
|> track down at run-time.
|>
|> All the language would then need is some kind of run time checking
|> to help him out.

The distinction between "syntax" errors "semantic" errors is misleading.
What is relevant here is the distinction between errors caught at compile
time and those caught at run time (or, worse, not caught at all).  For
example, a missing semicolon is a syntax error and a type mismatch is a
semantic error, but both are caught by an Ada compiler at compile time.

The point that Matthew was making was that Ada's strong compile-time
checks allow certain errors that might not be detected until run time, or
might not be detected until a program is in the hands of customers, to be
detected during compilation instead.  The greater number of compile-time
error messages means that more work is required to get a program to
compile, but once it compiles it is likely to have fewer run-time errors.
Thus it will take less work to get the compiled program to pass its tests
and the end product will be more reliable.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: next "big" language?? (disagree)

[Robert Dewar]

Ian Ward said

"2. Trying to reuse software for different purpose than it was originally
defined."

Sure, but abstraction is all about making sure that software you use
is maximally reusable, i.e. that the set of purposes for which the
software you write is as large as possible. If you have no method
for easily enforcing and taking advantage of data abstraction, you
cannot easily avoid over-specification and thus narrowing down the
scope of possible reuse purposes.

Code modification is the worst possible form of reuse (only slight
ly better, and sometimes worse than, rewriting stuff from scratch).
The whole idea is to reuse code as much as possible WITHOUT ever
having to touch it. Sure, in the C world, the normal paradigm for
code reuse is precisely to grab source and much with it, and that
is not surprising given the language, but it is far from ideal,
and from one point ofview you can see a major design goal in modern
language design is to eliminate the need for (and therefore the
practice of) this kind of source code mucking.