Timeline for Are there any primary sources for the “passing constant by reference” behavior in old Fortran compilers?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 28, 2021 at 3:12 | comment | added | texdr.aft | @another-dave Indeed. The only (modern) compiler I know of that provides citations in diagnostics is SBCL for Common Lisp. | |
| May 28, 2021 at 3:00 | comment | added | dave | @texdr.aft - Oh, duh: it's a reference to the Report. That's actually useful for an error message, | |
| May 28, 2021 at 2:27 | comment | added | texdr.aft | @another-dave Section 4.7.5.2 of the Algol 60 report: “A formal parameter which occurs as a left part variable in an assignment statement within the procedure body and which is not called by value can only correspond to an actual parameter which is a variable (special case of expression).” I missed this when looking through the report yesterday, but it nicely answers your original inquiry about whether a constant called by name can be assigned to. | |
| May 28, 2021 at 1:59 | comment | added | dave | @texdr.aft - kalgol reports "FAIL 001 IN SECT.4.7.5.2." at run time. As should be perfectly obvious :-), this means an invalid use of an expression called by name. 'SECT.4.7.5.2' is a fixed part of this error message, it does not refer to anything in the original program. Compiler module? Design spec? Documentation reference? No idea. Kalgol always was a little opaque. | |
| May 27, 2021 at 11:45 | comment | added | dave | @texdr.aft - I tried it out on walgol and got a FAIL 8 (Real assigned to integer actual parameter called by name) at run time. This was not the error I would have expected, others seem more appropriate, but nevertheless, it was detected. I'll try the same thing on kalgol. | |
| May 27, 2021 at 2:04 | comment | added | dave | Thanks; I was going to check that myself when I got around to it. | |
| May 27, 2021 at 1:19 | comment | added | texdr.aft | @another-dave A cursory reading of "Algol 60 Implementation" seems to indicate that in Randel and Russel's compiler you could modify a constant but it would be "local" to some extent; you can't globally affect the value of a constant. | |
| May 26, 2021 at 23:53 | comment | added | dave |
There must be an analogue in Algol-60 call by name arguments. Given procedure foo(a); a := 42; what happens in typical compilers if you write foo(0) ? I would hope the error is detected, preferable at compile time, otherwise at run time.
|
|
| May 26, 2021 at 23:48 | comment | added | dave | And therefore, I regard passing a reference to a writeable "one and only" instance of a constant as a compiler bug - understandable in the context of the times, and who am I to criticize the pioneers, giants that they were, but nevertheless, it's still an implementation decision that does not match language semantics. | |
| May 26, 2021 at 23:31 | comment | added | dave | Even in your grandfather's FORTRAN, the fact that a constant must be passed by reference does not imply that the reference has to be "the one and only" instance of that value. Load the constant into a scratch location (on the stack if you have a stack) and set the argument to point to it. | |
| May 26, 2021 at 23:01 | comment | added | supercat |
Would anything in the Standard forbid an implementation from passing foo the address of one storage location which was initialized to 1, and passing bar the address of another, or setting some storage location to 1 immediately before each call and passing its address?
|
|
| May 26, 2021 at 19:29 | comment | added | TooTea |
@alephzero But that's because you added the intent attribute, not because of Fortran 90+. Not specifying intent is perfectly standard conforming even in Fortran 2018, and in some situations it's the only reasonable option. (For example when interfacing with external non-Fortran libraries or in some cases of Fortran 2008 OOP code relying heavily on polymorphism.)
|
|
| May 26, 2021 at 18:50 | comment | added | alephzero | This is only correct if you write Fortran ignoring the standards from Fortran 90 to present. Here is a complete modern Fortran program (note, it is perfectly legal to write multiple statements on one line!) and the error message from gfortran: "1 | program main ; call sub(1) ; end program main ; subroutine sub(i) ; integer, intent(out) :: i ; i = 42 ; end subroutine sub" " | 1 Error: Non-variable expression in variable definition context (actual argument to INTENT = OUT/INOUT) at (1)" | |
| May 25, 2021 at 14:38 | history | edited | TooTea | CC BY-SA 4.0 |
added 36 characters in body
|
| May 25, 2021 at 12:26 | history | edited | TooTea | CC BY-SA 4.0 |
added 8 characters in body
|
| May 25, 2021 at 12:26 | review | First posts | |||
| May 25, 2021 at 12:38 | |||||
| May 25, 2021 at 12:20 | history | answered | TooTea | CC BY-SA 4.0 |