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

[rav@goanna.cs.rmit.EDU.AU (++ 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.