f



Is it possible to invoke a Unix command within Fortran 90 source code?

Hi, there.

I know it is pretty easy to invoke a Unix command within C code, but
it seems that no textbook has mentioned to invoke a Unix command
within Fortran code. So the question is "is it possible or not?"

Thank you in advance!

0
iamwuxin (18)
2/7/2008 11:02:47 AM
comp.lang.fortran 11941 articles. 2 followers. Post Follow

30 Replies
532 Views

Similar Articles

[PageSpeed] 47

On 7 feb, 12:02, hermitian <iamwu...@gmail.com> wrote:
> Hi, there.
>
> I know it is pretty easy to invoke a Unix command within C code, but
> it seems that no textbook has mentioned to invoke a Unix command
> within Fortran code. So the question is "is it possible or not?"
>
> Thank you in advance!

Yes, but it depends on your compiler. Most define some
function or subroutine like system() that allows you to
run an external command or program.

But it is not part of the standard, so you will have to
check the manual of your compiler and be prepared to
change the relevant code if you use another one.

Regards,

Arjen
0
arjen.markus (2628)
2/7/2008 11:07:01 AM
As Arjen said, the "system" command is an extension of standard
fortran.
The first argument is a string containing the command to execute.
As the string is a regular fortran string, you can put whatever you
want in it. It is therefore easy to construct it by using fortran
"internal files".
I use it everyday, for example to copy a file, based on "cp" under
Linux or "copy"
under windows :

  subroutine file_copy (sourcefn, targetfn, status )
    implicit none
    character(len=3DMAX_FILENAME), intent(in) :: sourcefn, targetfn
    integer, intent(out) , optional :: status
    integer :: local_status
    character (len=3DMAX_COMMAND_LENGTH) :: command
#ifdef _LINUX
    write ( command ,*) "cp ", trim(sourcefn), " ", trim(targetfn)
#else
    write ( command ,*) "copy ", trim(sourcefn), " ", trim(targetfn)
#endif
    call system ( command, local_status )
    if ( present ( status )) then
       status =3D local_status
    endif
  end subroutine file_copy

It is extremely useful !
The "system" command is included in the following compilers :
- Intel Fortran (8.0)
- g95
- gfortran

Best regards,

Micha=EBl
0
2/7/2008 11:29:03 AM
"relaxmike" <michael.baudin@gmail.com> wrote in message 
news:c5a0811a-6dde-40a6-a083-796205cafe51@j20g2000hsi.googlegroups.com...

<snip>
>    call system ( command, local_status )

Note some compilers have "system" as a function not a subroutine: (eg ifort 
v9 and above on Windows)
        status = system(command)

Other compilers may have a different spelling of "system"

Les 


0
l.neilson825 (106)
2/7/2008 12:45:15 PM
"Arjen Markus" <arjen.markus@wldelft.nl> wrote in message 
news:27a1cb20-194e-4226-b696-ace3558a22bc@m34g2000hsb.googlegroups.com...
> On 7 feb, 12:02, hermitian <iamwu...@gmail.com> wrote:
>> Hi, there.
>>
>> I know it is pretty easy to invoke a Unix command within C code, but
>> it seems that no textbook has mentioned to invoke a Unix command
>> within Fortran code. So the question is "is it possible or not?"
>>
>> Thank you in advance!
>
> Yes, but it depends on your compiler. Most define some
> function or subroutine like system() that allows you to
> run an external command or program.
>
> But it is not part of the standard, so you will have to
> check the manual of your compiler and be prepared to
> change the relevant code if you use another one.
>
> Regards,
>
> Arjen

    FWIW, Fortran 2008 will have a standard suboutine EXECUTE_COMMAND_LINE of 
the form:
EXECUTE_COMMAND_LINE( COMMAND, WAIT, EXITSTAT, CMDSTAT, CMDMSG )
    where:
COMMAND    is a scalar variable of type default character and its value is the 
command line to be executed.
WAIT             is an optional scalar variable of type default logical and 
determines whether the command operates synchronously or asynchronously.
EXITSTAT    is an optional scalar variable of type default integer and is 
assigned the value of the exit status if the command is executed synchronously.
CMDSTAT    is an optional scalar variable of type default integer and is 
assigned values that represent the completion status of the subroutine.
CMDMSG    is an optional scalar variable of type character and is assigned a 
processor-dependent error message of an error occurs.

    J3 paper 05-240r4 contains a complete description of this subroutine.

    I have no idea whether any current Fortran compilers have any plans to 
include the Fortran 2008 EXECUTE_COMMAND_LINE subroutine in versions in the near 
future.

-- 
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI   53008-0423
Voice:  (262) 783-5869
Fax:    (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cdedo@wi.rr.com> or <craig@ctdedo.com>

0
cdedo (127)
2/7/2008 1:55:01 PM
On Feb 7, 7:55=A0am, "Craig Dedo" <cd...@wi.rr.com> wrote:
> "Arjen Markus" <arjen.mar...@wldelft.nl> wrote in message
>
> news:27a1cb20-194e-4226-b696-ace3558a22bc@m34g2000hsb.googlegroups.com...
>
>
>
>
>
> > On 7 feb, 12:02, hermitian <iamwu...@gmail.com> wrote:
> >> Hi, there.
>
> >> I know it is pretty easy to invoke a Unix command within C code, but
> >> it seems that no textbook has mentioned to invoke a Unix command
> >> within Fortran code. So the question is "is it possible or not?"
>
> >> Thank you in advance!
>
> > Yes, but it depends on your compiler. Most define some
> > function or subroutine like system() that allows you to
> > run an external command or program.
>
> > But it is not part of the standard, so you will have to
> > check the manual of your compiler and be prepared to
> > change the relevant code if you use another one.
>
> > Regards,
>
> > Arjen
>
> =A0 =A0 FWIW, Fortran 2008 will have a standard suboutine EXECUTE_COMMAND_=
LINE of
> the form:
> EXECUTE_COMMAND_LINE( COMMAND, WAIT, EXITSTAT, CMDSTAT, CMDMSG )
> =A0 =A0 where:
> COMMAND =A0 =A0is a scalar variable of type default character and its valu=
e is the
> command line to be executed.
> WAIT =A0 =A0 =A0 =A0 =A0 =A0 is an optional scalar variable of type defaul=
t logical and
> determines whether the command operates synchronously or asynchronously.
> EXITSTAT =A0 =A0is an optional scalar variable of type default integer and=
 is
> assigned the value of the exit status if the command is executed synchrono=
usly.
> CMDSTAT =A0 =A0is an optional scalar variable of type default integer and =
is
> assigned values that represent the completion status of the subroutine.
> CMDMSG =A0 =A0is an optional scalar variable of type character and is assi=
gned a
> processor-dependent error message of an error occurs.
>
> =A0 =A0 J3 paper 05-240r4 contains a complete description of this subrouti=
ne.
>
> =A0 =A0 I have no idea whether any current Fortran compilers have any plan=
s to
> include the Fortran 2008 EXECUTE_COMMAND_LINE subroutine in versions in th=
e near
> future.

Don't like the overly verbose spelling, but wonderful...on windows,
need a value that specifies whether an annoying DOS box flashes on the
screen or not as the command is processed.  By default, in most
implementations, a command prompt window is opened prior to execution
of a command regardless of whether the command writes anything or not
to the window.  This can be suppressed through an API call, but it is
extremely annoying when not desired.

>
> --
> Craig Dedo
> 17130 W. Burleigh Place
> P. O. Box 423
> Brookfield, WI =A0 53008-0423
> Voice: =A0(262) 783-5869
> Fax: =A0 =A0(262) 783-5928
> Mobile: (414) 412-5869
> E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>- Hide quoted text -
>
> - Show quoted text -

0
garylscott (1355)
2/7/2008 3:12:55 PM
Arjen Markus writes:

> hermitian wrote:

>> I know it is pretty easy to invoke a Unix command within C code, but
>> it seems that no textbook has mentioned to invoke a Unix command
>> within Fortran code. So the question is "is it possible or not?"

> Yes, but it depends on your compiler. Most define some
> function or subroutine like system() that allows you to
> run an external command or program.
>
> But it is not part of the standard, so you will have to
> check the manual of your compiler and be prepared to
> change the relevant code if you use another one.

Herein lies an interesting, and perhaps semantic, argument.  For example,
I could state that a solution to Kepler's equation is also not part of the
Fortran standard, yet I can write one using standard-conforming code, put
it in a function, add it to a library, and use it with any compiler on any
system that I choose to move it to.  The invocation of a "system" routine,
in all the cases with which I'm familiar, is done using standard-conforming
syntax, so one could argue that the call *is* part of the standard.  The
problem is that you don't have the source code for it, so you can't move it
to another system should you choose to do so, thus it might be better to
call it "non-portable" rather than "non-standard".  But on the other hand,
one might expect a standard-conforming program to be compatible with any
standard-supporting compiler, yet many standard-supporting compilers could
not in fact generate an executable program for such a standard-conforming
program, so there is a strong temptation to call the program "non-standard".

How do the veterans treat such a situation?  Do you call the program
non-standard or non-portable?  Again, we're dealing with a situation in
which a program has been written using entirely standard-conforming
statements and syntax, but calling a system-supplied routine.

0
tholen (16675)
2/7/2008 7:28:20 PM
tholen@antispam.ham wrote:

(snip)

> Herein lies an interesting, and perhaps semantic, argument.  For example,
> I could state that a solution to Kepler's equation is also not part of the
> Fortran standard, yet I can write one using standard-conforming code, put
> it in a function, add it to a library, and use it with any compiler on any
> system that I choose to move it to.  The invocation of a "system" routine,
> in all the cases with which I'm familiar, is done using standard-conforming
> syntax, so one could argue that the call *is* part of the standard.  The
> problem is that you don't have the source code for it, so you can't move it
> to another system should you choose to do so, thus it might be better to
> call it "non-portable" rather than "non-standard".  
(snip)

The call is either to a Fortran compatible system() routine, or to a C
compatible routine through C interoperability.  In general, the system()
function can't be written using standard, operating system independent,
Fortran.

-- glen

0
gah (12851)
2/8/2008 12:10:33 AM
glen herrmannsfeldt writes:

>> Herein lies an interesting, and perhaps semantic, argument.  For example,
>> I could state that a solution to Kepler's equation is also not part of the
>> Fortran standard, yet I can write one using standard-conforming code, put
>> it in a function, add it to a library, and use it with any compiler on any
>> system that I choose to move it to.  The invocation of a "system" routine,
>> in all the cases with which I'm familiar, is done using standard-conforming
>> syntax, so one could argue that the call *is* part of the standard.  The
>> problem is that you don't have the source code for it, so you can't move it
>> to another system should you choose to do so, thus it might be better to
>> call it "non-portable" rather than "non-standard".  

> The call is either to a Fortran compatible system() routine, or to a C
> compatible routine through C interoperability.  In general, the system()
> function can't be written using standard, operating system independent,
> Fortran.

But the call to it can be written using standard Fortran.  So one could
argue that the program (meaning the source code) is standard conforming.
Yet it is definitely not portable.

And that was the issue I was interested in seeing discussed.  One could
argue that the program is standard-conforming and prefer to call it
non-portable, while others could argue that the program is non-standard
and call it that.

How would the veterans describe such a program and why?

0
tholen (16675)
2/8/2008 12:30:17 AM
In article <47aba299$0$6514$4c368faf@roadrunner.com>, tholen@antispam.ham writes:
> glen herrmannsfeldt writes:
> 
> >> Herein lies an interesting, and perhaps semantic, argument.  For example,
> >> I could state that a solution to Kepler's equation is also not part of the
> >> Fortran standard, yet I can write one using standard-conforming code, put
> >> it in a function, add it to a library, and use it with any compiler on any
> >> system that I choose to move it to.  The invocation of a "system" routine,
> >> in all the cases with which I'm familiar, is done using standard-conforming
> >> syntax, so one could argue that the call *is* part of the standard.  The
> >> problem is that you don't have the source code for it, so you can't move it
> >> to another system should you choose to do so, thus it might be better to
> >> call it "non-portable" rather than "non-standard".  
> 
> > The call is either to a Fortran compatible system() routine, or to a C
> > compatible routine through C interoperability.  In general, the system()
> > function can't be written using standard, operating system independent,
> > Fortran.
> 
> But the call to it can be written using standard Fortran.  So one could
> argue that the program (meaning the source code) is standard conforming.
> Yet it is definitely not portable.
> 
> And that was the issue I was interested in seeing discussed.  One could
> argue that the program is standard-conforming and prefer to call it
> non-portable, while others could argue that the program is non-standard
> and call it that.
> 
> How would the veterans describe such a program and why?

Actually, this concept has been throughly thrashed out in the
standards world.  The basic answer is go back and read Glen's
response:  the program is not conformant with the Fortran standard.

To see why, it is critical to notice that the use of the term
conformant is actually specified in the Fortran standard.  From a
draft of the Fortran 2003 standard:

     A program is a standard-conforming program if it uses only
     those forms and relationships described herein and if the
     program has an interpretation according to this standard.

Since the program uses a procedure (system, in your scenario) that
does not have an interpretation specified by the Fortran standard,
it does not conform.  Furthermore, as noted by Glan, you can't
write a procedure such as system using only facilities specified
in the Fortran standard.

I will note in passing that even though Fortran 2003 includes a
mechanism for "Interoperability with C," your program using system
would not be conformant (IMHO) even if you wrote the system procedure
in C.  The reason is that the Fortran standard provides an
interpretation for how to interoperate, but not for what the C or
C-like procedures do (except for certain aspects of procedures such
as exit).

I will also note that your argument about

> >>                                      The invocation of a "system" routine,
> >> in all the cases with which I'm familiar, is done using standard-conforming
> >> syntax, so one could argue that the call *is* part of the standard.

is also in error because the standard also says:

     This standard does not specify

	(4) The program and processor behavior when this standard
	    fails to establish an interpretation except ...
	    [irrelevant exception].

 - dmw

-- 
..   Douglas Wells             .  Connection Technologies      .
..   Internet:  -sp9804- -at - contek.com-                     .
0
see105 (51)
2/8/2008 5:06:42 AM
Douglas Wells writes:

>> glen herrmannsfeldt wrote:

>>>> Herein lies an interesting, and perhaps semantic, argument.  For example,
>>>> I could state that a solution to Kepler's equation is also not part of the
>>>> Fortran standard, yet I can write one using standard-conforming code, put
>>>> it in a function, add it to a library, and use it with any compiler on any
>>>> system that I choose to move it to.  The invocation of a "system" routine,
>>>> in all the cases with which I'm familiar, is done using standard-conforming
>>>> syntax, so one could argue that the call *is* part of the standard.  The
>>>> problem is that you don't have the source code for it, so you can't move it
>>>> to another system should you choose to do so, thus it might be better to
>>>> call it "non-portable" rather than "non-standard".  

>>> The call is either to a Fortran compatible system() routine, or to a C
>>> compatible routine through C interoperability.  In general, the system()
>>> function can't be written using standard, operating system independent,
>>> Fortran.

>> But the call to it can be written using standard Fortran.  So one could
>> argue that the program (meaning the source code) is standard conforming.
>> Yet it is definitely not portable.

>> And that was the issue I was interested in seeing discussed.  One could
>> argue that the program is standard-conforming and prefer to call it
>> non-portable, while others could argue that the program is non-standard
>> and call it that.

>> How would the veterans describe such a program and why?

> Actually, this concept has been throughly thrashed out in the
> standards world.  The basic answer is go back and read Glen's
> response:  the program is not conformant with the Fortran standard.

But what constitutes "the program"?  The executable file?  Presumably
not, but that is where the code to run "system" resides.  The source
code?  The source includes just a call to a subprogram using standard-
conforming syntax.

> To see why, it is critical to notice that the use of the term
> conformant is actually specified in the Fortran standard.  From a
> draft of the Fortran 2003 standard:
>
>     A program is a standard-conforming program if it uses only
>     those forms and relationships described herein and if the
>     program has an interpretation according to this standard.
>
> Since the program uses a procedure (system, in your scenario) that
> does not have an interpretation specified by the Fortran standard,
> it does not conform.

In my scenario, I also compared the program to another one that uses a
procedure to solve Kepler's equation.  Suppose that procedure was
provided to a programmer in a library of object code (which is how
the intrinsic procedures are usually provided).  How is the programmer
supposed to know whether that procedure has "an interpretation specified
by the Fortran standard" or not, and therefore allows the program to be
described as standard-conforming or not?

> Furthermore, as noted by Glan, you can't
> write a procedure such as system using only facilities specified
> in the Fortran standard.

That's not at issue.  But if a programmer is given a library of routines
that can be used in a Fortran program, how is the programmer supposed to
know which of those library routines was written with facilities specified
in the Fortran standard and which were not?

> I will note in passing that even though Fortran 2003 includes a
> mechanism for "Interoperability with C," your program using system
> would not be conformant (IMHO) even if you wrote the system procedure
> in C.  The reason is that the Fortran standard provides an
> interpretation for how to interoperate, but not for what the C or
> C-like procedures do (except for certain aspects of procedures such
> as exit).
>
> I will also note that your argument about

>>>>                                      The invocation of a "system" routine,
>>>> in all the cases with which I'm familiar, is done using standard-conforming
>>>> syntax, so one could argue that the call *is* part of the standard.

> is also in error because the standard also says:
>
>     This standard does not specify
>
>	(4) The program and processor behavior when this standard
>	    fails to establish an interpretation except ...
>	    [irrelevant exception].

It seems as though the meaning of "interpretation" is open to interpretation.

It basically sounds as though you're saying that for a program to be
standard conforming, it must include the source code (written in
standard conforming Fortran) for every procedure that is not listed
as an intrinsic procedure in the standard.  Otherwise, I don't see
any guaranteed way to distinguish between a call to "system" or a call
to "kepler".

It brings back memories of a situation about a decade ago when I purposely
avoided using extensions to make my program "standard conforming", but then
to solve a problem that the user of the program had, it was necessary to add
a call to GETENV to access an environment variable.  So in the end, the
program turned out to be non-standard anyway.

0
tholen (16675)
2/8/2008 9:25:40 AM
> But what constitutes "the program"? [...] The source includes just a
> call to a subprogram using standard- conforming syntax.

The standard of the call is not the problem. The problem is that this
program:

-----------------------------------
  program foo
    call system ("ls")
  end progra foo
-----------------------------------

is not standard-conforming because it calls an external subroutine called
SYSTEM (which is external because there is no intrinsic subroutine of
this name) but SYSTEM is not defined. It is invalid, as is the following:

-----------------------------------
  program foo
    call xxxxxxx ()
  end progra foo
-----------------------------------

The standard rules how a processor (in the usual view, that processor is
composed of a complete chain: the compiler-linker-OS-CPU) deals with
Fortran programs. It has no concept of executable code.

-- 
FX
0
coudert (470)
2/8/2008 9:56:13 AM
> But what constitutes "the program"? [...] The source includes just a
> call to a subprogram using standard- conforming syntax.

The syntax of the call is not the problem. The problem is that this
program:

-----------------------------------
  program foo
    call system ("ls")
  end progra foo
-----------------------------------

is not standard-conforming because it calls an external subroutine called
SYSTEM (which is external because there is no intrinsic subroutine of
this name) but SYSTEM is not defined. It is invalid, as is the following:

-----------------------------------
  program foo
    call xxxxxxx ()
  end progra foo
-----------------------------------

The standard rules how a processor (in the usual view, that processor is
composed of a complete chain: the compiler-linker-OS-CPU) deals with
Fortran programs. It has no concept of executable code.

-- 
FX

0
coudert (470)
2/8/2008 9:56:13 AM
FX writes:

>> But what constitutes "the program"? [...] The source includes just a
>> call to a subprogram using standard- conforming syntax.

> The standard of the call is not the problem. The problem is that this
> program:
>
> -----------------------------------
>  program foo
>    call system ("ls")
>  end progra foo
> -----------------------------------
>
> is not standard-conforming because it calls an external subroutine called
> SYSTEM (which is external because there is no intrinsic subroutine of
> this name) but SYSTEM is not defined. It is invalid, as is the following:
>
> -----------------------------------
>  program foo
>    call xxxxxxx ()
>  end progra foo
> -----------------------------------

I hope it's not because you misspelled "program" in the final statement.

> The standard rules how a processor (in the usual view, that processor is
> composed of a complete chain: the compiler-linker-OS-CPU) deals with
> Fortran programs. It has no concept of executable code.

Is the following non-standard:

program foo
  real a,b,c
  call xxxxxxx (a,b,c)
end program foo

subroutine xxxxxxx(a,b,c)
  real a,b,c
  c = a + b
  return
end subroutine xxxxxxx

If it is standard-conforming, why is this version standard-conforming
and your version invalid?

0
tholen (16675)
2/8/2008 10:15:09 AM
On 8 f=E9v, 11:15, tho...@antispam.ham wrote:
> FX writes:
> >> But what constitutes "the program"? [...] The source includes just a
> >> call to a subprogram using standard- conforming syntax.
> > The standard of the call is not the problem. The problem is that this
> > program:
>
> > -----------------------------------
> >  program foo
> >    call system ("ls")
> >  end progra foo
> > -----------------------------------
>
> > is not standard-conforming because it calls an external subroutine calle=
d
> > SYSTEM (which is external because there is no intrinsic subroutine of
> > this name) but SYSTEM is not defined. It is invalid, as is the following=
:
>
> > -----------------------------------
> >  program foo
> >    call xxxxxxx ()
> >  end progra foo
> > -----------------------------------
>
> I hope it's not because you misspelled "program" in the final statement.
>
> > The standard rules how a processor (in the usual view, that processor is=

> > composed of a complete chain: the compiler-linker-OS-CPU) deals with
> > Fortran programs. It has no concept of executable code.
>
> Is the following non-standard:
>
> program foo
>   real a,b,c
>   call xxxxxxx (a,b,c)
> end program foo
>
> subroutine xxxxxxx(a,b,c)
>   real a,b,c
>   c =3D a + b
>   return
> end subroutine xxxxxxx
>
> If it is standard-conforming, why is this version standard-conforming
> and your version invalid?

I prefer to be pragmatic : my program is standard-conforming when it
runs identically on all the platforms my users work on.

As most of my FORTRAN softwares may call the routine SYSTEM somewhere,
and as I consider that my programs are standard conforming (with my
definition of course), then your program is standard conforming too
(more exactly FJ-standard conforming ;-) )

Notice that I use my own pre-processor (which must be standard
conforming too) to pre-process routines calling external functions
like SYSTEM. Here is my "best" wrapper of SYSTEM :

      SUBROUTINE TBSYST(COMAND)
C&P
C&P   S. Matteo 06/99
C&F
C&F   call to system function to execute a command
C&F
%IF f95 nagf95
      USE F90_UNIX_PROC,ONLY : SYSTEM
%ENDIF

      CHARACTER*(*) COMAND
%IF watcom
      INCLUDE 'FSUBLIB.FI'
      ISTAT=3DFSYSTEM(COMAND)
      IF (ISTAT.LT.0)THEN
        WRITE(6,*) 'TBSYST : problem in running command status =3D
',ISTAT
      ENDIF
%ELSEIF lf95
%IF linux
      ISTAT=3DSYSTEM(COMAND)
      IF (ISTAT.LT.0)THEN
        WRITE(6,*) 'TBSYST : problem in running command status =3D
',ISTAT
      ENDIF
%ELSE
      CALL SYSTEM(COMAND)
%ENDIF
%ELSE
      CALL SYSTEM(COMAND)
%ENDIF
      END


0
2/8/2008 11:01:30 AM
tholen@antispam.ham wrote:
> glen herrmannsfeldt writes:
> 
>>> Herein lies an interesting, and perhaps semantic, argument.  For example,
>>> I could state that a solution to Kepler's equation is also not part of the
>>> Fortran standard, yet I can write one using standard-conforming code, put
>>> it in a function, add it to a library, and use it with any compiler on any
>>> system that I choose to move it to.  The invocation of a "system" routine,
>>> in all the cases with which I'm familiar, is done using standard-conforming
>>> syntax, so one could argue that the call *is* part of the standard.  The
>>> problem is that you don't have the source code for it, so you can't move it
>>> to another system should you choose to do so, thus it might be better to
>>> call it "non-portable" rather than "non-standard".  
> 
>> The call is either to a Fortran compatible system() routine, or to a C
>> compatible routine through C interoperability.  In general, the system()
>> function can't be written using standard, operating system independent,
>> Fortran.
> 
> But the call to it can be written using standard Fortran.  So one could
> argue that the program (meaning the source code) is standard conforming.
> Yet it is definitely not portable.
> 
> And that was the issue I was interested in seeing discussed.  One could
> argue that the program is standard-conforming and prefer to call it
> non-portable, while others could argue that the program is non-standard
> and call it that.
> 
> How would the veterans describe such a program and why?
> 

I hesitate to describe myself as a veteran :) but I'd say it was 
standard, non-portable code - assuming your version of SYSTEM follows 
the standard Fortran rules. Normally they do, but not always 
(Salford/Silverfrost routines of this sort always have an @ on the end 
which is an illegal character for a routine name in standard Fortran. 
Dead useful when porting to another compiler - you can see instantly 
what the compiler-specific library routines are).

When it comes down to it, almost all non-trivial programs are 
non-portable - the moment you do anything with directories or filenames, 
you're filesystem-dependent. I certainly wouldn't describe a program as 
non-standard because it was set up to put a backslash between a 
directory path and a filename. But there are many systems on which it 
wouldn't run if that string was used in an OPEN statement.

My personal definition would be that it's standard code if it will 
compile on a standard-conforming compiler set up to error on anything 
non-standard. It's portable if the resulting program will run and 
produce the correct results :) So it's possible (and common) for a 
program to be both standard and non-portable. It's also possible (but a 
lot less common) for a program to be non-standard but portable. Use of 
IMPLICIT NONE, lower case, or variable names longer than 6 characters, 
in the later days of Fortran 77, would have fit the second category to 
all intents and purposes.

-- 
Catherine Rees Lay

Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57
0
2/8/2008 11:05:56 AM
In article <47ac2013$0$6492$4c368faf@roadrunner.com>, tholen@antispam.ham writes:

> > Actually, this concept has been throughly thrashed out in the
> > standards world.  The basic answer is go back and read Glen's
> > response:  the program is not conformant with the Fortran standard.

> But what constitutes "the program"?  The executable file?  Presumably
> not, but that is where the code to run "system" resides.  The source
> code?  The source includes just a call to a subprogram using standard-
> conforming syntax.

Remember that you originally brought up the point as to whether a
program was non-standard.  The context was Fortran, so the question
here is what is "the Fortran program."  And, again, that question is
explicitly addressed by the Fortran standard:

     A "program" is one or more "program-units," exactly one of
     which is a "main-program."  A "program-unit" is a "main-program"
     or an "external-subprogram" or a "module" or "block-data."
     And then each of those terms is precisely defined.

> In my scenario, I also compared the program to another one that uses a
> procedure to solve Kepler's equation.  Suppose that procedure was
> provided to a programmer in a library of object code (which is how
> the intrinsic procedures are usually provided).  How is the programmer
> supposed to know whether that procedure has "an interpretation specified
> by the Fortran standard" or not, and therefore allows the program to be
> described as standard-conforming or not?

Whether and how the programmer knows is irrelevant to your original
question about whether the program is conformant or not.  It either
is or is not conformant based on the contents of the library (and
the rest of the program) and nothing else.  I will note in passing
that object code and executables are not relevant here:  only
Fortran source programs can be conformant to the Fortran standard
(at least to the part that defines programs).  (Although we do
often speak loosely about a standard-conforming executable programs
that have been created from standard-conformant Fortran source
programs by a standard-conformant Fortran processors.)

> > Furthermore, as noted by Glan, you can't
> > write a procedure such as system using only facilities specified
> > in the Fortran standard.

> That's not at issue.  But if a programmer is given a library of routines
> that can be used in a Fortran program, how is the programmer supposed to
> know which of those library routines was written with facilities specified
> in the Fortran standard and which were not?

Sorry, but it appears to me to be exactly the issue you originally
raised.  BTW. I found another section of the standard that appears
to be relevant here:

     A standard-conforming program shall not use nonstandard
     intrinsic procedures or modules that have been added by the
     processor.

Now to be practical, the provider of a library will often tell you
whether it is conformant or not.  Also, many compilers include
switches or options that will perform appropriate checks.

> It seems as though the meaning of "interpretation" is open to interpretation.

Yes, it is, but so is the rest of life.

You should look at the Fortran standard as a legal document.  It
can be (and often is) included as a reference in contracts.  The
"final" Interpretation is done in a court proceeding usually based
on the testimony of "experts."  You've already getting (non-binding)
interpretations by some of those experts in their daily responses
to questions in this newsgroup.  Listen to them and heed them.

> It basically sounds as though you're saying that for a program to be
> standard conforming, it must include the source code (written in
> standard conforming Fortran) for every procedure that is not listed
> as an intrinsic procedure in the standard.  Otherwise, I don't see
> any guaranteed way to distinguish between a call to "system" or a call
> to "kepler".

You've got it.  You may not like the resulting situation, but
you've expressed it properly.

> It brings back memories of a situation about a decade ago when I purposely
> avoided using extensions to make my program "standard conforming", but then
> to solve a problem that the user of the program had, it was necessary to add
> a call to GETENV to access an environment variable.  So in the end, the
> program turned out to be non-standard anyway.

Look, there's no nirvana associated with a program being
standard-conformant.  It's a best practice sort of thing.  If I
have a choice between two programs, only one of which is
standard-conformant, I'm going to choose the standard-conformant
one -- other things being equal.  On the other hand, if I find that
there is an option to use a non-conformant library that produces
correct results and will save me 3 days on a week-long run, I'm
likely to choose that non-conformant library.

 - dmw

-- 
..   Douglas Wells             .  Connection Technologies      .
..   Internet:  -sp9804- -at - contek.com-                     .
0
see105 (51)
2/8/2008 3:29:29 PM
<tholen@antispam.ham> wrote in message 
news:47ac2013$0$6492$4c368faf@roadrunner.com...
> Douglas Wells writes:
>>> glen herrmannsfeldt wrote:
>>>>> Herein lies an interesting, and perhaps semantic, argument.  For example,
>>>>> I could state that a solution to Kepler's equation is also not part of the
>>>>> Fortran standard, yet I can write one using standard-conforming code, put
>>>>> it in a function, add it to a library, and use it with any compiler on any
>>>>> system that I choose to move it to.  The invocation of a "system" routine,
>>>>> in all the cases with which I'm familiar, is done using 
>>>>> standard-conforming
>>>>> syntax, so one could argue that the call *is* part of the standard.  The
>>>>> problem is that you don't have the source code for it, so you can't move 
>>>>> it
>>>>> to another system should you choose to do so, thus it might be better to
>>>>> call it "non-portable" rather than "non-standard".
>
>>>> The call is either to a Fortran compatible system() routine, or to a C
>>>> compatible routine through C interoperability.  In general, the system()
>>>> function can't be written using standard, operating system independent,
>>>> Fortran.
>
>>> But the call to it can be written using standard Fortran.  So one could
>>> argue that the program (meaning the source code) is standard conforming.
>>> Yet it is definitely not portable.
>
>>> And that was the issue I was interested in seeing discussed.  One could
>>> argue that the program is standard-conforming and prefer to call it
>>> non-portable, while others could argue that the program is non-standard
>>> and call it that.
>
>>> How would the veterans describe such a program and why?

    The answer is:  It depends on how system() or any other procedure is defined 
and implemented.  See below.

    It appears that several readers of this newsgroup have incorrect ideas about 
standards conformance and related issues.  See my explanation below.

>> Actually, this concept has been throughly thrashed out in the
>> standards world.  The basic answer is go back and read Glen's
>> response:  the program is not conformant with the Fortran standard.

    This is incorrect.  See below.

> But what constitutes "the program"?  The executable file?  Presumably
> not, but that is where the code to run "system" resides.  The source
> code?  The source includes just a call to a subprogram using standard-
> conforming syntax.

    "Program" is defined in the Fortran standard.  See below.

>> To see why, it is critical to notice that the use of the term
>> conformant is actually specified in the Fortran standard.  From a
>> draft of the Fortran 2003 standard:
>>
>>     A program is a standard-conforming program if it uses only
>>     those forms and relationships described herein and if the
>>     program has an interpretation according to this standard.
>>
>> Since the program uses a procedure (system, in your scenario) that
>> does not have an interpretation specified by the Fortran standard,
>> it does not conform.

    This is incorrect.  See below.

> In my scenario, I also compared the program to another one that uses a
> procedure to solve Kepler's equation.  Suppose that procedure was
> provided to a programmer in a library of object code (which is how
> the intrinsic procedures are usually provided).  How is the programmer
> supposed to know whether that procedure has "an interpretation specified
> by the Fortran standard" or not, and therefore allows the program to be
> described as standard-conforming or not?

    It is not necessary that a procedure has an interpretation according to the 
standard if some other conditions are met.  See below.

>> Furthermore, as noted by Glan, you can't
>> write a procedure such as system using only facilities specified
>> in the Fortran standard.
>
> That's not at issue.  But if a programmer is given a library of routines
> that can be used in a Fortran program, how is the programmer supposed to
> know which of those library routines was written with facilities specified
> in the Fortran standard and which were not?

    The programmer does not need to know this.  See below.

>> I will note in passing that even though Fortran 2003 includes a
>> mechanism for "Interoperability with C," your program using system
>> would not be conformant (IMHO) even if you wrote the system procedure
>> in C.  The reason is that the Fortran standard provides an
>> interpretation for how to interoperate, but not for what the C or
>> C-like procedures do (except for certain aspects of procedures such
>> as exit).
>>
>> I will also note that your argument about
>
>>>>>                                      The invocation of a "system" routine,
>>>>> in all the cases with which I'm familiar, is done using 
>>>>> standard-conforming
>>>>> syntax, so one could argue that the call *is* part of the standard.
>
>> is also in error because the standard also says:
>>
>>     This standard does not specify
>>
>> (4) The program and processor behavior when this standard
>>     fails to establish an interpretation except ...
>>     [irrelevant exception].
>
> It seems as though the meaning of "interpretation" is open to interpretation.

    Incorrect.  If words and phrases do not have a specific definition within 
the Fortran standard, then you use their correct meaning in standard American 
English, as is acceptable in high-quality business and technical usage. 
Unfortunately for those who use non-English human languages, the English 
language edition of the standard is the official text in case there are 
conflicts between it and translations into other languages.  The English 
language edition uses the American dialect, not the British.

> It basically sounds as though you're saying that for a program to be
> standard conforming, it must include the source code (written in
> standard conforming Fortran) for every procedure that is not listed
> as an intrinsic procedure in the standard.  Otherwise, I don't see
> any guaranteed way to distinguish between a call to "system" or a call
> to "kepler".

    This is incorrect.

> It brings back memories of a situation about a decade ago when I purposely
> avoided using extensions to make my program "standard conforming", but then
> to solve a problem that the user of the program had, it was necessary to add
> a call to GETENV to access an environment variable.  So in the end, the
> program turned out to be non-standard anyway.

    There are several related issues regarding the defintion of standard 
conformance and other issues.  I will try to clear up as much of the confusion 
as I can.

    All quotations are from the Fortran 2003 standard.  Earlier editions have 
been cancelled and replaced.  This is standard ISO practice.

    Standards conformance is governed by section 1.5.  **ALL** of the rules in 
1.5 are needed in order to determine exactly what standards conformance 
requires.  The first paragraph of section 1.5 says:
[Begin quote]
A program (2.2.1) is a standard-conforming program if it uses only those forms 
and relationships described herein and if the program has an interpretation 
according to this standard.  A program unit (2.2) conforms to this standard if 
it can be included in a program in a manner that allows a program to be standard 
conforming.
[End of quote]

    The last sentence of section 1.5, par. 4 addresses the issue of use of 
intrinsic procedures.  It says, "A standard-conforming program shall not use 
nonstandard intrinsic procedures or modules that have been added by the 
processor."

    "Program" is defined in section 2.2.1.
[Begin quote]
A program consists of exactly one main program, any number (including zero) of 
other kinds of program units, and any number (including zero) of external 
procedures and other entities defined by means other than Fortran.
[End of quote]

    "External procedure" is defined in section 2.2.3.1.
[Begin quote]
An external procedure is a procedure that is defined by an external subprogram 
or by means other than Fortran.  An external procedure may be invoked by the 
main program or by any procedure of a program.
[End of quote]

    "Intrinsic procedure" is defined in section 12.1.2.1.
[Begin quote]
A procedure that is provided as an inherent part of theprocessor is an intrinsic 
procedure.
[End of quote]

    Taken together, these definitions mean that it is possible for a 
standard-conforming program to call an external procedure written in another 
language.  This is explicitly authorized by the definition of "program" in 
sectoion 2.2.1.

    This includes all libraries that are provided by third-party software 
vendors or are part of an operating system API.  Thus programs that make calls 
to such procedures are standard-conforming, even though such libraries are often 
written in such languages as C, C++, or C#.  However, if you have to include 
non-standard syntax in order to make such calls work, then the program is not 
standard-conforming.  A good example of that last point is all of the extra 
non-standard syntax that is usually needed in order to make calls to the 
Microsoft Windows API procedures.

    Is a reference to a system() procedure standard-conforming?  Yes.  Whether 
system() is a function or a subroutine, the reference always follows the rules 
defined in section 12.4, "Procedure reference".

    Is the use of a system() procedure standard-conforming?  It depends on 
whether system() is defined as an intrinsic procedure or an external procedure. 
If it is an external procedure, then the use is standard-conforming.  If it is 
an intrinsic procedure, then the use is not standard-conforming.

    Similarly, the use of and a call to kepler() is standard-conforming if 
kepler() is an external procedure that is defined solely by standard-conforming 
Fortran and/or references external procedures defined by means other than 
Fortran.

    Hope this helps.  Comments, questions, and constructive criticism are 
welcome.

-- 
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI   53008-0423
Voice:  (262) 783-5869
Fax:    (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cdedo@wi.rr.com> or <craig@ctdedo.com>

0
cdedo (127)
2/8/2008 3:45:32 PM
Douglas Wells <see@signature.invalid> wrote:

> Remember that you originally brought up the point as to whether a
> program was non-standard.  The context was Fortran, so the question
> here is what is "the Fortran program."  And, again, that question is
> explicitly addressed by the Fortran standard:
> 
>      A "program" is one or more "program-units," exactly one of
>      which is a "main-program."  A "program-unit" is a "main-program"
>      or an "external-subprogram" or a "module" or "block-data."
>      And then each of those terms is precisely defined.

At least in f2003, the definition of a program also includes "and any
number (including zero) of external procedures and other entities
defined by means other than Fortran."

But there is a quote that I'd say was more to the point. In 1.5,
Conformance.

  "A standard-conforming program shall not use nonstandard intrinsic
procedures or modules that have beeen added by the processor."

That seems about as direct and explicit as could be imagined. Oh yes,
and a "nonstandard intrinsic procedure" is any one that isn't defined in
the standard; there isn't any room to wiggle and claim that one somehow
is standard because the call to it uses standard syntax.

(Oh, I later saw that you also found that quote, but I decided to leave
the above comentary in just to emphasize the point).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain
0
nospam47 (9747)
2/8/2008 4:26:56 PM
fj <francois.jacq@irsn.fr> wrote:

> I prefer to be pragmatic : my program is standard-conforming when it
> runs identically on all the platforms my users work on.

Ouch!

I vehemently disagree with that definition. It is one that has gotten
many, many people in trouble in the past. I might say that a major
reasoin to have a standard at all is so that people don't have to rely
on a definition like that.

I cannot count the times that I have heard people complain that their
code was fine because it ran on all the systems they tried before, so it
must be a fault of this new one because

  1. Variables didn't always retain their values (the SAVE attribute).

  2. Variables didn't start out initialized at zero.

  3. The byte sex was different.

  4. The data representation was otherwise different.

  5. Record size wasn't measured in 32-bit words.

  6. Zero-trip DO loops act differently (in a way that is now actually
      required by the standfard.)

  7. Any of a zillion syntax extensions wasn't accepted.
 
  etc.

Perhaps you phrased it in a manner that came over differently than what
you meant. But I simply could not disagree more with what you actually
said above. Most of my 40 years of experience in Fortran tells me that
this definition isn't pragmatic at all; it is a prescription for all but
guaranteed failure. I've spent an awful lot of time over those 40 years
fixing codes that used this definition... and thus later needed fixing,
sometimes almost complete rewrites. Just because a program works on all
the platforms your users are using today, with teh compilers they have
today - that doesn't do much to guarantee that they will work tomorrow.
History shows far too many exceptions. If you think that such history is
all in the past and has no lesson for the future, well... so did many of
the people involved in the past history; they were wrong.

> As most of my FORTRAN softwares may call the routine SYSTEM somewhere,
> and as I consider that my programs are standard conforming (with my
> definition of course), then your program is standard conforming too
> (more exactly FJ-standard conforming ;-) )

I certainly also use things like SYSTEM in many of my codes. I'm not
saying you shouldn't use it. But "standard conforming" is a lot more
useful concept when you actually use the proper definition instead of
making one up. The definition isn't "what I use."

When I document the conformance of my codes, I don't stop at "this code
is standard conforming" - unless that hjappens to be true, which it
usually isn't on codes of substantial size. The documentation usually
includes a list of exceptions to standard conformance, as well as
assumptions made by the code that don't necessarily make it
nonconforming.

I'd recommend rereading some of Douglas Wells' comments here. He seems
to have a good understanding of the issues. In particular, note the bit
about standard conformance not being a panacea. You don't have to hide
in embarassment for having a nonstandard code, and redefine terms like
"standard conformance" to hide the embarassing fact. Nor does the fact
that many of your programs (and mine as well) don't fully conform to the
standard mean that the standard is worthless to you.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain
0
nospam47 (9747)
2/8/2008 4:26:56 PM
Richard Maine wrote:

> fj <francois.jacq@irsn.fr> wrote:

>>I prefer to be pragmatic : my program is standard-conforming when it
>>runs identically on all the platforms my users work on.

> Ouch!

> I vehemently disagree with that definition. It is one that has gotten
> many, many people in trouble in the past. 
(snip of good reasons)

In addition, there are many ways that the standard allows conforming
programs to differ in their output.  Many of them are in the formatted
output routines, such that even with otherwise identical results one
can't do a simple compare on the output files.  Besides differences
in output routines for identical internal values, different systems
may round differently within the standard.

-- glen

0
gah (12851)
2/8/2008 4:49:43 PM
On 8 f=E9v, 17:26, nos...@see.signature (Richard Maine) wrote:
> fj <francois.j...@irsn.fr> wrote:
> > I prefer to be pragmatic : my program is standard-conforming when it
> > runs identically on all the platforms my users work on.
>
> Ouch!
>
> I vehemently disagree with that definition. It is one that has gotten
> many, many people in trouble in the past. I might say that a major
> reasoin to have a standard at all is so that people don't have to rely
> on a definition like that.

I was expecting such reaction, especially from you ... and I globally
agree with you. I made this remark mainly for joking.

But as any joke, it keeps a part of truth. As the standard (including
F2003) does not define how to interact with the operating system (an
effort has been carried out with arguments and environment variables
but this is not sufficient), it is practically impossible to write a
full FORTRAN application strictly portable. Then developers have the
choice between :
- implementing a part of the application in using another language
(C,Java, Python ...),
- accepting compiler extensions and using for instance a SYSTEM
intrinsic procedure.


0
2/8/2008 7:24:09 PM
In article <1ibzf1s.1xsoj7g1fx3vv1N%nospam@see.signature>, nospam@see.signature (Richard Maine) writes:
> Douglas Wells <see@signature.invalid> wrote:

> >      A "program" is one or more "program-units," exactly one of
> >      which is a "main-program."  A "program-unit" is a "main-program"
> >      or an "external-subprogram" or a "module" or "block-data."
> >      And then each of those terms is precisely defined.

> At least in f2003, the definition of a program also includes "and any
> number (including zero) of external procedures and other entities
> defined by means other than Fortran."

I had noticed that and had purposely ignored it since it appeared
to me that such entities couldn't be included in a standard-conforming
program.  My reasoning was that the Fortran standard didn't provide
an "interpretation" for such entities.  In particular, I can find
nothing that defines the execution of non-C procedures, and the
description of the C-interface explains that the procedures need
not be defined by C:

     Fortran provides a means of referencing procedures that are
     defined by means of the C programming language or procedures
     that can be described by C prototypes as defined in 6.7.5.3
     of the C International Standard, even if they are not actually
     defined by means of C.

The resulting procedure is thus not well-defined and the effect
of such a procedure is not well specified (a reasonable expectation
for "interpretation" (IMHO)).

I still believe that to be a valid interpretation of the words in
the current standard, but, in retrospect, I doubt that was the
intent of the standards committee.  Rather, I suspect that the
intent was some combination of:

1) the behavior of non-Fortran components is irrelevant to the
   conformance of Fortran programs, and/or,

2) the behavior of components accessed via the C interoperability
   facility is subject to interpretation via the C standard (and
   the note about "... not actually defined by ..." should be
   relegated to a non-normative note), and/or,

3) the behavior of non-Fortran components is implementation-defined
   (and should be explicitly called out in a conformance document
   by the vendor).

Fortran seems to be blazing the standards path for defining
interoperability with other languages, but other language standards
do take positions in his area.

Ada, which doesn't actually define conformance for programs, goes
with option 3).

COBOL goes with 1) and explicitly includes the note:

     NOTE The inclusion of non-COBOL components in the run unit
          does not affect the conformance of the run unit.

I did find a comment in the Fortran standard (in annex C.9.2, which
is non-normative) that seems to hint that the Fortran committee
intended option 1), but I would suggest that any such intent should
be cleared up in a future version of the standard or a Technical
Corrigendum.

 - dmw

-- 
..   Douglas Wells             .  Connection Technologies      .
..   Internet:  -sp9804- -at - contek.com-                     .
0
see105 (51)
2/8/2008 10:33:06 PM
In article <47ac791e$0$30717$4c368faf@roadrunner.com>, "Craig Dedo" <cdedo@wi.rr.com> writes:
> <tholen@antispam.ham> wrote in message 
> news:47ac2013$0$6492$4c368faf@roadrunner.com...
> > Douglas Wells writes:

>     It appears that several readers of this newsgroup have incorrect ideas about 
> standards conformance and related issues.  See my explanation below.

First, let me note that I do not doubt that your response might
express the intent of the Fortran standard committee, but I do
doubt that the words in the standard are as brightly distinguished
as your response might indicate.

> >> Actually, this concept has been throughly thrashed out in the
> >> standards world.  The basic answer is go back and read Glen's
> >> response:  the program is not conformant with the Fortran standard.
> 
>     This is incorrect.  See below.
>
> >> Since the program uses a procedure (system, in your scenario) that
> >> does not have an interpretation specified by the Fortran standard,
> >> it does not conform.
> 
>     This is incorrect.  See below.

>     It is not necessary that a procedure has an interpretation according to the 
> standard if some other conditions are met.  See below.

> > It seems as though the meaning of "interpretation" is open to interpretation.
> 
>     Incorrect.  If words and phrases do not have a specific definition within 
> the Fortran standard, then you use their correct meaning in standard American 
> English, as is acceptable in high-quality business and technical usage. 
> Unfortunately for those who use non-English human languages, the English 
> language edition of the standard is the official text in case there are 
> conflicts between it and translations into other languages.  The English 
> language edition uses the American dialect, not the British.

Yes, but you haven't here established that the use of the American
English word "interpretation" doesn't require sufficient definition
to enable a reasonably unambiguous implementation.  I, as a native
speaker of American English, would expect more precision.  I will
also note that the C standards committee seems to believe that
their "interpretation of programs written in the C programming
language" includes a specification of "the semantic rules for
interpreting C programs."

>     Standards conformance is governed by section 1.5.  **ALL** of the rules in
> 1.5 are needed in order to determine exactly what standards conformance
> requires.  The first paragraph of section 1.5 says:

Yes, standards are to be interpreted according to the totality of
the wording of the standard, but a standard may include multiple
foci.  For example, the wording of section 1.5 suggests that the
Fortran standard is addressing three separate and distinct types
of conformance:  programs, program units, and processors.  Thus,
when the standard implies a definition (e.g., "A program is a
standard-conformant program if ...") and that definition is not
contradicted elsewhere, it is reasonable to assume that the
particular definition is complete.

>     Hope this helps.  Comments, questions, and constructive criticism are 
> welcome.

Again, I don't doubt that you have expressed the intent of the
standards committee, but I still believe my interpretation is a
reasonable interpretation of a standards document.  I have provided
suggestions elsewhere in this thread for clearing up the intent
of the standard.  In particular, if the standard is intended to
allow arbitrary non-Fortran programs in a standard-conformation
programs, it should explicitly say so (as COBOL does).

As a final note, I have finally discovered and closely examined
the final paragraph of Section 1.5, which says:

     Because a standard-conforming program may place demands on a
     processor that are not within the scope of this standard or
     may include standard items that are not portable, such as
     external procedures defined by means other than Fortran,
     conformance to this standard does not ensure that a program
     will execute consistently on all or any standard-conforming
     processors.

Yes, this normative paragraph does provide the additional evidence
that appropriately modifies the first sentence of Section 1.5, and
I accept that your interpretation in this thread is the one intended
by the standards committee -- but please clean up the wording in
the standard.

 - dmw

-- 
..   Douglas Wells             .  Connection Technologies      .
..   Internet:  -sp9804- -at - contek.com-                     .
0
see105 (51)
2/8/2008 11:42:13 PM
On Feb 8, 7:45 am, "Craig Dedo" <cd...@wi.rr.com> wrote:

>     Incorrect.  If words and phrases do not have a specific
> definition within the Fortran standard, then you use their
> correct meaning in standard American English, as is
> acceptable in high-quality business and technical usage.

While that might be a goal of the committee, it is certainly
not true of the standard as written.  There are many words
used by the standard for which the standard does not provide a
definition and yet are not used in the sense of standard
American English.  For example, the words "positive" and
"negative" are not defined in the Fortran standard.  In normal
American English, the word "positive" when applied to a number
means a number whose value is greater than zero.  The word
"negative" when applied to a number means a number whose value
is less than zero.  The phrases "positive zero" and
"negative zero" are nonsense phrases.  (Note that the IEEE
floating-point standard does not use the phrases "positive
zero" and "negative zero.")  The committee appears to take
the attitude that when the standard uses a term or phrase that
makes no sense in standard American English, it is up to the
reader to intuit what the committee meant.

Bob Corbett

Bob Corbett
0
2/9/2008 6:46:28 AM
<robert.corbett@sun.com> wrote in message 
news:319a0f18-de04-49fc-bcee-778e9b9be440@v4g2000hsf.googlegroups.com...
> On Feb 8, 7:45 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>
>>     Incorrect.  If words and phrases do not have a specific
>> definition within the Fortran standard, then you use their
>> correct meaning in standard American English, as is
>> acceptable in high-quality business and technical usage.
>
> While that might be a goal of the committee, it is certainly
> not true of the standard as written.  There are many words
> used by the standard for which the standard does not provide a
> definition and yet are not used in the sense of standard
> American English.  For example, the words "positive" and
> "negative" are not defined in the Fortran standard.  In normal
> American English, the word "positive" when applied to a number
> means a number whose value is greater than zero.  The word
> "negative" when applied to a number means a number whose value
> is less than zero.  The phrases "positive zero" and
> "negative zero" are nonsense phrases.  (Note that the IEEE
> floating-point standard does not use the phrases "positive
> zero" and "negative zero.")  The committee appears to take
> the attitude that when the standard uses a term or phrase that
> makes no sense in standard American English, it is up to the
> reader to intuit what the committee meant.
>
> Bob Corbett
>
> Bob Corbett
positiv, negativ--allerdings wichtig.

Kann sich der Syntax trauen, wenn man nicht mal an Arizona heran is?


-- 
Gerry Ford

"The apple was really a peach."
-- Allison Dunn on the garden of eden 


0
invalid163 (956)
2/9/2008 7:02:49 AM
robert.corbett@sun.com wrote:
> On Feb 8, 7:45 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>
>>     Incorrect.  If words and phrases do not have a specific
>> definition within the Fortran standard, then you use their
>> correct meaning in standard American English, as is
>> acceptable in high-quality business and technical usage.
>
> While that might be a goal of the committee, it is certainly
> not true of the standard as written.  There are many words
> used by the standard for which the standard does not provide a
> definition and yet are not used in the sense of standard
> American English.  [...]

Different professions have different specialized terminology that,
while based on natural language, is not identical in meaning to
the natural language origin.  Doctors speak a variety of Latin (at
least for body parts, illnesses, and such).  Most of the words
would have had only informally similar meanings in the pre-medical
Latin that centuries of doctors have adapted.  Doctors need to be
able to make subtle distinctions that ordinary language doesn't
allow - or would you rather be dead?

Computing is a newer profession, but it has its own specialized
language too.  The committee should not aim at American English,
but at "American Computer English".  To be sure, it should use
as little of the colloquialisms as possible.  But there's no sense
trying to avoid the relatively common industry wide terms and
conventions.  It allows considerably less verbose presentation
while still being clear to most of the intended readers.

> [...]                             For example, the words "positive" and
> "negative" are not defined in the Fortran standard.  In normal
> American English, the word "positive" when applied to a number
> means a number whose value is greater than zero.  The word
> "negative" when applied to a number means a number whose value
> is less than zero.  The phrases "positive zero" and
> "negative zero" are nonsense phrases.  (Note that the IEEE
> floating-point standard does not use the phrases "positive
> zero" and "negative zero.")  [...]

But, those phrases are quite common and throughout the computing
profession.  As you know if you've taken Abstract Algebra courses,
there isn't just one kind of arithmetic, there are several kinds.  There
are groups, rings, fields, etc.  And kinds of arithmetic that have some
of the properties of several of those categories.  IEEE floating point
is an example:  a well defined kind of arithmetic that manages (fairly
well) to compromise between simulating continuous reals while
being efficiently implementable on digital hardware.

Like most forms of arithmetic, IEEE float has a set of values and
defines some operations on those values.  In this case, the set of
values is finite, the operations are closed on the set (neither of those
properties are universal to all kinds of arithmetic).  From a human
perspective it's of value to have names for things - especially those
that have special properties or properties that differ from "ordinary
arithmetic" that you learned in grammar school.

In this context, terms like "positive zero" and "negative zero" are
the phrases coined (pretty much industry wide) for two well defined
values that both correspond to the grammar school notion of zero.
The Fortran committee didn't invent the terms.

> [...]                   The committee appears to take
> the attitude that when the standard uses a term or phrase that
> makes no sense in standard American English, it is up to the
> reader to intuit what the committee meant.

If it does that (and I believe that is sometimes does) it is the job
of the committee to fix that defect in the document.  But, things
like "negative zero" aren't examples of the problem.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare 


0
jamesgiles (2210)
2/9/2008 6:16:20 PM
James Giles wrote:

> robert.corbett@sun.com wrote:
> 
>>On Feb 8, 7:45 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>>
>>
>>>    Incorrect.  If words and phrases do not have a specific
>>>definition within the Fortran standard, then you use their
>>>correct meaning in standard American English, as is
>>>acceptable in high-quality business and technical usage.
>>
>>While that might be a goal of the committee, it is certainly
>>not true of the standard as written.  There are many words
>>used by the standard for which the standard does not provide a
>>definition and yet are not used in the sense of standard
>>American English.  [...]
> 
> 
> Different professions have different specialized terminology that,
> while based on natural language, is not identical in meaning to
> the natural language origin.  Doctors speak a variety of Latin (at
> least for body parts, illnesses, and such).  Most of the words
> would have had only informally similar meanings in the pre-medical
> Latin that centuries of doctors have adapted.  Doctors need to be
> able to make subtle distinctions that ordinary language doesn't
> allow - or would you rather be dead?
> 
> Computing is a newer profession, but it has its own specialized
> language too.  The committee should not aim at American English,
> but at "American Computer English".  To be sure, it should use
> as little of the colloquialisms as possible.  But there's no sense
> trying to avoid the relatively common industry wide terms and
> conventions.  It allows considerably less verbose presentation
> while still being clear to most of the intended readers.
> 

My own "american computer english" terminology is heavily influenced by 
particular hardware vendors of yore (IBM, Harris, Gould, Control Data). 
  It often annoys me to see reinvented UNIX terminology used in place of 
the "prior art".  Especially when UNIX terminology often sounds like it 
was invented by a student hacker-mentality rather than someone studied 
in the subject matter.

<snip>
-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford
0
garylscott (1355)
2/9/2008 11:50:40 PM
> Different professions have different specialized terminology that,
> while based on natural language, is not identical in meaning to
> the natural language origin.  Doctors speak a variety of Latin (at
> least for body parts, illnesses, and such).

Actually, anatomy is almost exclusively latin-derived in its vocabulary, 
while illnesses (if they aren't named for a person) a mostly greek. A 
case in point is the spleen: you have an arteria lienalis, but suffer 
from splenomegalia.

	Jan
0
2/10/2008 11:19:09 AM
Douglas Wells writes:

>>> Actually, this concept has been throughly thrashed out in the
>>> standards world.  The basic answer is go back and read Glen's
>>> response:  the program is not conformant with the Fortran standard.

>> But what constitutes "the program"?  The executable file?  Presumably
>> not, but that is where the code to run "system" resides.  The source
>> code?  The source includes just a call to a subprogram using standard-
>> conforming syntax.

> Remember that you originally brought up the point as to whether a
> program was non-standard.  The context was Fortran, so the question
> here is what is "the Fortran program."  And, again, that question is
> explicitly addressed by the Fortran standard:
>
>     A "program" is one or more "program-units," exactly one of
>     which is a "main-program."  A "program-unit" is a "main-program"
>     or an "external-subprogram" or a "module" or "block-data."
>     And then each of those terms is precisely defined.

But in this case, the "program" doesn't include the source code to the
external subprogram "system", so one might be led to conclude that
"system" isn't part of the "program".  The call to "system", of course,
is part of the program, but that part of the program is written with
standard-conforming statements.

>> In my scenario, I also compared the program to another one that uses a
>> procedure to solve Kepler's equation.  Suppose that procedure was
>> provided to a programmer in a library of object code (which is how
>> the intrinsic procedures are usually provided).  How is the programmer
>> supposed to know whether that procedure has "an interpretation specified
>> by the Fortran standard" or not, and therefore allows the program to be
>> described as standard-conforming or not?

> Whether and how the programmer knows is irrelevant to your original
> question about whether the program is conformant or not.  It either
> is or is not conformant based on the contents of the library (and
> the rest of the program) and nothing else.

Yes, but the question is WHY a program is conformant or not.  Someone
posted a program foo that involved a call to a subroutine xxxxxxx, and
said that the program was "invalid", presumably meaning non-conformant.
In response, I posted a program foo that involved a call to a subroutine
xxxxxxx, the primary difference being that I included the source code to
the subroutine xxxxxxx, and asked if its inclusion made the program
comformant.  I didn't see any response to that question.

> I will note in passing
> that object code and executables are not relevant here:  only
> Fortran source programs can be conformant to the Fortran standard
> (at least to the part that defines programs).  (Although we do
> often speak loosely about a standard-conforming executable programs
> that have been created from standard-conformant Fortran source
> programs by a standard-conformant Fortran processors.)

Maybe I'm not making myself clear, but if object code and executables
are not relevant, then the only thing relevant must be the source code,
and the question is, what is it about a call, written using standard
conforming syntax, to "system" that makes the program (the source code)
non-conformant?  Is it the absence of conformat source code to "system"?
It might surprise a beginning programmer that a program written entirely
using standard-conforming syntax could be non-standard.

The reason I'm asking is because I have historically referred to such
programs as standard-conforming but non-portable, because of the presence
of a call that isn't one of the intrinsics that the standard requires to
be available.  If my usage has been incorrect, then I need to change my
practice.  But if I change my practice, I want to get it right.  What I'm
looking for is the sort of definition of "standard conforming program"
that a teacher would give to a class of students learning Fortran, and
not the sort of technical wording used by the standard itself.

>>> Furthermore, as noted by Glan, you can't
>>> write a procedure such as system using only facilities specified
>>> in the Fortran standard.

>> That's not at issue.  But if a programmer is given a library of routines
>> that can be used in a Fortran program, how is the programmer supposed to
>> know which of those library routines was written with facilities specified
>> in the Fortran standard and which were not?

> Sorry, but it appears to me to be exactly the issue you originally
> raised.

I can assure you that it was never the issue I raised.  The issue I
raised dealt with when to call a program non-standard and when to call
it non-portable.  Some excellent points have been made about portability
being a problem because of filesystem inconsistencies between processors,
such that any program that opens files could be called non-portable.

> BTW. I found another section of the standard that appears
> to be relevant here:
>
>     A standard-conforming program shall not use nonstandard
>     intrinsic procedures or modules that have been added by the
>     processor.

Does the standard go on to define what a "nonstandard intrinsic
procedure" is?  Is it any intrinsic procedure that isn't listed in the
standard?  Or is it any intrinsic procedure that isn't written using
standard-conforming Fortran?  Presumably it means the former, but
consistent usage of "standard" could point to the latter.

> Now to be practical, the provider of a library will often tell you
> whether it is conformant or not.  Also, many compilers include
> switches or options that will perform appropriate checks.

>> It seems as though the meaning of "interpretation" is open to interpretation.

> Yes, it is, but so is the rest of life.
>
> You should look at the Fortran standard as a legal document.  It
> can be (and often is) included as a reference in contracts.  The
> "final" Interpretation is done in a court proceeding usually based
> on the testimony of "experts."  You've already getting (non-binding)
> interpretations by some of those experts in their daily responses
> to questions in this newsgroup.  Listen to them and heed them.

But there's a good reason why the standard itself isn't used as a
textbook for a class in Fortran programming.  A more basic understanding
is needed for a foundation on which students can build for a more
advanced understanding.

>> It basically sounds as though you're saying that for a program to be
>> standard conforming, it must include the source code (written in
>> standard conforming Fortran) for every procedure that is not listed
>> as an intrinsic procedure in the standard.  Otherwise, I don't see
>> any guaranteed way to distinguish between a call to "system" or a call
>> to "kepler".

> You've got it.  You may not like the resulting situation, but
> you've expressed it properly.

It's not a matter of like or dislike.  Rather, it's a matter of trying
to understand what makes a program standard or non-standard.  If my
description above is accurate, that's the sort of description I could
use on a class of students.

>> It brings back memories of a situation about a decade ago when I purposely
>> avoided using extensions to make my program "standard conforming", but then
>> to solve a problem that the user of the program had, it was necessary to add
>> a call to GETENV to access an environment variable.  So in the end, the
>> program turned out to be non-standard anyway.

> Look, there's no nirvana associated with a program being
> standard-conformant.  It's a best practice sort of thing.  If I
> have a choice between two programs, only one of which is
> standard-conformant, I'm going to choose the standard-conformant
> one -- other things being equal.  On the other hand, if I find that
> there is an option to use a non-conformant library that produces
> correct results and will save me 3 days on a week-long run, I'm
> likely to choose that non-conformant library.

In a work for hire situation where the employer doesn't care whether
the program will run on somebody's else system, I agree.  And in my
case, the program written a decade ago was expected to be in that
category.  But now, a decade later, I've been contacted by someone
that wants to reuse the code for a different project.  Suddenly reuse
of code becomes important.  Fortunately, I suspect that more compilers
support access to environment variables now than did a decade ago.

0
tholen (16675)
2/12/2008 11:57:41 PM
Richard Maine wrote:
> You don't have to hide
> in embarassment for having a nonstandard code, and redefine terms like
> "standard conformance" to hide the embarassing fact. Nor does the fact
> that many of your programs (and mine as well) don't fully conform to the
> standard mean that the standard is worthless to you.
> 

Cath's First Law Of Consultancy:

The degree to which a given set of code is a) standard-conforming, and 
b) portable, is inversely proportional to the vehemence with which the 
customer insists that it is.

I know that the standard is black-and-white on this - either a program 
is standard conforming or it isn't, there is no degree. But, in 
practice, how many different ways it isn't standard-conforming / 
portable makes a huge difference to the effort required to get it 
working on another system. I LOVE it when I ask a potential client 
whether their code is standard-conforming and they look shifty and say 
"well, actually, we had to..." - because it's just about always 
carefully isolated, was only done because it was strictly necessary, and 
is fully documented. A casual "oh yes", however...

-- 
Catherine Rees Lay

Polyhedron Software Ltd. Registered Office: Linden House,
93 High St, Standlake, Witney, OX29 7RH, United Kingdom.
Registered in England No.2541693. Vat Reg No. GB 537 3214 57
0
2/13/2008 9:41:28 AM
Reply: