proposal for new assignment operators

proposal for new assignment operators

[Russ]

As most of you are aware, several very popular programming languages,
such as C, C++, Java, Perl, and Python, have what are called
"assignment operators." The most important of these operators are
"+=", "-=", "*=", and "/=".

On a recent thread, the usefulness of those operators was discussed in
detail, so I won't rehash it.

One of the problems with adding these operators to Ada is that "/=" is
already used for "not equals." So I suggested that the Ada version of
these operators could be ":+", ":-", ":*", and ":/". I did not get
much of a reply, but I think it's an idea worth considering, so I am
repeating it here.

These operators would be consistent with the ":=" assignment operator
of Ada, and I don't think they conflict with any established Ada
operator. I actually think they make *more* sense than the usual "+="
type operators. Consider, for example,

    count :+ 1
    EulerAngles :* D2R

I'm wearing my asbestos underwear, so have at it!

Re: proposal for new assignment operators

[Preben Randhol]

Russ wrote:
> 
>     count :+ 1
>     EulerAngles :* D2R

I don't like it at all.

> I'm wearing my asbestos underwear, so have at it!

Hehe vel isn't it just to aim at your toes and you will be tap dancing
;-)

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: proposal for new assignment operators

[Dmitry A. Kazakov]

Russ wrote:

> As most of you are aware, several very popular programming languages,
> such as C, C++, Java, Perl, and Python, have what are called
> "assignment operators." The most important of these operators are
> "+=", "-=", "*=", and "/=".
> 
> On a recent thread, the usefulness of those operators was discussed in
> detail, so I won't rehash it.
> 
> One of the problems with adding these operators to Ada is that "/=" is
> already used for "not equals." So I suggested that the Ada version of
> these operators could be ":+", ":-", ":*", and ":/". I did not get
> much of a reply, but I think it's an idea worth considering, so I am
> repeating it here.
> 
> These operators would be consistent with the ":=" assignment operator
> of Ada, and I don't think they conflict with any established Ada
> operator. I actually think they make *more* sense than the usual "+="
> type operators. Consider, for example,
> 
>     count :+ 1
>     EulerAngles :* D2R
> 
> I'm wearing my asbestos underwear, so have at it!

The real problem is not to find a better sequence of characters. The real 
problems are:

1. Ada does not have any assignment operator. It has an assignment 
statement. Carefully observe all the consequences of that. When I and 
others proposed to allow operators be implemented by procedures, the goal 
was to approach this problem.

2. Ada isn't C++. One have to provide an easy and safe way to ensure that 
"+" and in-place-"+" have compatible semantics. The language default has to 
be safe. This is why I made another proposal to invent a mechanism 
instructing the compiler to deduce one operations from others. Such things 
exist presently for "/=" which is automatically deduced from "=". And for 
":=", which is automatically deduced from Finalize, Adjust and assignments 
of the components. IMO we need something like:

procedure ":+" (L : in out Matrix; R : Matrix);
function "+" (L, R : Matrix) return Matrix;
for "+" use ":+";

But it is not an easy issue. Consider tagged types. You have overridden 
":+", but not "+". What have the language to say in such cases? Again, Ada 
need not to become Ada += C++; One C++ is already too much for our planet.

-------
Provided 1.& 2. one could just enlarge the set of lexical elements and let 
the programmer to choose what he/she wants. I would like to see "<+>", 
"[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the efforts?

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: proposal for new assignment operators

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> Provided 1.& 2. one could just enlarge the set of lexical elements and let 
> the programmer to choose what he/she wants. I would like to see "<+>", 
> "[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the efforts?

No. The "idem" proposal is worth the efforts.

Re: proposal for new assignment operators

[Dmitry A. Kazakov]

Lutz Donnerhacke wrote:

> * Dmitry A. Kazakov wrote:
>> Provided 1.& 2. one could just enlarge the set of lexical elements and
>> let the programmer to choose what he/she wants. I would like to see
>> "<+>", "[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the
>> efforts?
> 
> No. The "idem" proposal is worth the efforts.

Probably yes, but "idem" is rather an independent thing. It does not solve 
neither a problem of in-place operations (including constructors), nor a 
problem user-defined assignment(s) [for all types.]

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: proposal for new assignment operators

[Lutz Donnerhacke]

* Dmitry A. Kazakov wrote:
> Lutz Donnerhacke wrote:
>> * Dmitry A. Kazakov wrote:
>>> Provided 1.& 2. one could just enlarge the set of lexical elements and
>>> let the programmer to choose what he/she wants. I would like to see
>>> "<+>", "[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the
>>> efforts?
>>
>> No. The "idem" proposal is worth the efforts.
>
> Probably yes, but "idem" is rather an independent thing. It does not solve
> neither a problem of in-place operations (including constructors), nor a
> problem user-defined assignment(s) [for all types.]

If so, then "procedure Add_Inplace(to : in out Matrix, a : in out Matrix);"
exists and has to be provided anyway.

Re: proposal for new assignment operators

[Dmitry A. Kazakov]

On Thu, 26 Jun 2003 10:37:57 +0000 (UTC), Lutz Donnerhacke
<lutz@iks-jena.de> wrote:

>* Dmitry A. Kazakov wrote:
>> Lutz Donnerhacke wrote:
>>> * Dmitry A. Kazakov wrote:
>>>> Provided 1.& 2. one could just enlarge the set of lexical elements and
>>>> let the programmer to choose what he/she wants. I would like to see
>>>> "<+>", "[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the
>>>> efforts?
>>>
>>> No. The "idem" proposal is worth the efforts.
>>
>> Probably yes, but "idem" is rather an independent thing. It does not solve
>> neither a problem of in-place operations (including constructors), nor a
>> problem user-defined assignment(s) [for all types.]
>
>If so, then "procedure Add_Inplace(to : in out Matrix, a : in out Matrix);"
>exists and has to be provided anyway.

From this point of view there is also no need to have any assignment
statement. Why do you need ":=" if 

   procedure Set (To : in out Matrix; From : Matrix);

can be defined?

As I said the problem is not lexical. One can live with Set instead of
":=" or Add_Inplace instead of "<whatsoever>".

The problem is in semantics. What happens [with assignments] if you
derive from Matrix? What happens if you aggregate Matrix in some other
type? C++ says: "it is all your business, dear." Ada tries to protect
you as much as possible. That's far not easy. And note that when you
say that Add_Inplace is enough, you, in effect, follow C++'s, not
Ada's way.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: proposal for new assignment operators

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> What happens [with assignments] if you derive from Matrix?

Generally speaking, assignment should only be meaningful
between things of the same type. Polymorphic hierarchies
should most likely disallow assignment altogether. If the
Matrix subclasses are used for things like optimizing
storage (eg., diagonal matrices), then assignment remains
meaningful, and the semantics is just to assign each
matrix element from the source to the target.

Remembering previous posts, I suppose I should add the
caveat that this refers to derivation as normally used,
not derivation as you would like to have it. In C++, we
would most likely implement storage variations using
templates, not inheritance.

> What happens if you aggregate Matrix in some other type?

When you write assignment for that type, you decide how
to assign the aggregated pieces. In C++, you get a default
assignment operator if you don't declare your own, and that
does memberwise assignment, so the Matrix component would
be assigned using its own assignment operator.

Re: proposal for new assignment operators

[Russ]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<bdbtav$regf8$1@ID-77047.news.dfncis.de>...
> Russ wrote:
> >     count :+ 1
> >     EulerAngles :* D2R

> The real problem is not to find a better sequence of characters. The real 
> problems are:

Agreeing on a sequence of characters is not a *technical* problem, but
it is a problem nevertheless, and it could actually turn out to be
very difficult

> 1. Ada does not have any assignment operator. It has an assignment 
> statement. Carefully observe all the consequences of that. When I and 
> others proposed to allow operators be implemented by procedures, the goal 
> was to approach this problem.

As someone pointed out on an earlier thread, "+=", ":+", or whatever
you call it, is just "semantic sugar" for a procedure like
"Add_Matrix". It really has nothing to do with assignment per se. So I
fail to see the relevance of the fact that Ada has no assignment
operator.

> 2. Ada isn't C++. One have to provide an easy and safe way to ensure that 
> "+" and in-place-"+" have compatible semantics. The language default has to 
> be safe. This is why I made another proposal to invent a mechanism 
> instructing the compiler to deduce one operations from others. Such things 
> exist presently for "/=" which is automatically deduced from "=". And for 
> ":=", which is automatically deduced from Finalize, Adjust and assignments 
> of the components. IMO we need something like:

I agree it would be nice to have language enforcement of consistency
between operators, but I think that would be going beyond what Ada
already allows. Does Ada require a user-defined "+" operator to be
consistent with the corresponding "-" operator? No. "+" could add
matrices, and "-" could send email to Santa Claus.

> procedure ":+" (L : in out Matrix; R : Matrix);
> function "+" (L, R : Matrix) return Matrix;
> for "+" use ":+";

How about

function "+" (L, R : Matrix) return Matrix is
    Result: Matrix := L;
    begin
    Result :+ R;
    return Result;
    end "+";

> But it is not an easy issue. Consider tagged types. You have overridden 
> ":+", but not "+". What have the language to say in such cases? Again, Ada 
> need not to become Ada += C++; One C++ is already too much for our planet.

Maybe I'm missing something, but I don't see why these concerns are
any different than they would be for any other function or procedure.

> -------
> Provided 1.& 2. one could just enlarge the set of lexical elements and let 
> the programmer to choose what he/she wants. I would like to see "<+>", 
> "[+]", "(+)", "+:=", "<+>:=" etc added, but is that worth the efforts?

Re: proposal for new assignment operators

[Larry Kilgallen]

In article <bebbba07.0306242223.1f86b3f7@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:

> As most of you are aware, several very popular programming languages,
> such as C, C++, Java, Perl, and Python, have what are called
> "assignment operators." The most important of these operators are
> "+=", "-=", "*=", and "/=".
> 
> On a recent thread, the usefulness of those operators was discussed in
> detail, so I won't rehash it.

Thanks for that, but don't assume we were all convinced.

> One of the problems with adding these operators to Ada is that "/=" is
> already used for "not equals." So I suggested that the Ada version of
> these operators could be ":+", ":-", ":*", and ":/". I did not get
> much of a reply, but I think it's an idea worth considering, so I am
> repeating it here.

For all I care, such operators could be !@#$^#$%^#$%, I would not
understand them any less.  Please do not assume that we all came
from such a background.  I have used C, but the warning in your
first sentence is quite enough to make me steer clear of Java,
Perl and Python.

> These operators would be consistent with the ":=" assignment operator
> of Ada, and I don't think they conflict with any established Ada
> operator. I actually think they make *more* sense than the usual "+="
> type operators.

I believe the term is "damning with faint praise".

Re: proposal for new assignment operators

[Preben Randhol]

Larry Kilgallen wrote:
> 
> For all I care, such operators could be !@#$^#$%^#$%, I would not
> understand them any less.  Please do not assume that we all came

But wouldn't it be more fun to write and read Ada programs if we could
have:

   :-)
   :-(
   :-/
   :-P
  >:-{
  <:-)

and similar smilies as syntaxes ;-)

PS: Just so nobody gets confused I'm just kidding :-)

-- 
Preben Randhol -------------- http://www.pvv.org/~randhol/Ada95 --
                 �For me, Ada95 puts back the joy in programming.�

Re: proposal for new assignment operators

[Peter Hermann]

Preben Randhol <randhol+abuse@pvv.org> wrote:
>   :-)

approved  :-|

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: proposal for new assignment operators

[Georg Bauhaus]

Preben Randhol <randhol+abuse@pvv.org> wrote:
: Larry Kilgallen wrote:
:> 
:> For all I care, such operators could be !@#$^#$%^#$%, I would not
:> understand them any less.  Please do not assume that we all came
: 
: But wouldn't it be more fun to write and read Ada programs if we could
: have:
: 
:   :-)
:   :-(
:   :-/
:   :-P
:  >:-{
:  <:-)
: 
: and similar smilies as syntaxes ;-)

But we are close to that already, here is an excerpt from a working program:

   case a*(%$%) is
      when o.O          => A :=+ ('o');
      when (8-v)|12#8B# => OM(O.%/%(0,-0));
      when 2!2:0:..2:1: => null;
      when others       => << oO >> O.oo (O.o>o.O);
   end case;

Re: proposal for new assignment operators

[Preben Randhol]

Georg Bauhaus wrote:
> But we are close to that already, here is an excerpt from a working program:
> 
>    case a*(%$%) is
>       when o.O          => A :=+ ('o');
                               ^^^
Which language is this? :-)

>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
>       when 2!2:0:..2:1: => null;
>       when others       => << oO >> O.oo (O.o>o.O);
>    end case;

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: proposal for new assignment operators

[Vinzent Hoefler]

Preben Randhol wrote:

>Georg Bauhaus wrote:
>> But we are close to that already, here is an excerpt from a working program:
>> 
>>    case a*(%$%) is
>>       when o.O          => A :=+ ('o');
>                               ^^^
>Which language is this? :-)

Ada, badly formatted. Intentionally, I'd guess.

|A := +('o');

looks better, doesn't it?

Question to Georg: Was this your entry to the Ada-equivalent of
ioccc.org? ;->


Vinzent.

Re: proposal for new assignment operators

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> <snip> here is an excerpt from a working program:
> 
>    case a*(%$%) is
>       when o.O          => A :=+ ('o');
>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
>       when 2!2:0:..2:1: => null;
>       when others       => << oO >> O.oo (O.o>o.O);
>    end case;

Hmm. Changing this so I can try to compile it:

procedure Georg
is
begin
   case a*(%$%) is
      when o.O          => A :=+ ('o');
      when (8-v)|12#8B# => OM(O.%/%(0,-0));
      when 2!2:0:..2:1: => null;
      when others       => << oO >> O.oo (O.o>o.O);
   end case;
end Georg;

I get a GNAT bug with GNAT 3.16a - congratulations :). I don't think
I'll submit it.

-- 
-- Stephe

Re: proposal for new assignment operators

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
: 
: Hmm. Changing this so I can try to compile it:
: 
: procedure Georg
: is
: begin
:   case a*(%$%) is
:      when o.O          => A :=+ ('o');
:      when (8-v)|12#8B# => OM(O.%/%(0,-0));
:      when 2!2:0:..2:1: => null;
:      when others       => << oO >> O.oo (O.o>o.O);
:   end case;
: end Georg;
: 
: I get a GNAT bug with GNAT 3.16a - congratulations :). I don't think
: I'll submit it.

What kind of bug do you get? 
The GCC 3.1 compiler (1173) for Mac, when run with your changes, produces a
segmentation fault, after reporting "a" is undefined and compilation error.

See my reply to Preben's disbelief (:) for the complete program,
which does compile with GNAT 3.15p on GNU/Linux and 3.1 on Mac.

Georg

Re: proposal for new assignment operators

[Stephen Leake]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> Stephen Leake <Stephe.Leake@nasa.gov> wrote:
> : 
> : Hmm. Changing this so I can try to compile it:
> : 
> : procedure Georg
> : is
> : begin
> :   case a*(%$%) is
> :      when o.O          => A :=+ ('o');
> :      when (8-v)|12#8B# => OM(O.%/%(0,-0));
> :      when 2!2:0:..2:1: => null;
> :      when others       => << oO >> O.oo (O.o>o.O);
> :   end case;
> : end Georg;
> : 
> : I get a GNAT bug with GNAT 3.16a - congratulations :). I don't think
> : I'll submit it.
> 
> What kind of bug do you get? 

+===========================GNAT BUG DETECTED==============================+
| 3.16a (20030120) (i586-pc-mingw32msv) Program_Error EXCEPTION_ACCESS_VIOLATION|

As far as I am concerned, there is only one "kind" of bug in the
compiler (a bad one :).

> The GCC 3.1 compiler (1173) for Mac, when run with your changes, produces a
> segmentation fault, 

I gather you do not get this "GNAT BUG box"? Exactly how is the
"segmentation fault" reported? I hope it is in the form of an
unhandled Program_Error exception!

> after reporting "a" is undefined and compilation error.

I don't get that much.

> See my reply to Preben's disbelief (:) for the complete program,
> which does compile with GNAT 3.15p on GNU/Linux and 3.1 on Mac.

Ok.

-- 
-- Stephe

Re: proposal for new assignment operators

[Georg Bauhaus]

Stephen Leake <Stephe.Leake@nasa.gov> wrote:
:> : 
:> : procedure Georg
:> : is
:> : begin
:> :   case a*(%$%) is
:> :      when o.O          => A :=+ ('o');
:> :      when (8-v)|12#8B# => OM(O.%/%(0,-0));
:> :      when 2!2:0:..2:1: => null;
:> :      when others       => << oO >> O.oo (O.o>o.O);
:> :   end case;
:> : end Georg;
:> : 
:> : I get a GNAT bug with GNAT 3.16a - congratulations :). I don't think
:> : I'll submit it.
:> 
:> What kind of bug do you get? 
: 
: +===========================GNAT BUG DETECTED==============================+
: | 3.16a (20030120) (i586-pc-mingw32msv) Program_Error EXCEPTION_ACCESS_VIOLATION|
: 
: As far as I am concerned, there is only one "kind" of bug in the
: compiler (a bad one :).

:)

:> The GCC 3.1 compiler (1173) for Mac, when run with your changes, produces a
:> segmentation fault, 
: 
: I gather you do not get this "GNAT BUG box"? Exactly how is the
: "segmentation fault" reported? I hope it is in the form of an
: unhandled Program_Error exception!

No, just
Segmentation fault

However,
GNAT 3.3
Copyright 1992-2002 Free Software Foundation, Inc.

Compiling: georg.adb (source file time stamp: 2003-06-27 12:22:02)

     4.    case a*(%$%) is
                |
        >>> "a" is undefined

 11 lines: 1 error

runs fine.

Georg

Re: proposal for new assignment operators

[Preben Randhol]

Georg Bauhaus wrote:
> But we are close to that already, here is an excerpt from a working program:
> 
>    case a*(%$%) is
>       when o.O          => A :=+ ('o');
>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
>       when 2!2:0:..2:1: => null;
>       when others       => << oO >> O.oo (O.o>o.O);
>    end case;
> 

I don't believe this is from a *working* program.


-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: proposal for new assignment operators

[Georg Bauhaus]

Preben Randhol <randhol+abuse@pvv.org> wrote:
: Georg Bauhaus wrote:
:> But we are close to that already, here is an excerpt from a working program:
:> 
:>    case a*(%$%) is
:>       when o.O          => A :=+ ('o');
:>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
:>       when 2!2:0:..2:1: => null;
:>       when others       => << oO >> O.oo (O.o>o.O);
:>    end case;
:> 
: 
: I don't believe this is from a *working* program.

o.K.

procedure glub is

   procedure OM(o: natural) is
   begin
      null;
   end OM;

   a: Natural := 1;
   v: constant := 1;

   package o is
      o: constant := 17;
      procedure oo (o: Boolean);
      function "/"(o,oo: Natural) return natural;
      function "*"(left: Natural; right: String) return Natural;
      function "+"(o: Character) return Natural;
   end o;
   package body o is
      procedure oo (o: Boolean) is begin null; end oo;
      function "/"(o,oo: Natural) return Natural is
      begin
         return 0;
      end "/";
      function "*"(left: Natural; right: String) return Natural is
      begin
         return 1;
      end "*";
      function "+"(o: Character) return Natural is
      begin
         return 5;
      end "+";
   end o;

   use o;

begin
   case a*(%$%) is
      when o.O          => A :=+ ('o');
      when (8-v)|12#8B# => OM(O.%/%(0,-0));
      when 2!2:0:..2:1: => null;
      when others       => << oO >> O.oo (O.o>o.O);
   end case;

end glub;

Re: proposal for new assignment operators

[Preben Randhol]

Georg Bauhaus wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote:
>: 
>: I don't believe this is from a *working* program.
> 
> o.K.

["Pornographic" ;-) code removed]

Ok, then:

I don't believe this is from a *work* program ;-)

Well what it proved is that one actually can write:

   :=+ 

in Ada although it might not give the result some here would like :-)

Preben
-- 
"... in Ada, you can never have a buffer overflow error. Unless of
course you go very far out of your way to specifically program one
[...] most Ada programmers would consider going out of your way to
construct an Ada program that had a potential buffer overflow not
as a challenge, but as a kind of pornography." - Robert I. Eachus

Re: proposal for new assignment operators

[Steve]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnbfj40v.3su.randhol+abuse@kiuk0152.chembio.ntnu.no...
> Larry Kilgallen wrote:
> >
> > For all I care, such operators could be !@#$^#$%^#$%, I would not
> > understand them any less.  Please do not assume that we all came
>
> But wouldn't it be more fun to write and read Ada programs if we could
> have:
>
>    :-)
>    :-(
>    :-/
>    :-P
>   >:-{
>   <:-)
>
> and similar smilies as syntaxes ;-)
>
> PS: Just so nobody gets confused I'm just kidding :-)

Oh.  I thought you were tring to incorporate some APL features into Ada.

Steve
(The Duck)

>
> -- 
> Preben Randhol -------------- http://www.pvv.org/~randhol/Ada95 --
>                  �For me, Ada95 puts back the joy in programming.�

Re: proposal for new assignment operators

[Russ]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<CIkBNO94w0ls@eisner.encompasserve.org>...

> For all I care, such operators could be !@#$^#$%^#$%, I would not
> understand them any less.  Please do not assume that we all came
> from such a background.  I have used C, but the warning in your
> first sentence is quite enough to make me steer clear of Java,
> Perl and Python.

So "+=" is beyond your comprehension, and you intend to steer clear of
C, C++, Java, Perl, and Python. It's nice to find such bright,
open-minded people here on comp.lang.ada!

Re: proposal for new assignment operators

[John R. Strohm]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0306251833.69010629@posting.google.com...
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message
news:<CIkBNO94w0ls@eisner.encompasserve.org>...
>
> > For all I care, such operators could be !@#$^#$%^#$%, I would not
> > understand them any less.  Please do not assume that we all came
> > from such a background.  I have used C, but the warning in your
> > first sentence is quite enough to make me steer clear of Java,
> > Perl and Python.
>
> So "+=" is beyond your comprehension, and you intend to steer clear of
> C, C++, Java, Perl, and Python. It's nice to find such bright,
> open-minded people here on comp.lang.ada!

And THAT is the final straw.

Plonk!

Re: proposal for new assignment operators

[Frank J. Lhota]

I would prefer the Icon notation, where the operator prefixes the ":="
assignment symbol, e.g.

    first +:= margin
    last -:= margin

    # "||" is the Icon catenation operation, so this adds suffix to the end
of word
    word ||:= suffix

This fits in rather well with Ada, and poses no problem with division; "/:="
does in-place division, "/=" tests for inequality.

Re: proposal for new assignment operators

[Warren W. Gay VE3WWG]

Frank J. Lhota wrote:
> I would prefer the Icon notation, where the operator prefixes the ":="
> assignment symbol, e.g.
> 
>     first +:= margin
>     last -:= margin
> 
>     # "||" is the Icon catenation operation, so this adds suffix to the end
> of word
>     word ||:= suffix
> 
> This fits in rather well with Ada, and poses no problem with division; "/:="
> does in-place division, "/=" tests for inequality.

For my $0.02 Canadian, all of this fuss is fuss with very
little payback. In fact, all it will succeed in doing if
it gets accepted (which it won't AFAICS), is obfuscating
Ada code a bit more than it used to be. That is one of many
reasons it will never get accepted.

People keep claiming that it is not proposed for ease of typing, but
if you read through the thread, the theme that keeps emerging is
that it makes the code easier to write (vs easier to read). Just
give it up folks. It ain't goin' to be. If my input is included,
it will be against any such proposal.

There is simply no need for it.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: proposal for new assignment operators

[Russ]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3EF9CD5F.6030608@cogeco.ca>...
> Frank J. Lhota wrote:
> > I would prefer the Icon notation, where the operator prefixes the ":="
> > assignment symbol, e.g.
> > 
> >     first +:= margin
> >     last -:= margin
> > 
> >     # "||" is the Icon catenation operation, so this adds suffix to the end
> > of word
> >     word ||:= suffix
> > 
> > This fits in rather well with Ada, and poses no problem with division; "/:="
> > does in-place division, "/=" tests for inequality.
> 
> For my $0.02 Canadian, all of this fuss is fuss with very
> little payback. In fact, all it will succeed in doing if
> it gets accepted (which it won't AFAICS), is obfuscating
> Ada code a bit more than it used to be. That is one of many
> reasons it will never get accepted.

I'd like to know how count :+ 1 is any more obfuscated than count :=
count + 1. It looks simpler to me. And that applies all the more when
the variable name is longer. Also, A += B looks a lot cleaner to me
than Add_Matrix ( Into=>A, From=>B ). Ask any mathematician or MATLAB
user which they prefer -- to read *or* to write.

> People keep claiming that it is not proposed for ease of typing, but
> if you read through the thread, the theme that keeps emerging is
> that it makes the code easier to write (vs easier to read). Just
> give it up folks. It ain't goin' to be. If my input is included,
> it will be against any such proposal.

That's a crock. I have never once before this post said anything about
ease of typing, nor has anyone else that I recall. But now that you
mention it, it *is* easier to type too. That's just the icing on the
cake. And please spare me the standard baloney that says "easy to type
= difficult to read." Sometimes that's true, and sometimes it's not.
In this case, it isn't.

As for your arrogant "It ain't goin' to be" attitude, you may be
right, but if you are, it won't be for any rational reason. It'll just
be good old fashioned hard-headedness and stubbornness.

I can only hope that the influentual people behind Ada are more
open-minded than some of the regulars on this newsgroup. If not, I'm
afraid some of you regulars are destined to be big fish in an
ever-shrinking pond.

Re: proposal for new assignment operators

[Vinzent Hoefler]

Russ wrote:

>I'd like to know how count :+ 1 is any more obfuscated than count :=
>count + 1.

We've gone through this already. Yes, it looks simpler. But does it
look more obvious? No.


Vinzent.

Re: proposal for new assignment operators

[Larry Kilgallen]

In article <bebbba07.0306251909.760d7485@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:

> I'd like to know how count :+ 1 is any more obfuscated than count :=
> count + 1.

I am beginning to believe you are beyond hope.

That construct is totally obscure to someone who has not seen it before.
I can think of nothing in Ada meeting that incredible standard.

Re: proposal for new assignment operators

[Russ]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<3doRhIgUmUYX@eisner.encompasserve.org>...
> In article <bebbba07.0306251909.760d7485@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
> > I'd like to know how count :+ 1 is any more obfuscated than count :=
> > count + 1.
> 
> I am beginning to believe you are beyond hope.
> 
> That construct is totally obscure to someone who has not seen it before.
> I can think of nothing in Ada meeting that incredible standard.

Oh, you can't? Go find some programmers who have never seen Ada source
code, show them some Ada source code, and ask them if any of it looks
"obscure" to them. That should help you think of something in Ada that
meets such an "incredible" standard.

What's incredible is *your* implied standard: that someone should be
able to figure out how to read everything in a programming language by
simply looking at source code, with no training or external
information whatsoever. Such a language has never existed and never
will.

I can guarantee that ":+" will be easier for the vast majority of
programmers to learn than many other features currently found in Ada.
The vast majority of programmers know at least one of the languages C,
C++, Java, Perl, and Python. Simply tell them that ":+" is Ada's
version of "+=", and your done with it. that's all the training they
will need on that one. If only all of Ada were that simple!

Re: proposal for new assignment operators

[Preben Randhol]

Russ wrote:
> 
> Oh, you can't? Go find some programmers who have never seen Ada source
> code, show them some Ada source code, and ask them if any of it looks
> "obscure" to them. That should help you think of something in Ada that
> meets such an "incredible" standard.

I would beleive most programmers would read Ada code fairly easy just
because it is *so* self-documenting as it is. And one reason for that is
that it is not flooded with whitespaces.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: proposal for new assignment operators

[Larry Kilgallen]

In article <bebbba07.0306261008.51e8bc81@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<3doRhIgUmUYX@eisner.encompasserve.org>...
>> In article <bebbba07.0306251909.760d7485@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
>> 
>> > I'd like to know how count :+ 1 is any more obfuscated than count :=
>> > count + 1.
>> 
>> I am beginning to believe you are beyond hope.
>> 
>> That construct is totally obscure to someone who has not seen it before.
>> I can think of nothing in Ada meeting that incredible standard.
> 
> Oh, you can't? Go find some programmers who have never seen Ada source
> code, show them some Ada source code, and ask them if any of it looks
> "obscure" to them.

Please specify the Ada syntax elements which you find obscure.

Re: proposal for new assignment operators

[Kevin Cline]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<HfU+ONDON25c@eisner.encompasserve.org>...
> In article <bebbba07.0306261008.51e8bc81@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<3doRhIgUmUYX@eisner.encompasserve.org>...
> >> In article <bebbba07.0306251909.760d7485@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> >> 
> >> > I'd like to know how count :+ 1 is any more obfuscated than count :=
> >> > count + 1.
> >> 
> >> I am beginning to believe you are beyond hope.
> >> 
> >> That construct is totally obscure to someone who has not seen it before.
> >> I can think of nothing in Ada meeting that incredible standard.
> > 
> > Oh, you can't? Go find some programmers who have never seen Ada source
> > code, show them some Ada source code, and ask them if any of it looks
> > "obscure" to them.
> 
> Please specify the Ada syntax elements which you find obscure.

I found the distinction between controlled and uncontrolled types to
be completely obscure and to my mind completely unnecessary,
particularly when compared with C++, where one simply overrides the
assignment operator if desired.

Also the Finalization package seems rather complex, but maybe it has
to be to support garbage collection.  Still, it's much more complex
than the simple idea of a destructor.


 Finalization -- a completely obscure partitioning of the type system
that is peculiar to Ada alone.

Re: proposal for new assignment operators

[tmoran]

> I found the distinction between controlled and uncontrolled types to
> be completely obscure and to my mind completely unnecessary,
> particularly when compared with C++, where one simply overrides the
> assignment operator if desired.
  On a recent thread we were told that the usual idiom in C++ was
to do assignment a certain way to accomplish Finalization.  "idiom"
suggests it's up to the programmer to do it right.  When some complex
cases were mentioned, we were told basically that the programmer
would override assignment differently.  Personally, I prefer having
the computer do it, and do it right, rather than having to do it
myself, possibly making a mistaake in the process.

Re: proposal for new assignment operators

[Hyman Rosen]

tmoran@acm.org wrote:
>   On a recent thread we were told that the usual idiom in C++ was
> to do assignment a certain way to accomplish Finalization.  "idiom"
> suggests it's up to the programmer to do it right.  When some complex
> cases were mentioned, we were told basically that the programmer
> would override assignment differently.  Personally, I prefer having
> the computer do it, and do it right, rather than having to do it
> myself, possibly making a mistaake in the process.

You probably misunderstood what you read, then. Ada's
Controlled types don't offer anything extra over C++'s
abilities. Writing your own assignment operator in C++
is similar to writing Adjust in Ada. The constructor is
similar to Initialize, and the destructor is similar to
Finalize.

There are differences. In Ada, when a Controlled object
is initialized with an aggregate, Initialize is not called.
In C++, some constructor is always called. In Ada, assignment
is done by Finalizing the target, doing a bitwise copy of a
temporary object initialized from the source (although the
temporary mayy be elided), then calling Adjust on the target.
In C++, assignment is done by invoking the assignment operator.
The default assignment operator does elementwise assignment
for each subcomponent, but a user-written one may do whatever
it deems appropriate.

Re: proposal for new assignment operators

[tmoran]

> >   On a recent thread we were told that the usual idiom in C++ was
> > to do assignment a certain way to accomplish Finalization.
> > ... we were told basically that the programmer
> > would override assignment differently.

> The default assignment operator does elementwise assignment
> for each subcomponent, but a user-written one may do whatever
> it deems appropriate.

I repeat:
> Personally, I prefer having
> the computer do it, and do it right, rather than having to do it
> myself, possibly making a mistaake in the process.

Re: proposal for new assignment operators

[Richard Riehle]

Kevin Cline wrote:

> I found the distinction between controlled and uncontrolled types to
> be completely obscure and to my mind completely unnecessary,
> particularly when compared with C++, where one simply overrides the
> assignment operator if desired.

One reason for the peculiarity is that Ada, unlike C++, has limited
types.   For limited types, assignment is never possible.  Therefore,
overloading assignment is not possible.   Limited types are used for
most container classes.

It is rare that one even needs to override the assignment operator
on a non-limited type.   There is a distinction here that will not
be immediately obvious to the C++ programmer.

Additionally, the idea of Adjust for overriding assignment was done
intentionally after much wrangling about whether the language should
allow direct overriding or overloading the assignment operation.  For
a lot of very good reasons, the designers eschewed the C++ approach
in favor of the Adjust approach.   These reasons are discussed in some of the
literature that covers the rationale for the language design.

Richard Riehle

Re: proposal for new assignment operators

[Hyman Rosen]

Richard Riehle wrote:
 > For limited types, assignment is never possible.  Therefore,
> overloading assignment is not possible.

That "therefore" doesn't actually follow. In C++, to make assignment
impossible, you declare a private assignment operator. Surely it would
be no problem to say that assignment may not be overloaded for limited
types.

> It is rare that one even needs to override the assignment operator
> on a non-limited type.   There is a distinction here that will not
> be immediately obvious to the C++ programmer.

It's not that frequent to need to do it in C++ either, as long as you
avoid low-level types such as pointers that are better handled by
encapsulation in proper holder classes. Of course, in C++ you can define
assignment between different types, and then you do find yourself writing
assignment operators for describing that operation. For example, I might
have a simple
     template <typename T> struct ObjectHolder
     {
         T theObject;

         template <typename O>
         ObjectHolder &operator=(const ObjectHolder<O> &other)
         { theObject = other.theObject; return *this; }
      };
so that I can assign one kind of ObjectHolder to another. (This assignment
will be legal only when the underlying types are assignment compatible, and
will otherwise result in a compiler error message, so we are not decreasing
type safety here.)

> For a lot of very good reasons, the designers eschewed the C++ approach
> in favor of the Adjust approach. These reasons are discussed in some of
 > the literature that covers the rationale for the language design.

I looked at the section on Controlled types (7.4) in the Rationale and
didn't see any discussion about this, except for a remark about returning
limited types from functions. This leads me to believe that the "lot of
very good reasons" have to do with technical aspects of preserving
existing parts of Ada rather than abstract notions of how assignment
should be done properly. Not that there's anything wrong with that.

Re: proposal for new assignment operators

[Randy Brukardt]

Hyman Rosen wrote in message ...
>I looked at the section on Controlled types (7.4) in the Rationale and
>didn't see any discussion about this, except for a remark about
returning
>limited types from functions. This leads me to believe that the "lot of
>very good reasons" have to do with technical aspects of preserving
>existing parts of Ada rather than abstract notions of how assignment
>should be done properly. Not that there's anything wrong with that.


Sometimes Ada zealots (myself included) overstate the case. We get so
used to explaining something that it starts seeming like a good thing.

The truth is, Adjust was a kludge of sorts that came about for a number
of reasons. It was born of expediency. Ada 9x originally had a
full-blown constructor/destructor/user-defined assignment solution.
However, it is was very complicated, because assignments occur in many
contexts other than assignment statements (and only covering assignment
statements would make it impossible to make a complete abstraction),
because of "disappearing" components (it is not always the case that a
component in the source also exists in the target - which makes proper
composition a nightmare), and because it was orthogonal to everything
else in the language.

When the Distinguished Reviewers decided it was necessary to cut
proposed features (the infamous "scope reduction"), that was one of the
features that was cut.

A few of us (especially me) continued to push for some finalization
solution, because it is a critical capability present in many other
programming languages. Eventually, Tucker and his team proposed a much
lighter-weight solution using tagged types: the Controlled types that we
know and love.

This solution had a variety of nice properties: It didn't need a lot of
special rules (or implementation), because the tagged type rules
eliminated a lot of problems, and the implementation can be the same. It
composes automatically; because the handling of the source and target in
an assignment are separate, disappearing components are not a problem.

But it still is 3/4s of a loaf. That's a lot better than no loaf (which
was the only option politically), but it still isn't an ideal solution.
We have the problem that it cannot be added to an existing type (I
personally don't consider that much of a problem, since there are few
types of any complexity that don't need to be controlled). And there
isn't any way to allow assignments between subtypes with different
discriminants or bounds (since those checks are always performed in the
standard way). Perhaps interfaces will aleviate these problems.

If Ada 95 had been defined from scratch, it probably would not have had
the existing issues that made Finalization/user-defined assignment so
hard. But of course Ada 95 had to be mostly compatible with Ada 83 (as
Ada 2005 will have to be mostly compatible with Ada 95), so we didn't
have the blank sheet of paper to start from.

                       Randy.

Re: proposal for new assignment operators

[Hyman Rosen]

I thought it might be something like that :-)

Actually, one feature of the way Ada does it is that
it avoids the assignment operator / copy constructor
dichotomy present in C++. (In C++, initialization,
including that of function parameters, happens under
the auspices of a copy constructor, not by assignment.)

Re: proposal for new assignment operators

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Richard Riehle wrote:
>  > For limited types, assignment is never possible.  Therefore,
> > overloading assignment is not possible.
> 
> That "therefore" doesn't actually follow. In C++, to make assignment
> impossible, you declare a private assignment operator. Surely it would
> be no problem to say that assignment may not be overloaded for limited
> types.

Hmm. The point is that assignment does not exist in the first place
for limited types, therefore there is nothing to overload.

-- 
-- Stephe

Re: proposal for new assignment operators

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in
news:Q5NMa.632$i57.44@nwrdny02.gnilink.net: 

> It's not that frequent to need to do it in C++ either, as long as you
> avoid low-level types such as pointers that are better handled by
> encapsulation in proper holder classes. Of course, in C++ you can
> define assignment between different types, and then you do find
> yourself writing assignment operators for describing that operation.
> For example, I might have a simple
>      template <typename T> struct ObjectHolder
>      {
>          T theObject;
> 
>          template <typename O>
>          ObjectHolder &operator=(const ObjectHolder<O> &other)
>          { theObject = other.theObject; return *this; }
>       };
> so that I can assign one kind of ObjectHolder to another. (This
> assignment will be legal only when the underlying types are assignment
> compatible, and will otherwise result in a compiler error message, so
> we are not decreasing type safety here.)

In C++ template syntax above, does "typename" apply implicitly to only
classes and structs, or does it also primitive types such as int, char,
and float?

Jim Rogers

Re: proposal for new assignment operators

[Hyman Rosen]

James Rogers wrote:
> In C++ template syntax above, does "typename" apply implicitly to only
> classes and structs, or does it also primitive types such as int, char,
> and float?

Any type, including primitive ones.

Re: proposal for new assignment operators

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in 
news:hG6Oa.14372$Ha.12381@nwrdny02.gnilink.net:

> James Rogers wrote:
>> In C++ template syntax above, does "typename" apply implicitly to only
>> classes and structs, or does it also primitive types such as int, char,
>> and float?
> 
> Any type, including primitive ones.
> 
> 

This is interesting. Not too long ago in comp.lang.c++.moderated I was
told floats cannot be used as template parameters. Was I told correctly?

I was surprised when I was told that. I have wondered if it is true, and
if so, why.

Jim Rogers

Re: proposal for new assignment operators

[Hyman Rosen]

James Rogers wrote:
> This is interesting. Not too long ago in comp.lang.c++.moderated I was
> told floats cannot be used as template parameters. Was I told correctly?

A "typename" template parameter must be matched by an actual argument
which is a type, and this can be any type, including any primitive
type. Template parameters may also be constant values rather than types,
and in that case, those parameters cannot be floating point.

> I was surprised when I was told that. I have wondered if it is true, and
> if so, why.

Template parameters are used in the linkage of instantiated templates
(loosely speaking, the parameters are interpolated into the name of the
instantiation), and template arguments can be constant expressions.
Allowing floating-point parameters would lead to questions of equivalence
of instantiations. In my opinion that's not such a terrible burden, and I
would have allowed it, but the standard doesn't. Some compilers offer it
as an extension.

As a sample of the problem, consider
     template <float X> char *f() { static char c; return &c; }
     bool b = f<1./3.>() == f<1./6.+1./6.>();
How do you specify what the value of 'b' should be?

Re: proposal for new assignment operators

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in 
news:1057672755.789189@master.nyc.kbcfp.com:

> Template parameters are used in the linkage of instantiated templates
> (loosely speaking, the parameters are interpolated into the name of the
> instantiation), and template arguments can be constant expressions.
> Allowing floating-point parameters would lead to questions of equivalence
> of instantiations. In my opinion that's not such a terrible burden, and I
> would have allowed it, but the standard doesn't. Some compilers offer it
> as an extension.
> 
> As a sample of the problem, consider
>      template <float X> char *f() { static char c; return &c; }
>      bool b = f<1./3.>() == f<1./6.+1./6.>();
> How do you specify what the value of 'b' should be?
> 

Interesting.

I suppose part of the problem can be the algorithm for interpolation
of the parameter(s) into an instance name. Does the standard specify
this algorithm, or is that 'implementation defined'? If the standard
does not specify the interpolation algorithm I would expect object
files from different compilers to be incompatible with each other
when instantiating a template from a commonly referenced header file.

Are the parameters also available within the body of the template
for logic purposes?

Jim Rogers

Re: proposal for new assignment operators

[Hyman Rosen]

James Rogers wrote:
> I suppose part of the problem can be the algorithm for interpolation
> of the parameter(s) into an instance name.

Not really. It's simply that equal parameters should refer to the
same instantiation, and unequal ones to different instantiations.

> I would expect object files from different compilers to be incompatible

And that is in fact generally the case. You would expect Ada object files
from different compilers to be similarly incompatible. Both C++ and Ada
have a great many implementation-defined decisions to make, about such
things as data layout, "dope" vectors, exception processing, and threads.
The only way to have intercompatibility among compilers is to have a
platform ABI that specifies all of those things. VMS had such a thing,
and g++ now has a written specification for an IA64 platform ABI that's
extending to other platforms as well.

> Are the parameters also available within the body of the template
> for logic purposes?

Of course, using the names in the angle brackets.

Re: proposal for new assignment operators

[Matthew Heaney]

Richard Riehle <richard@adaworks.com> wrote in message news:<3F038B77.2F2E41B7@adaworks.com>...
> 
> One reason for the peculiarity is that Ada, unlike C++, has limited
> types.   For limited types, assignment is never possible.  Therefore,
> overloading assignment is not possible.   Limited types are used for
> most container classes.

The statement that C++ doesn't have limited types is false.  To make a
limited type in C++, you simply have to declare the assignment
operator and copy constructor as private, and not define them:

class Limited_Type is
public:
   void f();
private:
   Limited_Type& operator=(const Limited_Type&);
   Limited_Type(const Limited_Type&);
};


Also, most container types are not limited, because containers that
are limited are hard to compose.  (It should be easy to instantiate a
container type using another container type as the element type.)

The reason you need non-limited types is for composition, not for
assignment (which has dubious value for a container).  There are many
ways to copy a container without using the assignment operator.

Also, the assignment operator only allows you to copy from the same
type, but it's often the case that the source or target of the
assignment is some other kind of container (e.g. an array).


> It is rare that one even needs to override the assignment operator
> on a non-limited type.   There is a distinction here that will not
> be immediately obvious to the C++ programmer.

You almost always need to override the assignment operator for a
non-limited type, if the type allocates internal storage from a pool.

Re: proposal for new assignment operators

[Richard Riehle]

Matthew Heaney wrote:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3F038B77.2F2E41B7@adaworks.com>...
> >
> > One reason for the peculiarity is that Ada, unlike C++, has limited
> > types.   For limited types, assignment is never possible.  Therefore,
> > overloading assignment is not possible.   Limited types are used for
> > most container classes.
>
> The statement that C++ doesn't have limited types is false.  To make a
> limited type in C++, you simply have to declare the assignment
> operator and copy constructor as private, and not define them:
>
> class Limited_Type is
> public:
>    void f();
> private:
>    Limited_Type& operator=(const Limited_Type&);
>    Limited_Type(const Limited_Type&);
> };

Limited types are not defined as part of the C++ standard.  One can, of
course, do as you  have with your example.   I rather doubt it is as common
as one would find in Ada.

> Also, most container types are not limited, because containers that
> are limited are hard to compose.  (It should be easy to instantiate a
> container type using another container type as the element type.)

Container types, perhaps not those you have created, are often designed
as limited types.   There are different points-of-view on this.   I recall
a PhD dissertation from OSU on this subject where the dissertation
recommended that all types for a container be limited, even the generic
formal parameters.

> The reason you need non-limited types is for composition, not for
> assignment (which has dubious value for a container).  There are many
> ways to copy a container without using the assignment operator.

Of course, the idiom for composing with a limited type involves a generic
formal access type parameter.  Recall the wonderful quote from Maurice
Wilkes relative to this issue.

> Also, the assignment operator only allows you to copy from the same
> type, but it's often the case that the source or target of the
> assignment is some other kind of container (e.g. an array).

Exactly.  This is one reason for not providing assignment over a limited
type.   Instead, we typically create a copy procedure and declare the
name of that copy procedure as specifically as possible.

> > It is rare that one even needs to override the assignment operator
> > on a non-limited type.   There is a distinction here that will not
> > be immediately obvious to the C++ programmer.
>
> You almost always need to override the assignment operator for a
> non-limited type, if the type allocates internal storage from a pool.

True when using indirection in your design. Also true for nearly
any composite type (where the partial definition is private).  Not true
when the full definition is not composite.

There is certainly overlap in the concerns of the Ada and C++ programmer.
I think the Ada programmer has an easier time with this than the C++
programmer.

Richard Riehle

Re: proposal for new assignment operators

[Hyman Rosen]

Richard Riehle wrote:
> Limited types are not defined as part of the C++ standard.  One can, of
> course, do as you  have with your example.   I rather doubt it is as common
> as one would find in Ada.

Well, for one thing, the standard input and output streams are
of such a limited type. There are many objects for which assignment
would be meaningless or destructive, and this idiom appears in most
every moderately advanced book about C++.

> Container types, perhaps not those you have created, are often designed
> as limited types.   There are different points-of-view on this.   I recall
> a PhD dissertation from OSU on this subject where the dissertation
> recommended that all types for a container be limited, even the generic
> formal parameters.

But this is not how Ada arrays work, so why should other containers
work that way? In C++, the standard containers all support assignment,
with the semantics of making the target of the assignment compare
equal to the source after the assignment happens (which means that the
two containers will have the same size, and the elements will compare
equal).

> Exactly.  This is one reason for not providing assignment over a limited
> type.   Instead, we typically create a copy procedure and declare the
> name of that copy procedure as specifically as possible.

In C++, that procedure is just called "operator=". We can program
assignment from arbitrary source types if we choose, by using templates.

Re: proposal for new assignment operators

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
>

> > Container types, perhaps not those you have created, are often designed
> > as limited types.   There are different points-of-view on this.   I recall
> > a PhD dissertation from OSU on this subject where the dissertation
> > recommended that all types for a container be limited, even the generic
> > formal parameters.
>
> But this is not how Ada arrays work, so why should other containers
> work that way? In C++, the standard containers all support assignment,
> with the semantics of making the target of the assignment compare
> equal to the source after the assignment happens (which means that the
> two containers will have the same size, and the elements will compare
> equal).

Well, actually,  container types  constructed from arrays are often designed
as limited private.   In fact, it is frequently desirable to keep direct
visibility to the
array away from the client of that array, even when the client knows the
underlying
structure is an array.

> > Exactly.  This is one reason for not providing assignment over a limited
> > type.   Instead, we typically create a copy procedure and declare the
> > name of that copy procedure as specifically as possible.
>
> In C++, that procedure is just called "operator=". We can program
> assignment from arbitrary source types if we choose, by using templates.

One problem with overloading the assignment operation is that the user
of that assignment cannot know, except via the documentation, what the
outcome will be.   For a limited type, when we declare a procedure, we
can give the procedure a name that makes clear the expected outcome.

           procedure Copy_BitWise(Source : in T;  Target : out T);

           procedure Copy_Shallow(Source : in T;  Target : out T);

and so forth.  While this might seem a little extreme, I rarely encounter
anyone who is  confused by a procedure where the exact behavior is
declared in its name.

If we overload assignment, we still find ourselves with no idea of what
is really going on when we assign a to b.   This is also true of overloading
the equality operator for a composite type, particularly one that includes
access values in its definition.

I prefer limited types, even though they are slightly more work to define,
and even though I have to think ahead a lot more when designing with
them.

Matthew Heaney has correctly pointed out that the idiom is possible in
C++.  Mr. Rosen has noted that there are places in C++ where the types
are roughly equivalent to limited types.   Even so, the power of limited
types ought not be underestimated as a feature of Ada that encourages
the design of safe abstractions.

Richard Riehle

Re: proposal for new assignment operators

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: 
: I'd like to know how count :+ 1 is any more obfuscated than count :=
: count + 1.

Anyway, it could be the label count:, followed by +1, among other things.
I'd find it much more plausible, that if there were going to be talk
about augmented assignment, then it will be assignemt, augmented.

That is ":=" with "+" as "+:=", as is the case in some other
programming languages that seem to have been of some significance
during the developement of Ada 95, including SETL2, and possibly
Icon. This is an opportunity to read a bit about augmented assignment,
I think.


: (+=) It looks simpler to me.

But does it blend well with the rest of Ada syntax?

Re: proposal for new assignment operators

[Russ]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:<bdhh5e$ciq$2@a1-hrz.uni-duisburg.de>...
> Russ <18k11tm001@sneakemail.com> wrote:
> : 
> : I'd like to know how count :+ 1 is any more obfuscated than count :=
> : count + 1.
> 
> Anyway, it could be the label count:, followed by +1, among other things.
> I'd find it much more plausible, that if there were going to be talk
> about augmented assignment, then it will be assignemt, augmented.
> 
> That is ":=" with "+" as "+:=", as is the case in some other
> programming languages that seem to have been of some significance
> during the developement of Ada 95, including SETL2, and possibly
> Icon. This is an opportunity to read a bit about augmented assignment,
> I think.

That would be acceptable to me. I think two characters is preferable
to three, but that is obviously only a cosmetic issue. The important
thing is to get these operators in Ada. Their usefulness has been
proven in at least the five most popular general-purpose programming
languages around today.

Re: proposal for new assignment operators

[Larry Kilgallen]

In article <bebbba07.0306271512.6cdd5f79@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:

> That would be acceptable to me. I think two characters is preferable
> to three, but that is obviously only a cosmetic issue. The important
> thing is to get these operators in Ada. Their usefulness has been
> proven in at least the five most popular general-purpose programming
> languages around today.

As has the usefulness of pointer arithmetic, null terminated string,
etc.  People who want those features should use those languages.

Re: proposal for new assignment operators

[Russ]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<pMTkgtGAiZ3l@eisner.encompasserve.org>...
> In article <bebbba07.0306271512.6cdd5f79@posting.google.com>, 18k11tm001@sneakemail.com (Russ) writes:
> 
> > That would be acceptable to me. I think two characters is preferable
> > to three, but that is obviously only a cosmetic issue. The important
> > thing is to get these operators in Ada. Their usefulness has been
> > proven in at least the five most popular general-purpose programming
> > languages around today.
> 
> As has the usefulness of pointer arithmetic, null terminated string,
> etc.  People who want those features should use those languages.

Java, Perl, and Python do not have pointer arithmetic, and C++ took a
step away from it with the STL. It's still there in C++, but STL
reduces the need to use it explicitly. A similar statement could be
made for null-terminated strings, I think, but certainly not for
augmented assignment.

Re: proposal for new assignment operators

[Warren W. Gay VE3WWG]

Russ wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3EF9CD5F.6030608@cogeco.ca>...
>>Frank J. Lhota wrote:
>>>I would prefer the Icon notation, where the operator prefixes the ":="
>>>assignment symbol, e.g.
>>>
>>>    first +:= margin
>>>    last -:= margin
>>>
>>>    # "||" is the Icon catenation operation, so this adds suffix to the end
>>>of word
>>>    word ||:= suffix
>>>
>>>This fits in rather well with Ada, and poses no problem with division; "/:="
>>>does in-place division, "/=" tests for inequality.
>>
>>For my $0.02 Canadian, all of this fuss is fuss with very
>>little payback. In fact, all it will succeed in doing if
>>it gets accepted (which it won't AFAICS), is obfuscating
>>Ada code a bit more than it used to be. That is one of many
>>reasons it will never get accepted.
> 
> I'd like to know how count :+ 1 is any more obfuscated than count :=
> count + 1. It looks simpler to me. And that applies all the more when
> the variable name is longer. Also, A += B looks a lot cleaner to me
> than Add_Matrix ( Into=>A, From=>B ). Ask any mathematician or MATLAB
> user which they prefer -- to read *or* to write.
...
> As for your arrogant "It ain't goin' to be" attitude, you may be
> right, but if you are, it won't be for any rational reason. It'll just
> be good old fashioned hard-headedness and stubbornness.
> 
> I can only hope that the influentual people behind Ada are more
> open-minded than some of the regulars on this newsgroup. If not, I'm
> afraid some of you regulars are destined to be big fish in an
> ever-shrinking pond.

As to my statement that you call "arrogant", this is simply a
statement as to how I see it panning out. If that is arrogant to
you, then there is nothing more I can say about it. But to use
your line of reasoning, then I guess it would be fair to say that
the statement "you regulars are destined to be big fish in an
ever-shrinking pond" is equally arrogant ;-)

You know, I can be open minded about many things, but there are
just some things in life that are not worth the bother for. To
me at least, this is one of them. Many reasons have been given
already why this is a worthless proposition. There is not a _big_
payback here. That perhaps is one of the biggest reasons it will
not be seriously considered.  It also goes against some of the
standing goals of Ada (readability, for example). But all of this
has been said before.

So I voiced my opinion, and I am going to leave it at that. You
guys can argue this out, but I personally think this is wasting
your time.

(signing off this thread).

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: proposal for new assignment operators

[Russ]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3EFC86A0.5090002@cogeco.ca>...

> You know, I can be open minded about many things, but there are
> just some things in life that are not worth the bother for. To

I will agree that augmented assignment operators are a small thing,
but sometimes small things add up to make a significant difference.

Take car design as one of an infinite number of possible examples.
Suppose the speedometer is located in such a way that you have to bend
your neck awkwardly to see it while driving. Now, someone could come
along and say that's a trivial problem -- but if you drive the car for
10 years it becomes a real nuisance.

Ada has many nice features. I really appreciate the ability to pass
arguments by named association, for example (Python has this too, by
the way). It has overloading and default arguments, which are
certainly *unnecessary* but are nice features nevertheless. But Ada
doesn't have augmented assignment, which the top five languages have.
It's like a luxury car that has everything but frickin' cup holders
and visors.

> me at least, this is one of them. Many reasons have been given
> already why this is a worthless proposition. There is not a _big_

Worthless, eh? I guess that's why C, C++, Java, Perl, and Python all
have it, and it is one of the most common features used. The users of
those languages probably outnumber Ada users by over 100:1, by the
way. No, that doesn't mean that Ada is inferior, of course, but it
does mean that many other programmers consider augmented assignment to
worth something. Just who the hell are you to declare it "worthless"?

> payback here. That perhaps is one of the biggest reasons it will
> not be seriously considered.  It also goes against some of the
> standing goals of Ada (readability, for example). But all of this
> has been said before.

Ah, the readability thing again. I guess you think that a statement
must be true if you repeat it enough times. Sorry, but it ain't so.

> So I voiced my opinion, and I am going to leave it at that. You
> guys can argue this out, but I personally think this is wasting
> your time.

Actually, I agree that much of this discussion has been a waste of
time. Let's just make Ada a fully modern programming language and
forget about it.

> (signing off this thread).

Yeah, right.

Re: proposal for new assignment operators

[Warren W. Gay VE3WWG]

Russ wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3EFC86A0.5090002@cogeco.ca>...
...
>>So I voiced my opinion, and I am going to leave it at that. You
>>guys can argue this out, but I personally think this is wasting
>>your time.
> 
> Actually, I agree that much of this discussion has been a waste of
> time. Let's just make Ada a fully modern programming language and
> forget about it.
> 
>>(signing off this thread).
> 
> Yeah, right.

Yep, just watch me ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: proposal for new assignment operators

[Bill Findlay]

On 25/6/03 07:23, in article
bebbba07.0306242223.1f86b3f7@posting.google.com, "Russ"
<18k11tm001@sneakemail.com> wrote:

> One of the problems with adding these operators to Ada is that "/=" is
> already used for "not equals." So I suggested that the Ada version of
> these operators could be ":+", ":-", ":*", and ":/". I did not get
> much of a reply, but I think it's an idea worth considering, so I am
> repeating it here.
> 
> These operators would be consistent with the ":=" assignment operator
> of Ada, and I don't think they conflict with any established Ada
> operator. I actually think they make *more* sense than the usual "+="
> type operators. Consider, for example,
> 
>   count :+ 1
>   EulerAngles :* D2R
> 
> I'm wearing my asbestos underwear, so have at it!

Russ, you missed the point of my previous reply to this proposal.

Your syntax is *in*compatible with the co-existence of the '=' operator and
the ':=' assignment symbol. In your proposal, x :? y,
for some operator ?, means: "x is assigned the value of (x ? y)".

I now ask, what does a := b mean when a and b are Boolean?
Does it assign (a = b) to a, or does it assign b to a?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: proposal for new assignment operators

[Russ]

Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message news:<BB1FBA16.36FD%yaldnifw@blueyonder.co.uk>...
> On 25/6/03 07:23, in article
> bebbba07.0306242223.1f86b3f7@posting.google.com, "Russ"
> <18k11tm001@sneakemail.com> wrote:
> 
> > One of the problems with adding these operators to Ada is that "/=" is
> > already used for "not equals." So I suggested that the Ada version of
> > these operators could be ":+", ":-", ":*", and ":/". I did not get
> > much of a reply, but I think it's an idea worth considering, so I am
> > repeating it here.
> > 
> > These operators would be consistent with the ":=" assignment operator
> > of Ada, and I don't think they conflict with any established Ada
> > operator. I actually think they make *more* sense than the usual "+="
> > type operators. Consider, for example,
> > 
> >   count :+ 1
> >   EulerAngles :* D2R
> > 
> > I'm wearing my asbestos underwear, so have at it!
> 
> Russ, you missed the point of my previous reply to this proposal.

Yes, I did.

> Your syntax is *in*compatible with the co-existence of the '=' operator and
> the ':=' assignment symbol. In your proposal, x :? y,
> for some operator ?, means: "x is assigned the value of (x ? y)".
> 
> I now ask, what does a := b mean when a and b are Boolean?
> Does it assign (a = b) to a, or does it assign b to a?

Oh, now I see what you mean. You have an interesting point, but I
don't think its particularly compelling. The ":=" symbol obviously
should not be redefined for this special case. So the answer to your
question is that a := b would assign b to a.

It's not really an incompatibility; its just that "=" doesn't happen
to be one of the operators that should have an in-place counterpart.
It wouldn't be useful anyway. After all, none of the languages with
"+=" have "===", do they?

Re: proposal for new assignment operators

[Bill Findlay]

On 26/6/03 03:06, in article
bebbba07.0306251806.5789a018@posting.google.com, "Russ"
<18k11tm001@sneakemail.com> wrote:

> Bill Findlay <yaldnifw@blueyonder.co.uk> wrote in message
>> Your syntax is *in*compatible with the co-existence of the '=' operator and
>> the ':=' assignment symbol. In your proposal, x :? y,
>> for some operator ?, means: "x is assigned the value of (x ? y)".
>> 
>> I now ask, what does a := b mean when a and b are Boolean?
>> Does it assign (a = b) to a, or does it assign b to a?
> 
> Oh, now I see what you mean. You have an interesting point, but I
> don't think its particularly compelling. The ":=" symbol obviously
> should not be redefined for this special case. So the answer to your
> question is that a := b would assign b to a.
> 
> It's not really an incompatibility; its just that "=" doesn't happen
> to be one of the operators that should have an in-place counterpart.

Is there any better reason for this than expediency?

> It wouldn't be useful anyway.

'=' for Boolean operands is every bit (!) as useful as 'xor'.

> After all, none of the languages with "+=" have "===", do they?

Ah! You think Ada should aspire to the arbitrariness of C in this regard.

Which of Ada's operators do you think should be given these special
privileges, and which should be second-class citizens?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")

Re: proposal for new assignment operators

[Karel Miklav]

Russ wrote:
> It's nice to find such bright, open-minded people here on 
> comp.lang.ada!

Listen Russ, you cannot blame people like this. What if someone starts 
the campaign to get some stuff from Perl into Ada tomorrow, are we all 
supposed to say: no problem, how else can we serve you?

> Oh, now I see what you mean. You have an interesting point, but I 
> don't think its particularly compelling. The ":=" symbol obviously 
> should not be redefined for this special case. So the answer to your
>  question is that a := b would assign b to a.

No special cases please, I'm sic++k of them already.

> It wouldn't be useful anyway. After all, none of the languages with
> "+=" have "===", do they?

Yes, they do:
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/ops.html#1060974

Regards,
Karel Miklav

Re: proposal for new assignment operators

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: 
:> Your syntax is *in*compatible with the co-existence of the '=' operator and
:> the ':=' assignment symbol. In your proposal, x :? y,
:> for some operator ?, means: "x is assigned the value of (x ? y)".
:> 
:  The ":=" symbol obviously
: should not be redefined for this special case. So the answer to your
: question is that a := b would assign b to a.

special casing for operators...
Searching goole for
 "augmented assignment" -python
turn up some interesting material.

: It wouldn't be useful anyway. After all, none of the languages with
: "+=" have "===", do they?

They do. However, += need not be what you think it is.


Georg

Re: proposal for new assignment operators

[Joseph Dalton]

18k11tm001@sneakemail.com (Russ) writes:

...
> It's not really an incompatibility; its just that "=" doesn't happen
> to be one of the operators that should have an in-place counterpart.
> It wouldn't be useful anyway. After all, none of the languages with
> "+=" have "===", do they?

Verilog, a hardware description language (modelled on C), has it.


-- 
Joe Dalton 

Re: proposal for new assignment operators

[Frank J. Lhota]

"Russ" <18k11tm001@sneakemail.com> wrote in message
news:bebbba07.0306251806.5789a018@posting.google.com...
> It's not really an incompatibility; its just that "=" doesn't happen
> to be one of the operators that should have an in-place counterpart.
> It wouldn't be useful anyway. After all, none of the languages with
> "+=" have "===", do they?

Icon has a "===" operator, and therefore Icon also permits a "===:="
operator (although this is fairly useless).

Re: proposal for new assignment operators

[christoph.grein]

Georg Bauhaus schrieb:

> Preben Randhol <randhol+abuse@pvv.org> wrote:
> : Georg Bauhaus wrote:
> :> But we are close to that already, here is an excerpt from a working program:
> :> 
> :>    case a*(%$%) is
> :>       when o.O          => A :=+ ('o');
> :>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
> :>       when 2!2:0:..2:1: => null;
> :>       when others       => << oO >> O.oo (O.o>o.O);
> :>    end case;
> :> 
> : 
> : I don't believe this is from a *working* program.
>
> o.K.
>
> procedure glub is
>
>    procedure OM(o: natural) is
>    begin
>       null;
>    end OM;
>
>    a: Natural := 1;
>    v: constant := 1;
>
>    package o is
>       o: constant := 17;
>       procedure oo (o: Boolean);
>       function "/"(o,oo: Natural) return natural;
>       function "*"(left: Natural; right: String) return Natural;
>       function "+"(o: Character) return Natural;
>    end o;
>    package body o is
>       procedure oo (o: Boolean) is begin null; end oo;
>       function "/"(o,oo: Natural) return Natural is
>       begin
>          return 0;
>       end "/";
>       function "*"(left: Natural; right: String) return Natural is
>       begin
>          return 1;
>       end "*";
>       function "+"(o: Character) return Natural is
>       begin
>          return 5;
>       end "+";
>    end o;
>
>    use o;
>
> begin
>    case a*(%$%) is
>       when o.O          => A :=+ ('o');
>       when (8-v)|12#8B# => OM(O.%/%(0,-0));
>       when 2!2:0:..2:1: => null;
>       when others       => << oO >> O.oo (O.o>o.O);
>    end case;
>
> end glub;

Georg, I thought you were kidding when you said this was from a working program. Now I'm 
standing with awe in front of this little gem. I'll keep it in my store forever :-)

Das ist das schönste verrückte Ada-Programm, das ich je gesehen habe :-)

Re: proposal for new assignment operators

[Preben Randhol]

christoph.grein@eurocopter.com wrote:

> Das ist das sch�nste verr�ckte Ada-Programm, das ich je gesehen habe :-)

And it shows how unreadable code gets if you use a lot of whitespace ,
strange overloadings and single letter package/procedure/variable names
:-)

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: proposal for new assignment operators

[Georg Bauhaus]

christoph.grein@eurocopter.com wrote:
:> end glub;
: 
: Georg, I thought you were kidding when you said this was from a working program. Now I'm 
: standing with awe in front of this little gem. I'll keep it in my store forever :-)

Thanks. Don't show it to non-Ada programmers ;-)
 
: Das ist das sch?nste verr?ckte Ada-Programm, das ich je gesehen habe :-)

Wenn ich schon sonst nix beisteuere ...

-- Georg
``...keep fun in computing''.  -- Alan Perlis