(j3.2006) Materials for 199

[Bill Long]

On 9/24/12 3:15 PM, Tobias Burnus wrote:

> (I don't have a real comment regarding the generic-procedure proposal,
> except that I would like to see some possibility to support it. Whether
> it is done via macros, the current proposal or differently, I don't have
> thought about. I also would like to see some kind of procedure which can
> be defined at one place (e.g. a module) and then when invoked, it gets
> expanded inline - possibly even with enforcing that it evaluates to a
> constant.)
>

Some sort of template scheme would be convenient.  Van proposed an 
interesting syntax style, but focused on KIND type parameters which 
should be a low priority since we have SELECTED_*_KIND routines to 
choose the desired KIND up front.  Being able to have substitutable 
types for the arguments would be more interesting.

>
> It's probably a rather small item, but something I would like to see: a
> simple way to prevent host association - or to import only some specific

One simple way to avoid host association is to declare the variable 
locally, which blocks host association of the host variable with the 
same name.  Basically a subset of the convention of explicitly declaring 
all of the local variables. Generally a good idea anyway.


> items, e.g.
>       noimport
>       import   ! which is the default
>       import :: some, list, items
> I think it was also suggested in the early draft Fortran appendix to TR
> 24772.Using the name IMPORT probably makes sense, but whether "NOIMPORT"
> is the best name, I don't know. "IMPORT NONE" would be nice, but that
> clashes with a symbol "NONE", unless the "::" are mandatory.
>
>
> I sometimes missed ANDTHEN and ORELSE, but that seems to be a recurring
> suggestions, where the exact ordering and details seem to be difficult.
> (Cf. e.g. J3/04-410r1.)
>
>
> What I also miss is something like
>      SELECT RANK(assumed_rank)
>      RANK IS (3):

It might get a lot of cases to just allow whole-array operations on 
assumed-rank dummies that are contiguous and not associated with 
assumed-size actual arguments.  Even that has potholes though.  Do the 
shapes have to match, for example?

>
> As larger item - and thus probably out of scope for the Fortran next
> revision, one could consider to follow the trend of C11 and C++11 and
> allow some shared-memory parallelization. For instance something


We do have DO CONCURRENT. Vendors are permitted to translate a loop like 
that for threaded parallel execution.

Cheers,
Bill


> inspired by Cilk. Alternatively, one could continue to leave that to
> out-of-language methods like OpenMP, which seems to also gain atomic and
> transactional memory support, following the suggestions for C++.
>
> Tobias
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101