[J3] [EXTERNAL] Re: Why is += missing?

[Van Snyder]

On Thu, 2021-08-26 at 17:35 +0000, Klemm, Michael via J3 wrote:
> May I throw in the Ada way of doing this:
>  
>                 A(i,j,k,l) := @ + B(i,j)

I proposed something a bit more general for Fortran, in a slightly
different form, in Section 2.15 of 03-258r1.

A name that has a scope that extends from its definition within a
statement, to the end of the statement, can be defined by following it
with a special symbol and then a variable or expression. That name
stands for that object (the variable, not its value, if it is a
variable) throughout its scope. Instead of

a(3*i+1) = b(3*i+1)

one could write

a ( s @ (3*i+1) ) = b ( s )

and of course

v @ a( s @(3*i+1) ) = v + b(s)

This is essentially a statement-scope version of the ASSOCIATE
construct -- but => cannot be used instead of @ because that would
conflict with pointer assignment. Maybe -> could be used.

Any use of "@"  might have a syntax conflict with its use to indicate
that a rank-1 array of size N denotes N consecutive subsctipts, as
Malcolm proposed at the Tokyo meeting after observing that the form I
proposed (without a special symbol) had a semantic ambiguity in the
case of a rank-1 size 1 array used to subscript a rank-1 array: Is the
result a scalar or an array of size 1? The proposed syntax did not,
however, have a name before the "@" -- so maybe there isn't a conflict.

>  
> which is a shorthand version of 
>  
>                 A(i,j,k,l) := A(i,j,k,l) + B(i,j)
>  
> This is from the Ada202x proposal at Target Name Symbols (ada-
> auth.org).
>  
> So, the idea is that the ‘@’ symbol stands-in for what’s on the LHS
> of the assignment.  That version would only introduce one additional
> symbol, have the same reduction of typing for the programmer, and
> would avoid the ambiguity of /=. 
>  
> Kind regards,
>         -michael
>  
> PS; Ada also uses /= for not equals.
>  
> PPS: I think the idea of the symbol is to resemble some visual
> correspondence to the mathematical way of writing “not equals” as a
> crossed out equals sign.
>  
> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf OfClune,
> Thomas L. (GSFC-6101) via J3
> Sent: Thursday, August 26, 2021 18:57
> To: General J3 interest list <j3 at mailman.j3-fortran.org>
> Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
> Subject: Re: [J3] [EXTERNAL] Re: Why is += missing?
>  
> [CAUTION: External Email] 
> While I agree that Fortran is intermediate between COBOL and raw C in
> terms of verbosity and clarity, my personal feeling is that it is not
> at the “sweet spot”.   Something like Java I think comes closer to
> the optimum of brevity and clarity.     (I don’t know many
> programming languages, so there could well be others that I would
> feel the same way about.)
>  
> Of course, it is rare to find a Fortran code that is anywhere near as
> “clear” as software ought to be.   My own code included.    If
> verbosity were only the worst of the sins …
>  
>  
>  
> From:J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3
> <j3 at mailman.j3-fortran.org>
> Reply-To: j3 <j3 at mailman.j3-fortran.org>
> Date: Thursday, August 26, 2021 at 11:47 AM
> To: j3 <j3 at mailman.j3-fortran.org>
> Cc: Van Snyder <van.snyder at sbcglobal.net>
> Subject: [EXTERNAL] Re: [J3] Why is += missing?
>  
> On Thu, 2021-08-26 at 12:03 +0000, Jeff Hammond via J3 wrote:
> > RB:
> >  
> > I agree with this idea.  I was thinking adding a “.” to make it
> > like element-wise ops in Matlab might be acceptable. I am willing
> > to add pretty much any character or character pair in order to
> > avoid duplicating array expressions.
>  
> For those of us who don't use C every day, writing a C program, or
> worse maintaining one written by someody else, requires keeping one
> eye on the code and one on the standard or your favorite textbook.
>  
> Fortran (Formula Translator) was originally designed to be as similar
> to mathematics as could be done with one-dimensional notation. Most
> people who write Fortran programs have been exposed to algebra. It
> shouldn't be necessary first to master C and Matlab.
>  
> Fortran is at a sweet spot between COBOL's extreme verbosity and the
> gibberish your old acoustically-coupled teletype machine used to make
> when the phone fell out of the coupler.
>  
> Here's an example of the latter:
>  
> #include <stdio.h>
> main(t,_,a)
> char *a;
> {
> return!0<t?t<3?main(-79,-13,a+main(-87,1-_,main(-86,0,a+1)+a)):
> 1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
> main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
> "@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#
> n+,/#\
> ;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
> q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw
> ' i;# \
> ){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
> iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
> ;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ')
> }+}{rl#'{n' ')#\
> }'+}##(!!/")
> :t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
> :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
> "!ek;dc i at bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m
> .vpbks,fxntdCeghiry"),a+1);
> }
>  
> Yes, this is a legal C program. Compile it and run it. It's actually
> a pleasant surprise. I dare you to reverse engineer it.
>  
> In this case, brevity is not the soul of wit.
>  
> >  
> > MK:
> >  
> > What happens to “a += b * c” is often optimized to an FMA if the
> > compiler flags or defaults allow ISO/IEEE violation.  You have to
> > talk nicely to GCC to get it to do it, whereas ICC will do it at -
> > O1 and above.
> >  
> > KH:
> >  
> > Yeah, ÷ is available on my Mac but I assume it’s Unicode.  I am not
> > advocating for the use of special characters in Fortran, but I
> > wanted to use it in this thread so as to not overload /= even if
> > it’s mostly obvious what I mean.
> >  
> > Jeff
> >  
> > From:J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Bader,
> > Reinhold via J3 <j3 at mailman.j3-fortran.org>
> > Date: Wednesday, August 25, 2021 at 5:29 PM
> > To: General J3 interest list <j3 at mailman.j3-fortran.org>
> > Cc: Bader, Reinhold <Reinhold.Bader at lrz.de>
> > Subject: Re: [J3] Why is += missing?
> > External email: Use caution opening links or attachments
> >  
> > Dear all, 
> >  
> > I think a separate syntax should be considered for these operations
> > if they are accepted as an addition to the language. e.g.  +.=, -.=
> > etc.
> > Wrt /= it is not only the semantic overlap that is an issue but
> > also the cognitive load on the programmer (prospective newby: “why
> > the damn has /= a different meaning than +=?”)
> >  
> > Also note that for a significant subset use of the associate
> > construct allows to often write
> >  
> > ASSOCIATE(X => something complicated)
> > ...
> >    X = X + Y
> > END ASSOCIATE
> >  
> > Regards
> > Reinhold
> >  
> > Von: J3 <j3-bounces at mailman.j3-fortran.org>Im Auftrag vonCarlson,
> > Neil via J3
> > Gesendet: Mittwoch, 25. August 2021 16:03
> > An: General J3 interest list <j3 at mailman.j3-fortran.org>
> > Cc: Carlson, Neil <nnc at lanl.gov>
> > Betreff: Re: [J3] Why is += missing?
> >  
> > Jeff's point here is spot on.  The point of "+=" isn't simply about
> > convenience.  It expresses intent.  A primary purposes of a high
> > level language is to support code that can be more easily
> > understood and reasoned about (by a human).  If your example is "a
> > = a + 1" then sure "+=" looks like insignificant syntactic sugar. 
> > But in his original example one has to carefully look at both sides
> > of the "=" to understand that the intent is to increment.  The
> > desire to have a complete set of such operators is obviously
> > understandable.  But it's not right that a difficulty posed by "/="
> > should derail them all ("perfect is the enemy of good") -- having
> > just "+=" and "-=" would be a major improvement to the language.
> >  
> > Neil
> >  
> > 
> > From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Jeff
> > Hammond via J3 <j3 at mailman.j3-fortran.org>
> > Sent: Wednesday, August 25, 2021 7:27 AM
> > To: General J3 interest list
> > Cc: Jeff Hammond
> > Subject: [EXTERNAL] Re: [J3] Why is += missing?
> >  
> > I will argue that it is syntactic sugar in the same sense that
> > multidimensional arrays are.  Below is the perfectly functional C
> > code I wrote to match my Fortran years ago (because computer
> > scientists don’t know their history).  There is no actual need for
> > multidimensional arrays in Fortran, just the practical difficulty
> > of not having them.
> >  
> > // t3(h3,h2,h1,p6,p5,p4)+=t1(p4,h1)*v2(h3,h2,p6,p5);
> > t3[h3+h3u*(h2+h2u*(h1+h1u*(p6+p6u*(p5+p5u*p4))))] += t1[p4+p4u*h1]
> > * v2[h3+h3u*(h2+h2u*(p6+p6u*p5))];
> >  
> > I think the relative usage of +=, -=, *=, ÷=, and **= if they were
> > added justifies the pragmatic solution of just doing += and -=,
> > which are more likely to have hardware support anyways.
> >  
> > Jeff
> >  
> > From:J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Steve
> > Lionel via J3 <j3 at mailman.j3-fortran.org>
> > Date: Wednesday, August 25, 2021 at 4:13 PM
> > To: j3 at mailman.j3-fortran.org <j3 at mailman.j3-fortran.org>
> > Cc: Steve Lionel <steve at stevelionel.com>
> > Subject: Re: [J3] Why is += missing?
> > External email: Use caution opening links or attachments
> >  
> > On 8/25/2021 8:07 AM, Jeff Hammond via J3 wrote:
> > > After 15 years as a Fortran programmer, I am still annoyed on a
> > > daily basis about the tedium imposed on me because Fortran lacks
> > > +=.
> > This was considered - there were a few requests for it in the 202X
> > survey we ran 2017-2018. I suspect it fell off the list because of
> > 1)  it is "syntactic sugar", not adding any new capability and 2)
> > the existing use of /= requiring some complicated exceptions. It
> > could be done, sure, but the demand seems low. We'll soon start the
> > process for 202Y features - feel free to put it forward then.
> >  
> > Steve
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210826/0536a8a8/attachment-0001.htm>