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=0.6 required=5.0 tests=BAYES_05,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <4130@enea.se>
Date: 5 Dec 88 06:53:06 GMT
Organization: ENEA DATA AB, Sweden
List-Id: <comp.lang.ada>

William Thomas Wolfe (billwolf@hubcap.clemson.edu) writes:
>I said:
>> 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!
>
>    Recall the discussion.  The rule that the "old" version of assign
>    would apply throughout any function named ":=", including parameter
>    passing, handles this contingency.

So there should be one rule for passing parameters to ":=" and another
to all other subprograms? That, if nothing else, shows that there is
something wrong with the idea. You expect all subprograms to behave
the same. What if ":=" is renamed? Should the rules change? And if
":=" calls another subprogram, what rules should be applied in this
case?
  Unless you don't want to fill the language definition with special
cases, and I don't, the idea to have a user-defined ":=" to implicitly
define parameter passing seems dead. If you really want it that way
you should think of some new syntactic device for defining assignment
of a limited type.
-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment