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

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