Home > Archive > Fortran > November 2007 > Allow interspersed named and positional arguments?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Allow interspersed named and positional arguments?
|
|
| Beliavsky 2007-11-27, 7:18 pm |
| In Fortran, all arguments in a call after the first named argument
must also be named, so that
subroutine foo(x1,x2,x3,x4,x5,x6)
! assume all arguments optional
....
call foo(a1,x3=a3,a4,x5=a5,x6)
is not allowed.
I wish it were allowed, with the interpretation that positional
arguments after named arguments are presumed to be the successive
arguments in the callee, until the next named argument appears, so
that the code above would be equivalent to
call foo(a1,x3=a3,x4=a4,x5=a5,x6=a6)
Making this change would not provide substantial new functionality,
but I think it would be convenient, and it does not seem too difficult
for compiler writers to implement.
| |
| Paul van Delst 2007-11-27, 7:18 pm |
| Beliavsky wrote:
> In Fortran, all arguments in a call after the first named argument
> must also be named, so that
>
> subroutine foo(x1,x2,x3,x4,x5,x6)
> ! assume all arguments optional
>
> ...
>
> call foo(a1,x3=a3,a4,x5=a5,x6)
>
> is not allowed.
(I'll assume that's true... I didn't check the std)
> I wish it were allowed,
Why?
> with the interpretation that positional
> arguments after named arguments are presumed to be the successive
> arguments in the callee, until the next named argument appears, so
> that the code above would be equivalent to
>
> call foo(a1,x3=a3,x4=a4,x5=a5,x6=a6)
Then write it that way.
> Making this change would not provide substantial new functionality,
> but I think it would be convenient, and it does not seem too difficult
> for compiler writers to implement.
I have no idea as to the ease or difficulty of implementing your suggestion (although I'd
bet it's not as simple as it may seem :o), but even you state "[m]aking this change would
not provide substantial new functionality".
So .... why do it? Is it *that* inconvenient to write "x4=a4" as opposed to just "a4"?
cheers,
paulv
| |
| Richard Maine 2007-11-27, 7:18 pm |
| Beliavsky <beliavsky@aol.com> wrote:
> call foo(a1,x3=a3,a4,x5=a5,x6)
>
> is not allowed.
>
> I wish it were allowed, with the interpretation...
....
> Making this change would not provide substantial new functionality,
> but I think it would be convenient, and it does not seem too difficult
> for compiler writers to implement.
I haven't thought much about the question. I might note that the one
area I would worry about complications in would be in generic
resolution. There are some "funny" rules right now about requirements
for the specific procedures in a generic. In particular, at least one of
the rules relates to the relative position of an argument that
disambiguate by position versus one that disambiguates by name. I
couldn't cite the exact rule without just looking it up and quoting it.
Anyway, I don't know that there would be extra complications there, as I
haven't spent the time to study that aspect in detail, but I can at
least see that there might be. I bet that rule depends on their being no
positional arguments after named ones. That's where I'd look anyway.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Fly Away 2007-11-27, 7:18 pm |
| > Making this change would not provide substantial new functionality,
> but I think it would be convenient, and it does not seem too difficult
> for compiler writers to implement.
Even though I have very little understanding about how all this stuff
works at the low lever I am almost certain that object files do not
contain any info about the original variables' names. With the
exception of procedures like open, close, etc. So at least for
external libraries there is no way to get enough information for your
suggestion to work.
| |
| Richard Maine 2007-11-27, 7:18 pm |
| Fly Away <victor.prosolin@gmail.com> wrote:
> Even though I have very little understanding about how all this stuff
> works at the low lever I am almost certain that object files do not
> contain any info about the original variables' names. With the
> exception of procedures like open, close, etc. So at least for
> external libraries there is no way to get enough information for your
> suggestion to work.
No, that is *NOT* an issue. You have to have an explicit interface for
anything like named arguments to work in the first place. That interface
provides all the necessary information. This is a compile-time thing
having nothing to do with object files. Sounds to me like you aren't
familliar with the existing f90 explicit interfaces and the things they
allow. That part is not new to Beliavsky's proposal.
I had some reservations, mentioned in my separate post, but they aren't
along this line. This part just isn't a problem.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Fly Away 2007-11-27, 7:18 pm |
| On Nov 27, 4:32 pm, nos...@see.signature (Richard Maine) wrote:
> Fly Away <victor.proso...@gmail.com> wrote:
>
> No, that is *NOT* an issue. You have to have an explicit interface for
> anything like named arguments to work in the first place. That interface
> provides all the necessary information. This is a compile-time thing
> having nothing to do with object files. Sounds to me like you aren't
> familliar with the existing f90 explicit interfaces and the things they
> allow. That part is not new to Beliavsky's proposal.
>
> I had some reservations, mentioned in my separate post, but they aren't
> along this line. This part just isn't a problem.
Now that I read the original post again, I admit that I completely
misunderstood it in the first place.
After looking at my .mod files I see that all my silly var names are
right in there...
Victor.
|
|
|
|
|