I've never had occasion to use this until now, and don't recall seeing
any examples.  My guess is that a procedure dummy argument can be
optional just like any other.  How would this be declared?  A
hand-written INTERFACE block (I think this is the only time one needs to 
write an INTERFACE block by hand; of course this is not necessary if the 
routine is in a module which is used, but for library-type routines with 
optional procedure arguments this can't be done) and an additional, 
separate OPTIONAL statement?

Op donderdag 31 mei 2012 10:27:23 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
> I've never had occasion to use this until now, and don't recall seeing
> any examples.  My guess is that a procedure dummy argument can be
> optional just like any other.  How would this be declared?  A
> hand-written INTERFACE block (I think this is the only time one needs to 
> write an INTERFACE block by hand; of course this is not necessary if the 
> routine is in a module which is used, but for library-type routines with 
> optional procedure arguments this can't be done) and an additional, 
> separate OPTIONAL statement?

I do not know if it is possible - checking for the presence or absence
seems odd too - but consider this alternative:

interface use_func
    module procedure use_user_func
    module procedure use_default_func
end interface 

contains
subroutine use_user_func( f )
    interface 
        real function f(x) 
            ...
        end function
    end interface
    ...

    write(*,*) f(1.0)

end subroutine use_user_func 

subroutine use_default_func

    write(*,*) sin(1.0)

end subroutine use_default_func

In other words: consider providing an interface uniting two
versions, one with the function dummy argument and one without.
Perhaps a bit more source code, but it will do the trick in 
any case.

Regards,

Arjen

On 05/31/2012 10:27 AM, Phillip Helbig---undress to reply wrote:
> I've never had occasion to use this until now, and don't recall seeing
> any examples.  My guess is that a procedure dummy argument can be
> optional just like any other.  How would this be declared?  A
> hand-written INTERFACE block (I think this is the only time one needs to
> write an INTERFACE block by hand; of course this is not necessary if the
> routine is in a module which is used, but for library-type routines with
> optional procedure arguments this can't be done) and an additional,
> separate OPTIONAL statement?
>

No problem in F2003, consider this:

module foo

   abstract interface
      integer function fi ()
      end function fi
   end interface

contains

   subroutine apply_f (f)
     procedure (fi), optional :: f
     if (present (f))  print *, f ()
   end subroutine apply_f

end module foo


-- Wolfgang

-- 
E-mail: firstnameinitial.lastname@domain.de
Domain: yahoo

In article <90406972-ec54-462a-8136-0004297ba20e@googlegroups.com>,
Arjen Markus <arjen.markus895@gmail.com> writes: 

> I do not know if it is possible - checking for the presence or absence
> seems odd too

Maybe it is.

> In other words: consider providing an interface uniting two
> versions, one with the function dummy argument and one without.
> Perhaps a bit more source code, but it will do the trick in 
> any case.

This will work.  However, a bit unwieldy in my case.  I have a very long 
list of arguments, most of them are optional.  The idea is that the 
calling program can provide a variable OR a function to calculate the 
same quantity.  Say you're calculating the time to fly from A to B.  The 
routine could get passed a constant windspeed as a variable, or a 
function which would calculate windspeed as a function of time and 
position.  One could, of course, have in this function the special case 
of constant wind speed, but would have to specify it in some non-obvious 
way (say, the function could USE a module which contains the windspeed 
and also a flag whether or not to use the windspeed from the module or 
calculate it).

In article <jq7ctc$mig$1@dont-email.me>, Wolfgang Kilian
<seesig@domain.invalid> writes: 

> No problem in F2003, consider this:

Won't work in F95.  :-(

What about this?

module foo
contains
real function f(x)
real :: X
f = 2*x
end function f
subroutine apply_f (f)
!optional :: f
!if (present (f))  print *, f ()
print *, f ()
end subroutine apply_f
end module foo

With the lines commented out as above I get:

subroutine apply_f (f)
.....................^
%F90-W-WARNING, This name has not been given an explicit type.   [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;31

Since it is declared as a REAL FUNCTION in the same module, why isn't it 
visible?

With the lines uncommented, I get:

subroutine apply_f (f)
.....................^
%F90-W-WARNING, This name has not been given an explicit type.   [F]
at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;32

if (present (f))  print *, f ()
............................^
%F90-E-ERROR, This name has not been declared as an array or a function. 
  [F]
at line number 9 in file DISK$SCRATCH:[HELBIG]BLA.F90;32

print *, f ()
..........^
%F90-E-ERROR, This name has not been declared as an array or a function. 
  [F]
at line number 10 in file DISK$SCRATCH:[HELBIG]BLA.F90;32

I don't see why I don't get the last error above as well.

What I did in F77 was to hard-code the function name and have a flag 
saying whether or not to use it:

IF (USE_FUNCTION) THEN
   X = FUNCTION(Y)
ELSE
   X = 5.0
ENDIF

But this needs the extra logical variable USE_FUNCTION and hard-codes 
the function name.  (I could have a non-optional procedure argument and 
pass an arbitrary function, but then I would ALWAYS have to pass a 
function name.)

Op donderdag 31 mei 2012 11:49:30 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
> In article Wolfgang Kilian writes: 
> 
> > No problem in F2003, consider this:
> 
> Won't work in F95.  :-(
> 

What compiler are you using? Most seem to support at least these aspects
of Fortran 2003. 

Regards,

Arjen

On 2012-05-31 7:49 PM, Phillip Helbig---undress to reply wrote:
> In article<jq7ctc$mig$1@dont-email.me>, Wolfgang Kilian
> <seesig@domain.invalid>  writes:
>
>> No problem in F2003, consider this:
>
> Won't work in F95.  :-(
>
> What about this?
>
> module foo
> contains
> real function f(x)
> real :: X
> f = 2*x
> end function f
> subroutine apply_f (f)
> !optional :: f
> !if (present (f))  print *, f ()
> print *, f ()
> end subroutine apply_f
> end module foo
>
> With the lines commented out as above I get:
>
> subroutine apply_f (f)
> ....................^
> %F90-W-WARNING, This name has not been given an explicit type.   [F]
> at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;31
>
> Since it is declared as a REAL FUNCTION in the same module, why isn't it
> visible?
>
> With the lines uncommented, I get:
>
> subroutine apply_f (f)
> ....................^
> %F90-W-WARNING, This name has not been given an explicit type.   [F]
> at line number 7 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
>
> if (present (f))  print *, f ()
> ...........................^
> %F90-E-ERROR, This name has not been declared as an array or a function.
>    [F]
> at line number 9 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
>
> print *, f ()
> .........^
> %F90-E-ERROR, This name has not been declared as an array or a function.
>    [F]
> at line number 10 in file DISK$SCRATCH:[HELBIG]BLA.F90;32
>
> I don't see why I don't get the last error above as well.
>
> What I did in F77 was to hard-code the function name and have a flag
> saying whether or not to use it:
>
> IF (USE_FUNCTION) THEN
>     X = FUNCTION(Y)
> ELSE
>     X = 5.0
> ENDIF
>
> But this needs the extra logical variable USE_FUNCTION and hard-codes
> the function name.  (I could have a non-optional procedure argument and
> pass an arbitrary function, but then I would ALWAYS have to pass a
> function name.)

(Goodness, after a few quiet days it looks like we have all woken up.)

Consider the following, which I think is just F95:

module foo
   implicit none
contains
   real function f(x)   ! #1
     real :: X
     f = 2*x
   end function f

   subroutine apply_f (f)   ! #2
     interface
       function f(x)        ! #3
         real :: x
         real :: f
       end function f
     end interface
     optional :: f          ! #4
     if (present (f))  print *, f(3.0)
   end subroutine apply_f
end module foo

The function body at #1 declares a function called f in the scope of the 
module.

In the subroutine statement at #2, the argument f has the same name as 
the function-called-f-at-module-scope.  Due to the rules of host 
association the argument then hides the function - in between the 
subroutine and end subroutine any references to f refer to the argument.

(If there was no argument called f then the 
function-called-f-at-module-scope would be available inside the 
subroutine through host association, in the event of a name clash the 
host associated thing loses.)

The interface block at #3 then tells the processor what that f inside 
the subroutine is.  In this case it is a dummy procedure that is a 
function.  #4 also tells the processor that dummy argument is optional.

Without #3 the processor knows that there is a thing called f that is 
local to the subroutine's scope, but it has no idea what it is - hence 
you were seeing warnings and errors.

In article <0c4bb81b-6b30-412e-9c2a-9dbca7495996@googlegroups.com>,
Arjen Markus <arjen.markus895@gmail.com> writes: 

> What compiler are you using? Most seem to support at least these aspects
> of Fortran 2003. 

I'm using the DEC/Compaq/HP compiler on VMS.  It is full F95, but 
nothing beyond that.  It is several years old (but has been good 
enough).  I'm not sure if there is a newer version which supports more 
features.  However, I try to aim for the most recent standard which is 
reasonably well supported.  I seem to recall reading recently that IBM 
has a complete F2003 compiler on AIX, but that is one of very few, 
right?

In article <k3Jxr.7771$%E2.6322@viwinnwfe01.internal.bigpond.com>, Ian
Harvey <ian_harvey@bigpond.com> writes: 

> Consider the following, which I think is just F95:

This works.  (When in the same file, I had to have the module before the 
test program calling apply_f.  Otherwise works OK.)

> The function body at #1 declares a function called f in the scope of the 
> module.

Right.

> In the subroutine statement at #2, the argument f has the same name as 
> the function-called-f-at-module-scope.  Due to the rules of host 
> association the argument then hides the function - in between the 
> subroutine and end subroutine any references to f refer to the argument.

OK.

> (If there was no argument called f then the 
> function-called-f-at-module-scope would be available inside the 
> subroutine through host association, in the event of a name clash the 
> host associated thing loses.)

Right.  I could call the dummy argument something else, but then it is 
not clear why it should refer to f.

> The interface block at #3 then tells the processor what that f inside 
> the subroutine is.  In this case it is a dummy procedure that is a 
> function.  #4 also tells the processor that dummy argument is optional.

Right.  This works.  However, I really dislike writing interfaces by 
hand; I prefer them to be automatic.

> Without #3 the processor knows that there is a thing called f that is 
> local to the subroutine's scope, but it has no idea what it is - hence 
> you were seeing warnings and errors.

OK.

Is there a way to do this without explicitly writing the interface?  I 
tried putting f in another module and using it, both from within foo and 
from within apply_f.  Neither work.

It is clear that declaring a local variable of the same name overrides
those inherited from elsewhere.  However, the dummy argument, though it
doesn't specify a type and is not really a declaration, also overrides
this.  Thus, the mere presence of a dummy argument overrides anything 
from elsewhere, so there is no way to get the function definition via 
USE.

On 2012-05-31 10:33 PM, Phillip Helbig---undress to reply wrote:
> In article<k3Jxr.7771$%E2.6322@viwinnwfe01.internal.bigpond.com>, Ian
> Harvey<ian_harvey@bigpond.com>  writes:
>
>> Consider the following, which I think is just F95:
>
> This works.  (When in the same file, I had to have the module before the
> test program calling apply_f.  Otherwise works OK.)

It is a very common (in my experience ubiquitous bar one extreme corner 
case that I'm aware of) requirement of implementations that the compiler 
sees the module (either as a separate file, or earlier in the source 
file) before it sees any use statements for the module.

....
> Is there a way to do this without explicitly writing the interface?

Not in F95 as far as I am aware.

In F2003 you could use a minor variant on the abstract interface 
approach that Wolfgang posted upthread.

module foo
   implicit none
contains
   real function f(x)
     real :: x
     ...
   end function f

   subroutine apply_f(f_arg)
     procedure(f), optional :: f_arg   ! #1
     ...
   end subroutine apply_f
end module foo

The procedure statement at #1 says that the interface of the dummy 
argument f_arg has the same characteristics as the interface of the 
module procedure f.  In Wolfangs example he provided an abstract 
procedure to use as the template, above we hitch a ride using the 
existing concrete function.

Op donderdag 31 mei 2012 14:14:55 UTC+2 schreef Phillip Helbig---undress to reply het volgende:
> In article <0c4bb81b-6b30-412e-9c2a-9dbca7495996@googlegroups.com>,
> Arjen Markus writes: 
> 
> > What compiler are you using? Most seem to support at least these aspects
> > of Fortran 2003. 
> 
> I'm using the DEC/Compaq/HP compiler on VMS.  It is full F95, but 
> nothing beyond that.  It is several years old (but has been good 
> enough).  I'm not sure if there is a newer version which supports more 
> features.  However, I try to aim for the most recent standard which is 
> reasonably well supported.  I seem to recall reading recently that IBM 
> has a complete F2003 compiler on AIX, but that is one of very few, 
> right?

As for a complete F2003 compiler, I think you are right, but both Intel Fortran
and gfortran support most of the features of F2003 that I need (which makes
experimenting with these features quite convenient). And there are others 
which similar support. 

I do not use VMS myself, so I can not comment on the availability of 
F2003 features on that platform.

Regards,

Arjen

Arjen Markus <arjen.markus895@gmail.com> wrote:

> Op donderdag 31 mei 2012 10:27:23 UTC+2 schreef Phillip Helbig---undress
to reply het volgende:
> > I've never had occasion to use this until now, and don't recall seeing
> > any examples.  My guess is that a procedure dummy argument can be
> > optional just like any other.  How would this be declared?  A
> > hand-written INTERFACE block (I think this is the only time one needs to
> > write an INTERFACE block by hand; of course this is not necessary if the
> > routine is in a module which is used, but for library-type routines with
> > optional procedure arguments this can't be done) and an additional,
> > separate OPTIONAL statement?
> 
> I do not know if it is possible - checking for the presence or absence
> seems odd too

I don't know what is so odd about it. Argument presence is orthogonal to
any matter if the argument being a data argument. Anyway, yes, that's
perfectly fine.

For f95, you do end you having to write an interface body, which I don't
like. At least you need that to get an explicit interface for the dummy
rpocedure. If the dummy does not need an explicit interface, you can
just go with the EXTERNAL statement instead of an interface body, but I
don't much like that either.

As discussed in the other replies, f2003 provides what I see as
"cleaner" alternatives using the new PROCEDURE statement. The PROCEDURE
statement is much more parallel in form to type specification
statements, including the allowance for atributes such as OPTIONAL. You
can use an abstract interface with a PROCEDURE statement. That still has
you writing an interface body, but at least you can then potentially
reference that abstract interface in multiple places instead of having
to repeat it each time. Alternatively, you can use the feature of the
PROCEDURE statement that says, in essence, "use the same interface as
this other procedure, whose interface you already know." That avoids
having to write an interface body at all. But all of those require
f2003.

For f95, you are stuck with either an interface body or the external
statement/attribute. Also for f95, you have to use a separate OPTIONAL
statement (except in the case of an implicit interface function, where
you could use the optional attribute on the type specification
statement).

P.S. One other case where you have to write an interface body is for
calling non-Fortran procedures. For me, that's far more common than
having procedure dummy arguments.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 2012-05-31 17:56, Richard Maine wrote:

>> I do not know if it is possible - checking for the presence or absence
>> seems odd too
> 
> I don't know what is so odd about it. Argument presence is orthogonal to
> any matter if the argument being a data argument. Anyway, yes, that's
> perfectly fine.
> 

I was thinking of the idiom:

if ( present(f) ) then
     f_local = f
else
     f_local = f_default
endif

For procedures under F95 that can not be done. Under F2003 it
would be:

f_local => f

But as F2003 is not an option for OP, that is not a solution.

Regards,

Arjen

In article <h3Kxr.7512$v14.3638@viwinnwfe02.internal.bigpond.com>, Ian
Harvey <ian_harvey@bigpond.com> writes: 

> > Is there a way to do this without explicitly writing the interface?
> 
> Not in F95 as far as I am aware.
> 
> In F2003 you could use a minor variant on the abstract interface 
> approach that Wolfgang posted upthread.
> 
> module foo
>    implicit none
> contains
>    real function f(x)
>      real :: x
>      ...
>    end function f
> 
>    subroutine apply_f(f_arg)
>      procedure(f), optional :: f_arg   ! #1
>      ...
>    end subroutine apply_f
> end module foo
> 
> The procedure statement at #1 says that the interface of the dummy 
> argument f_arg has the same characteristics as the interface of the 
> module procedure f.  

This is exactly what I need.  Alas, as you mention, not possible in 
Fortran 95.

In article <jq9pe7$421$1@dont-email.me>, arjenmarkus
<arjen.markus895@gmail.com> writes: 

> I was thinking of the idiom:
> 
> if ( present(f) ) then
>      f_local = f
> else
>      f_local = f_default
> endif

I was thinking of:

interface
  function f(x)
    real :: x
    real :: f
  end function f
end interface
optional :: f
real, optional :: z
if ( present(f) ) then
     y = f(x)
else if (present (z) ) then
     y = z
else
     print*, "either f or z must be specified"
endif

On 2012-06-01 10:48, Phillip Helbig---undress to reply wrote:
> In article <jq9pe7$421$1@dont-email.me>, arjenmarkus
> <arjen.markus895@gmail.com> writes: 
> 
>> I was thinking of the idiom:
>>
>> if ( present(f) ) then
>>      f_local = f
>> else
>>      f_local = f_default
>> endif
> 
> I was thinking of:
> 
> interface
>   function f(x)
>     real :: x
>     real :: f
>   end function f
> end interface
> optional :: f
> real, optional :: z
> if ( present(f) ) then
>      y = f(x)
> else if (present (z) ) then
>      y = z
> else
>      print*, "either f or z must be specified"
> endif
> 

Yes, that is a possibility - it all depends of course on what
you want to do with the optional argument. If the procedure
has to be used in various locations, then it pays off to
create a default procedure.

Regards,

Arjen

arjenmarkus <arjen.markus895@gmail.com> wrote:

> On 2012-05-31 17:56, Richard Maine wrote:
> 
> >> I do not know if it is possible - checking for the presence or absence
> >> seems odd too
> > 
> > I don't know what is so odd about it. Argument presence is orthogonal to
> > any matter if the argument being a data argument. Anyway, yes, that's
> > perfectly fine.
> > 
> I was thinking of the idiom:
> 
> if ( present(f) ) then
>      f_local = f
> else
>      f_local = f_default
> endif
> 
> For procedures under F95 that can not be done. Under F2003 it
> would be:
> 
> f_local => f
> 
> But as F2003 is not an option for OP, that is not a solution.

Sure that can't be done, but I don't see where the original post asked
anything much relating to that. Seems to me like you are looking for a
solution to a question not asked. It asked about optional procedure
arguments. Just because there is something optional doesn't mean that
you have to provide a local default. It is a common idiom, but certainly
not the only way to use optional arguments.

What f95 doesn't have is anything much like procedure variables except
for the limitted case of dummy arguments, which aren't called variables,
but are sort of like them. The lack of procedure variables is why you
can't do your example in f95. F2003 procedure pointers play a role like
procedure variables. (In fact, there was a bit of debate during
development as to whether to make them called variables or pointers; I
forget the details of the debate, though I vaguely recall being on the
other side of it at the time).

So the functionality of these sort-of-variable-like dummy arguments is
limitted in many ways in f95. But those limitations are not particularly
related to being optional. For example, you can't have an intent(out)
procedure argument. You can, however, have an optional procedure
argument.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

Richard Maine <nospam@see.signature> wrote:

(snip, someone wrote)
>> For procedures under F95 that can not be done. Under F2003 it
>> would be:
 
>> f_local => f
 
>> But as F2003 is not an option for OP, that is not a solution.

> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.

At some point, I thought the OP wanted an argument that was either
a function or ordinary variable. That, as far as I know, can't
be done in any version of the standard.

> What f95 doesn't have is anything much like procedure variables except
> for the limitted case of dummy arguments, which aren't called variables,
> but are sort of like them. The lack of procedure variables is why you
> can't do your example in f95. F2003 procedure pointers play a role like
> procedure variables. (In fact, there was a bit of debate during
> development as to whether to make them called variables or pointers; I
> forget the details of the debate, though I vaguely recall being on the
> other side of it at the time).

What to call them seems always to be a problem. PL/I calls them
ENTRY variables. That gets confusing, as ENTRY is also how you
declare external procedures (which can be the main entry point,
or an ENTRY statement). That is, similar to C function prototypes.

In C, they are usually called function pointers, and in most
implmentations store the address of a function. To continue
the confusion, do you need to dereference one with * or not?

> So the functionality of these sort-of-variable-like dummy 
> arguments is limitted in many ways in f95. But those limitations 
> are not particularly related to being optional. For example, 
> you can't have an intent(out) procedure argument. You can, 
> however, have an optional procedure argument.

Back to at least Fortran 66, and I believe to Fortran II.

-- glen

In article <1kl05dl.1shynco1xfuio0N%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> Sure that can't be done, but I don't see where the original post asked
> anything much relating to that. Seems to me like you are looking for a
> solution to a question not asked. It asked about optional procedure
> arguments. Just because there is something optional doesn't mean that
> you have to provide a local default. It is a common idiom, but certainly
> not the only way to use optional arguments.

Right.  In my case, there is no local default routine.  The idea is that
the calling program has two options: pass a variable name, the value of
which will be used by the called routine, or pass a procedure name, in
which case the value will be calculated by the procedure.  In my example
of calculating the time to fly somewhere, in the first case the variable
would be a constant wind speed (well, maybe speed and direction) while
in the second case the wind will be calculated as a function of time and
place.  The idea is not to replace a default procedure with a
user-defined procedure, but rather to replace a simple solution with a 
more involved solution.  (Actually, the procedure can be either user 
written or the user can specify a routine which is part of the module 
with all the other routines.  Since the value is used very often, it is 
good to avoid the overhead of procedure calls unless they are needed.  
One could, of course, have a procedure which always returns the same 
value, but that is the overhead I want to avoid.)

In article <jqavqo$it3$1@speranza.aioe.org>, glen herrmannsfeldt
<gah@ugcs.caltech.edu> writes: 

> Richard Maine <nospam@see.signature> wrote:
> 
> (snip, someone wrote)
> >> For procedures under F95 that can not be done. Under F2003 it
> >> would be:
>  
> >> f_local => f
>  
> >> But as F2003 is not an option for OP, that is not a solution.
> 
> > Sure that can't be done, but I don't see where the original post asked
> > anything much relating to that. Seems to me like you are looking for a
> > solution to a question not asked. It asked about optional procedure
> > arguments. Just because there is something optional doesn't mean that
> > you have to provide a local default. It is a common idiom, but certainly
> > not the only way to use optional arguments.
> 
> At some point, I thought the OP wanted an argument that was either
> a function or ordinary variable. That, as far as I know, can't
> be done in any version of the standard.

Right.  But I know that that can't be done.  :-)  So, both the variable
and the procedure are OPTIONAL, and an error occurs if neither is
specified.  (Actually, there are two variables (one integer and one
real) and one procedure, all optional, and exactly one must be
specified.) 

This is not some contrived example; it is real code.  I want to make it 
conceptually very clear so that it is easy for other people to use.  One 
part of it is some code I wrote a bit more than 15 years ago, in F77.  I 
have rewritten it in F95 and it will be part of a much larger package.  
The original code was used in the Perlmutter et al. paper for which the 
2011 Nobel Prize in physics was awarded, so I know that other people use 
my code and I want to make sure it is as good as possible.  :-)

> > So the functionality of these sort-of-variable-like dummy 
> > arguments is limitted in many ways in f95. But those limitations 
> > are not particularly related to being optional. For example, 
> > you can't have an intent(out) procedure argument. You can, 
> > however, have an optional procedure argument.
> 
> Back to at least Fortran 66, and I believe to Fortran II.

Procedure arguments were there in F77 (I haven't used any older 
Fortran).  But OPTIONAL procedure arguments?  OPTIONAL wasn't introduced 
until F90.