It Hurts When I Do This
in [Fortran]
|
Prev: compile errors, please help.
Next: A digression
From: GaryScott on 18 Apr 2008 16:14 On Apr 18, 1:32 pm, Clive Page <j...(a)main.machine> wrote: > In message > <9bfddca3-b45a-4649-ab77-1f894baec...(a)b64g2000hsa.googlegroups.com>, > GaryScott <garylsc...(a)sbcglobal.net> writes > > >It doesn't logically follow that to ask for a syntax for arrayness > >requires a syntax for any other attributes. The article makes it > >quite clear that it is a common thought process among programmers and > >a common pitfall. > > I for one don't agree. It may be a common pitfall among programmers > used to inferior languages such as C, C++, and Java which really don't > support much beyond simple scalar operations, but surely Fortran > programmers are used to being able to use the name of an array and have > it mean the entire array. This has been standard practice in many > statements (READ, WRITE, PRINT, CALL, DATA, SUBROUTINE, FUNCTION, etc) > since Fortran-II (I think), certainly since Fortran-IV/Fortran 66. > > The main change since then is that the whole-array notation was extended > to every other appropriate context, and especially to expressions and > assignments. Of course this change came in as recently as 1990. > > I really don't think that a new notation is required just because some > programmers are a bit slow to catch on to the new thought processes > required. Of course it doesn't help that so many other languages are > still stuck in the scalar era. Perhaps it's these that need a change of > syntax? > If they supported whole-array operations, as a modern language surely > should, the problem wouldn't arise. :-) > > -- > Clive Page Other languages with whole array syntax support it properly by including a syntax for consistently differentiating arrayness versus scalarness. In this single instance, Fortran has it wrong. It leads to ambiguous (actually hidden) meaning when humans are reading the code because it looks exactly like a scalar operation, a very different thing. Anyway, I wasn't intending to start an argument, but merely to point those interested in reading the latest edition of "Dr. Fortran".
From: glen herrmannsfeldt on 18 Apr 2008 16:43 GaryScott wrote: > http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-this/ > But we NEED a syntax that means "the entire array". Code should be > self documenting. Of course, I typically just name arrays so that > it's clear that it is an array (aArray, bArray, cArray), but it is > fairly natural to want to specify a wildcard indicating whole array > since it improves interpretability. It is available in other > languages that I've used in the past. Having read this thread backwards (my news reader is set to sort in decreasing time/date order) and then the referenced article, I agree with Steve. Note, though, that the (:) does indicate (the contents of) the entire array. As someone said, this will be more obvious to C, C++, and Java programmers, also not previously mentioned, R programmers. In Java you can say A=B; You get a copy of the Object reference, or as some say a shallow copy of the array, not a copy of the contents of the array. In C, an array name is a pointer to the array. It seems, then, that the lhs (:) can be used as a "don't reallocate" indicator. (I almost wrote operator!) Note that unlike all other array operations the "reallocate assignment" does NOT reference the whole array but the underlying data structure (pointer in C, object reference in Java (and, I believe C++)). It does what the => operator would otherwise do. Applying (:) to an unallocated array does not make sense, as the array doesn't have bounds to specify the whole array. I do wonder, without thinking the implications through, whether => could have been used for reallocation assignment. It seems consistent with the use of allocatable arrays and pointers in the ALLOCATE statement. Steve mentioned that some compilers don't generate the best code for (:) array assignment, but they are getting better. There is the complication in array assignment that the result be as if the entire rhs was evaluated before the lhs changed. In some cases this can require temporary arrays, in others the compiler might do it to be safe. In addition, note that it is common in mathematics and physics to use different notation for arrays (vectors, matrices, and tensors). -- glen
From: Richard Maine on 18 Apr 2008 16:54 GaryScott <garylscott(a)sbcglobal.net> wrote: > Other languages with whole array syntax support it properly by > including a syntax for consistently differentiating arrayness versus > scalarness. In this single instance, Fortran has it wrong. It leads > to ambiguous (actually hidden) meaning when humans are reading the > code because it looks exactly like a scalar operation, a very > different thing. I suppose it is just restating part of my previous post, and I suppose we are just going to continue to disagree about it, but I still don't understand why you think it important for there to be such a special syntax for arrays, but not for derived types. I perhaps exagerated the case in my prior post by extrapolating to all other attributes in an attempt to see where that direction might lead, but the case of a derived type seems awfully simillar to me and not an exageration or extrapolation. After all, a derived-type assignment can equally "hide" a simillar underlying meaning. In fact, a derived-type assignment can include array assignments within it (for array components). > Anyway, I wasn't intending to start an argument, but merely to point > those interested in reading the latest edition of "Dr. Fortran". That bit I quite agree with. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 18 Apr 2008 17:03 Clive Page wrote: > In message > <9bfddca3-b45a-4649-ab77-1f894baecb8d(a)b64g2000hsa.googlegroups.com>, > GaryScott <garylscott(a)sbcglobal.net> writes >> It doesn't logically follow that to ask for a syntax for arrayness >> requires a syntax for any other attributes. The article makes it >> quite clear that it is a common thought process among programmers and >> a common pitfall. > I for one don't agree. It may be a common pitfall among programmers > used to inferior languages such as C, C++, and Java which really don't > support much beyond simple scalar operations, but surely Fortran > programmers are used to being able to use the name of an array and have > it mean the entire array. Note that C, C++, and Java are consistent in the use of names and operations. In Java an array name is an Object reference and [] is the array element reference operator. I believe this is more consistent than Fortran where, for example, you can't subscript a function returning an array. In C, C++, and Java subscripting is an operator and can be applied to any array, including the return value of a function. C pointers and Java Object references are given the simpler notation. > This has been standard practice in many > statements (READ, WRITE, PRINT, CALL, DATA, SUBROUTINE, FUNCTION, etc) > since Fortran-II (I think), certainly since Fortran-IV/Fortran 66. I believe you could use PRINT for an entire array in Fortran II. (Fortran IV supported PRINT for backward compatibility.) What you couldn't do in Fortran II or Fortran IV (66) was use PRINT or WRITE for constants! > The main change since then is that the whole-array notation was extended > to every other appropriate context, and especially to expressions and > assignments. Of course this change came in as recently as 1990. I do believe, though, that reallocation assignment without a distinct notation was a mistake. In another post I suggested that => could have been used for reallocation assignment. > I really don't think that a new notation is required just because some > programmers are a bit slow to catch on to the new thought processes > required. Of course it doesn't help that so many other languages are > still stuck in the scalar era. Perhaps it's these that need a change of > syntax? > If they supported whole-array operations, as a modern language surely > should, the problem wouldn't arise. :-) In Java you can say A=B; You copy the Object reference not the array. -- glen
From: glen herrmannsfeldt on 18 Apr 2008 17:12
Richard Maine wrote: (snip) > I suppose it is just restating part of my previous post, and I suppose > we are just going to continue to disagree about it, but I still don't > understand why you think it important for there to be such a special > syntax for arrays, but not for derived types. I perhaps exagerated the > case in my prior post by extrapolating to all other attributes in an > attempt to see where that direction might lead, but the case of a > derived type seems awfully simillar to me and not an exageration or > extrapolation. After all, a derived-type assignment can equally "hide" a > simillar underlying meaning. In fact, a derived-type assignment can > include array assignments within it (for array components). I believe it is slightly more obvious that a derived type assignment apply to the whole structure than an array name for array assignment. This then reminds me that Fortran doesn't support structure operations. To be consistent, allow A=B+C; for both derived types (structures) and arrays, assuming that the operations makes sense. (You can't add arrays of CHARACTER, nor structures containing CHARACTER.) -- glen |