FDIS
in [Fortran]
|
Prev: g95 and FFTW
Next: calling a c function
From: Richard Maine on 23 Apr 2010 21:05 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Personally, I always liked statement functions, I dislike them. Hard to say whether they are better or worse than entry, both are so perverse. I can find no better word that perverse for the declaration of statement function arguments. You can't declare them in the statemement function itself, there being no place to do so. So unless you use implicit typing, you have to declare them in the host scope, where the declaration might or not declare 2 unrelated things of the same name (the statement function dumy argument and some unrelated thing in the host scope). Of course, if one routinely uses implicit typing, then that oddity doesn't show up. Perhaps that's part of why I dislike statememt functions. They look to have been designed by people who thought you should use implicit typing, with a hack thrown in as an afterthought just in case someone actually wanted a way to declare the types of the dummy arguments. The statement function dummy argument picks up some, but not all of the attributes declared in the host scope. For example, you might think that integer :: x(10) declared x to be a real array of size 10. If so, you'd be wrong where statement functions are involved. It declares x to be real, but the dimension part is ignored.... Hmm. Or I thought that's how it was. On checking the standard I'm not so sure. Maybe I'm confusing statement function dummy arguments with one of the few other things confusingly declared in the wrong scope. They all make sort of a confused mishmash in my mind. Hmm.... Looks like forall is like that, so I'm probably confusing the two. Don't ask me why they are different like that. Both forall index variables and statement function dummy arguments get their type declarations from the host scope. Both must be scalar. But in the case of forall, the host declaration can have other attributes that get ignored, while for statement functions, the host has to be scalar... Or maybe I'm just having trouble reading it, particularly as I know of no way to explicitly declare something to be scalar as is mentioned in a constraint even. Note the word "explicitly" in C1263; any process by which you deduce that something must be scalar because it has attributes incompatible with anything else would not count as explicit. In particular, not having a dimension specified in any of the many places where one can possibly specify one is about the opposite of explicit. That leaves me quite uncertain as to what that constraint is supposed to mean. Wouldn't shock me to find that an interp had fixed it after f2003, which is what I just checked... but I might have thought that a feature in the standard since f66 would have had at least its basics straight by now. Maybe it is because its basics are so confusing. Fortunately I don't have to figure it out as I don't use statement functions, and I don't write compilers. I wonder what compiler writers make of c1263, which they are required to diagnose violations of. > One feature that I might have thought could have been added > to statement functions is array arguments, and the next might > have been array return values. Those are the foremost of the examples I had in mind when I said that statement functions illustrated a disinclination to simultaneously extend and declare something obsolescent. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Richard Maine on 23 Apr 2010 21:35 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > > > Personally, I always liked statement functions, > > I dislike them. Hard to say whether they are better or worse than entry, > both are so perverse. > > I can find no better word that perverse for the declaration of statement > function arguments. Not to speak of the syntax being so confusingly like that of an assignment statement that even quite experienced users regularly confuse them, and compilers occasionally do so. That confusion would get worse if array returns were allowed as you suggested. I'm not even sure that it would be resolvable at all, but I am sure that even if technically possible, it would be confusing. There's no real danger of that becomming an issue though. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 23 Apr 2010 23:19 Richard Maine <nospam(a)see.signature> wrote: (snip regarding statement functions) > Not to speak of the syntax being so confusingly like that of an > assignment statement that even quite experienced users regularly confuse > them, and compilers occasionally do so. That confusion would get worse > if array returns were allowed as you suggested. I'm not even sure that > it would be resolvable at all, but I am sure that even if technically > possible, it would be confusing. There's no real danger of that > becomming an issue though. Well, the syntax for variable declarations has been changed along the way, though keeping the old forms. I wouldn't complain if a new form for statement function declaration were added. real, statement function :: fn(x)=x+1 -- glen
From: Richard Maine on 24 Apr 2010 01:39 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip regarding statement functions) > > > Not to speak of the syntax being so confusingly like that of an > > assignment statement that even quite experienced users regularly confuse > > them, and compilers occasionally do so. That confusion would get worse > > if array returns were allowed as you suggested. I'm not even sure that > > it would be resolvable at all, but I am sure that even if technically > > possible, it would be confusing. There's no real danger of that > > becomming an issue though. > > Well, the syntax for variable declarations has been changed > along the way, though keeping the old forms. I wouldn't complain > if a new form for statement function declaration were added. > > real, statement function :: fn(x)=x+1 Venturing yet further into the direction of expanding at the same time as making obsolescent... unless you are also arguing against making them obsolescent, which is what it really sounds like you are doing. That argument already was lost. Note also that if this is supposed to address the problems related to array return values not being easily workable with the existing syntax, then adding a different syntax would add one of the kinds of non-orthogonalities you were just complaining about - the allowable properties would depend on which of two different syntax forms you used to declare it. That's not really removing the non-orthogonality. Not quite sure why I bothered to respond. It ain't gonna happen regardless. As noted above, the argument about making them obsolescent already happened 20 or so years ago. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Ian Harvey on 24 Apr 2010 04:23
On 24/04/2010 11:05 AM, Richard Maine wrote: .... > The statement function dummy argument picks up some, but not all of the > attributes declared in the host scope. For example, you might think that > > integer :: x(10) > > declared x to be a real array of size 10. If so, you'd be wrong where > statement functions are involved. It declares x to be real, but the > dimension part is ignored.... I don't use statement functions either, but I would have picked x to be integer... |