IdeasForTheFuture

This is some space in which we can jot down our ideas for potential future features. Nothing here is guaranteed to happen but it is good to note down concepts as they occur.

Generalised PSyKAl Light

As part of the PSyclone development process Fab supports overriding the output of a PSyclone task with a hand written alternative. This way missing functionality can be prototyped allowing continued progress of the project using PSyclone and a working requirement example for PSyclone developers.

It seems like it should not be difficult to generalise this feature to allow the output of any transformation task to be overridden with an hand written alternative.

API Directives

The design as it stands allows for a "zero configuration" mode of operation. In this mode Fab just locates all the source in the subtree rooted at the currently selected directory. It then finds any Fortran program units or C int main(int argc, char **argv) functions. It then recurses through their dependencies to find every object which should be linked to make an executable.

There is no similar process which would allow us to infer the members of a library as neither Fortran or C source has any intrinsic knowledge of which objects belong in a library. That has to be provided externally as a list in some sort of configuration file. What this list is effectively doing is defining the API of the library by selecting which objects are linked into it.

What might be possible (and desirable?) is to use in source directives, in the recognised style, to identify variables, procedures and types which make up the API. Then "zero configuration" could intuit how to link the library. What's more, if the concept of a unique library name were included in these directives it would be possible to build multiple libraries from the same source tree. Even have objects appearing in more than one.

Consider an example where there is to be a normal library containing a class and a procedure. There is also to be a special library which holds the same class and a global variable but not the procedure.

!$FAB API(special)
integer :: some_global

!$FAB API(normal, special)
type :: my_type
  ...
contains
  ...
end type

!$FAB API(normal)
subroutine a_thing()
  ...
end subroutine

#pragma fab api(special)
static int some_global;

#pragma fab api(normal, special)
class my_class {
  ...
}

#pragma fab api(normal)
void a_thing() {
  ...
}

Obviously names and syntax are up for debate.

One concern is that this is repeating the mistake of the "dependson" comments used by FCM. This is true in so much as it provides additional information not provided by the standard language. However it differs in that it uses the existing recognised means, be they specified or common usage. It is very clear to which tool the information is intended as it is named. Consider OpenMP as an example of where this is already done.

Zero Configuration

An awful lot can potentially be achieved with no configuration at all. I call this "zero configuration mode."

The idea would be that when invoked without arguments (specifically a configuration file) Fab would operate on the current directory and discover all source in it. If there are any top level program structures (Fortran program program units or C main() functions then these are used to build executables. Otherwise everything is compiled into a library.

When combined with the API directive concept outlined above multiple libraries and mixtures of executables and libraries could be generated.

One envisaged value of this would be to allow science developers to quickly construct toy codes without even having to think about how to build them. It is not meant to replace the existing configuration driven approach but to augment it.

This change would require Fab to offer an executable in addition to being invoked as a library.