🚀 go-pugleaf

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