From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!steinmetz!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Keywords: Pre-processing, examples
Message-ID: <4123@enea.se>
Date: 3 Dec 88 21:08:16 GMT
Organization: ENEA DATA AB, Sweden
List-Id: <comp.lang.ada>

Geoff Mendal (mendal@ANNA.STANFORD.EDU) writes:
>>The argument that pre-processors can be used to acheive this effect is
>>bull. It ignores the absolute fact that *no one* maintains, reads, or
>>is expected to understand the processed code. This is a null argument.
>
>Quite the contrary.  The whole idea of a pre-processor or translation
>tool is to remove the need to "read" the processed version.  How many
>...
>So why is it that defining a mapping from some pre-processor to Ada is
>met with such cynicism?  It simply provides an additional layer of
>abstraction,

Pre-processors are OK, if they don't appear to you as pre-processors.
For example you must make the debugger to work on the original code,
not what the pre-processor produces. Also, the pre-processor should
be genrally available, or else you will lose portability.

Many of Geoff Mendal's ideas are reasonable. Yet, I like to provide 
some examples you might long for an overloadable ":=".

When we declare our variables in blocks we often initiate them. This
makes us feel safe, we know that the variable has a defined value,
and we can deduce so by looking at the declaration part. Since ":="
is not overloadable, we cannot initiate a limited private type in a
declaration. E.g. (Text is from the Text_handler in 7.6 of the LRM.)
   A : Text := To_text("Test string");
is illegal.

My other point concerns generic parameters. I once wrote a generic
package for sorted binary trees. It's parameter list looks like this:

   Generic
      Type Data_type is limited private;
      With procedure Assign(A : in out Data_type;
                            B : in     Data_type);
      With function "<"(A, B : Data_type) return boolean is <>;
      With function ">"(A, B : Data_type) return boolean is <>;
   Package Binary_trees is

With an overloadable ":=" I could have declared the second parameter as

      With procedure ":="(A : in out Data_type;
                          B : in     Data_type) is <>;

This would save the user from declaring unnecessary Assign for types like
integer. This Assign procedure he has to write is simple, but is 100% noise 
to his code.
  (Of course I could make Data_type Private only, but in this case the user
would be unnecessarily restriced, since he would be able to instantiate
it for limited types.)

Again this was some examples since Geoff Mendall wanted some. None of
them shows that you "must" have overloadable ":=". Just some case  
there it would be nice.

Oh, someone thought that an user-defined ":=" should apply to parameter
passing as well. This is of course impossible. In that case ":=" should
define how the parameters were passed to itself. A true circular definition!
-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment