In <658@manutius.UUCP> garyp@manutius.UUCP (Gary Powell) writes:

>Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.

>It appears to me that there are a large number of folks who want the following
>new operators added to the language.

>1) ||=

>   where:  x ||= y   <==>  x = x || y

>   Seems resonable as it matches all the "Blah"= operators.

*****> I would assume (hope?) that the semantics would be similar to
 plain ol' || in that if x is already true, y will not be
 evaluated.

>2) &&=

>   where:  x &&= y   <==>  x = x && y

>   Also seems reasonable for the same issue as #1.

*****> Same idea.

>3) ===

>   where x === y   <==> x = x == y

>   I have more trouble looking at this one, but again it still fits the
>   "blah"= operator rule.  So it maybe that I just haven't thought about
>   it long enough. Anyway I recommend it.

*****> Is this _that_ useful?  For completeness you'd also have to add:

  x !== y
  x <== y
  x >== y
  x <= y  // oops! <= is already an operator!
  x >= y  // ditto

 How about implication?

  x => y  <==>   !x || y

 And of course:

  x =>= y  <==> x = x => y

 :)  Seriously, I think we're going into operator overload (pun
 intended).  Operators are like Lays (TM) potato chips: you can't
 eat...er...add just one because if you add operator @ someone
 will want (and complain until the cows come home) that operators
 !@ and @= don't exist.

>4) some set of chars yet to be determined which bind tighter than the * and /
>   for which x power y  is x raised to the power of y.

*****> I'm not gonna touch this one; basically, I don't care because
 I'll probably only have occasion to use it even less that I use
 floats or doubles...and that's not a lot.

>   This seems reasonable but again has the problem of what do we do with
>   the odd ball arguments of y and x?

*****> Hopefully the same things that pow() does so code that switches
 from pow() to whatever won't break.

>   I recommend we define it as an operator but leave its implementation alone
>   and let everyone overload it as they see fit. And I don't care which
>   set or single character is chosen. My reasoning is that the current
>   arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
>   see heat on this one.) would care to summarize the arguments on this.

>5) "."
>   Lets add this.  I mean really, no one's code will break if we have it,
>   the earth will not shake and the sky fall down.  If it turns out to be
>   not as useful as Jim claims..so what?  We'll drop it from language "D"
>   the next generation.

[ ...other commentary deleted... ]
--
 - Paul J. Lucas    University of Illinois
   AT&T Bell Laboratories  at Urbana-Champaign
   Naperville, IL   pjl@cs.uiuc.edu

In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes:
|> Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.
|>
|> It appears to me that there are a large number of folks who want the following
|> new operators added to the language.
|>
|> 1) ||=
|>
|>    where:  x ||= y   <==>  x = x || y
|>
|>    Seems resonable as it matches all the "Blah"= operators.
|>
|> 2) &&=
|>
|>    where:  x &&= y   <==>  x = x && y
|>
|>    Also seems reasonable for the same issue as #1.
|>
|>
|> 3) ===
|>
|>    where x === y   <==> x = x == y
|>
|>    I have more trouble looking at this one, but again it still fits the
|>    "blah"= operator rule.  So it maybe that I just haven't thought about
|>    it long enough. Anyway I recommend it.
|>
|> 4) some set of chars yet to be determined which bind tighter than the * and /
|>    for which x power y  is x raised to the power of y.
|>
|>    This seems reasonable but again has the problem of what do we do with
|>    the odd ball arguments of y and x?
|>
|>    I recommend we define it as an operator but leave its implementation alone
|>    and let everyone overload it as they see fit. And I don't care which
|>    set or single character is chosen. My reasoning is that the current
|>    arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
|>    see heat on this one.) would care to summarize the arguments on this.
|>
|> 5) "."
|>    Lets add this.  I mean really, no one's code will break if we have it,
|>    the earth will not shake and the sky fall down.  If it turns out to be
|>    not as useful as Jim claims..so what?  We'll drop it from language "D"
|>    the next generation.
|>
|> Any others I've missed???
|>
|> Lets get on with it.  Like it or not many of us have to work with C++ even
|> though language "X" is better at some other task.  Lets add the features folks
|> clamor for.  IF they can make a convincing statement of "It won't break any
|> existing code. And it is possible for someone of resonable experience
|> programming to use it without shooting themselves in the foot."
|>
|> We still have a lot of other pressing problems, like how to incorporate
|> persistance, and how to do good garbage collection, and how to at run time
|> create objects whose type isn't known until after the program is running.
|>
|>
|> BTW.
|>   Could you folks who want to argue language issues move your discussion over
|> to this group?  Then we can quit annoying the folks who want to compare
|> Borland to Mircosoft or ask the beginners questions. And I don't have
|> to read 100 or more messages to find the language issue ones.
|>

Whoa. All of these are simply programmer convienences (sp?). I would rather
code a few more characters and be able to clearly read the code than save a few
bytes of disk space. If that many new operators are going to be added,
why not just make it a rule for all binary operators?

.i.e, x (op)= y;  <==>   x = x (op) y;

--

======================
Bill Volz
Chevron Oil Field Research Co.
Exploration Research/Geophysics Division.
P.O. Box 446, La Habra, CA 90633-0446
Phone: (310) 694-9340

In article <658@manutius.UUCP> garyp@manutius.UUCP (Gary Powell) writes:
>5) "."
>   Lets add this.  I mean really, no one's code will break if we have it,
>   the earth will not shake and the sky fall down.  If it turns out to be
>   not as useful as Jim claims..so what?  We'll drop it from language "D"
>   the next generation.

It would be nice if it were so easy to undo an addition.  (You were
joking, right?)

>Lets get on with it.  Like it or not many of us have to work with C++ even
>though language "X" is better at some other task.  Lets add the features folks
>clamor for.

Those people that I know who dislike C++, dislike it because they
believe it contains too many features (that cannot now be removed).
I know that I don't use the entire language, and neither do the people
that I work with (in fact, we have informal coding standards along the
lines of "avoid X, Y, and Z".)

>We still have a lot of other pressing problems, like how to incorporate
>persistance, and how to do good garbage collection, and how to at run time
>create objects whose type isn't known until after the program is running.

Don't hold your breath.  Adding persistence will be very hard, because
(if I understand the work going on at U Mass. to add persistence to
Modula-3) persistence is equivalent to having an accurate compacting
garbage collector.  Maybe you are using a different definition of
persistence.  There are other ways to implement garbage collection, so
adding that alone should be easier.  (It has been done for friendly
users, but there are still some hazards involving the optimizer that
people are working on).

David Chase
Sun
(dchase@eng.sun.com)

hwrvo@kato.lahabra.chevron.com (W.R. Volz) writes:
: In article <658@manutius.UUCP>, garyp@manutius.UUCP (Gary Powell) writes:
:
: .i.e, x (op)= y;  <==>   x = x (op) y;

Because x <= y is not the same as x = x < y.
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!altitude!ozrout!topoi!hendrik

In article <l6smdpINNjmc@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
|Those people that I know who dislike C++, dislike it because they
|believe it contains too many features (that cannot now be removed).

I am one of the people who thinks C++ has too many "features" --
[other people including myself would say "bugs"]

However, some of the these features/bugs CAN be successfully removed.

One of the "features" that I have formally proposed be removed is the
special case language preventing a few operators from being overloaded.
Its much easier to teach, program, remember, the language etc, if there
isn't a plethora of special case restrictions in the language.

If the language is implemented in an "orthogonal" manner [to the greatest
extent possible] then people can simply learn general rules, they do not
have to remember all these special cases.

People keep trying to argue against making the language orthogonal, people
keep arguing that I need to "prove" the benefits of trying to make the
langauge orthogonal.  This continues to amaze me.  Rather, I would expect
that a reasonable group of people would insist that anyone who wants to
defend special cases in the language would be required to show a great
burden of proof.  Each of those special cases represents an additional
"feature" that C++ programers have to try to learn, remember, and continually
program around.

Ok, Ok Ok...lets cut the relgion and get to the meat of the matter.

It appears to me that there are a large number of folks who want the following
new operators added to the language.

1) ||=

   where:  x ||= y   <==>  x = x || y

   Seems resonable as it matches all the "Blah"= operators.

2) &&=

   where:  x &&= y   <==>  x = x && y

   Also seems reasonable for the same issue as #1.


3) ===

   where x === y   <==> x = x == y

   I have more trouble looking at this one, but again it still fits the
   "blah"= operator rule.  So it maybe that I just haven't thought about
   it long enough. Anyway I recommend it.

4) some set of chars yet to be determined which bind tighter than the * and /
   for which x power y  is x raised to the power of y.

   This seems reasonable but again has the problem of what do we do with
   the odd ball arguments of y and x?

   I recommend we define it as an operator but leave its implementation alone
   and let everyone overload it as they see fit. And I don't care which
   set or single character is chosen. My reasoning is that the current
   arguments don't seem to be converging.  Maybe someone else (I'm sure I'll
   see heat on this one.) would care to summarize the arguments on this.

5) "."
   Lets add this.  I mean really, no one's code will break if we have it,
   the earth will not shake and the sky fall down.  If it turns out to be
   not as useful as Jim claims..so what?  We'll drop it from language "D"
   the next generation.

Any others I've missed???

Lets get on with it.  Like it or not many of us have to work with C++ even
though language "X" is better at some other task.  Lets add the features folks
clamor for.  IF they can make a convincing statement of "It won't break any
existing code. And it is possible for someone of resonable experience
programming to use it without shooting themselves in the foot."

We still have a lot of other pressing problems, like how to incorporate
persistance, and how to do good garbage collection, and how to at run time
create objects whose type isn't known until after the program is running.


BTW.
  Could you folks who want to argue language issues move your discussion over
to this group?  Then we can quit annoying the folks who want to compare
Borland to Mircosoft or ask the beginners questions. And I don't have
to read 100 or more messages to find the language issue ones.

PS
  You may flame me at will. I'm wearing my Nomax underware (By Dupont.)

  -Gary-


Gary Powell ------------+ Internet:     garyp@aldus.com
c/o Aldus Corporation   | uunet:        manutius!garyp@uunet.uu.net
411 1st Ave South       | uucp:         camco!manutius!garyp
Seattle, WA 98104  USA  | Voice:        (206) 622-5500