[Swift-devel] [Bug 343] New: Add support for optional input and output files

[Mihael Hategan]

The issue that I see is not as much how to implement optional files, but
how to deal with them. Consider the following:

app (optional file x) myapp() {
	blabla;
}

file x = myapp();
file y = f(x);

The question is what should that program do. Though that's probably a
simple example: one could simply say that anything dependent on x is
also optional (so f would not be invoked).

How about a reduce:

app (optional file x) myapp(int i) {
	blabla i;
}

for i in [0:100]  {
	a[i] = myapp(i);
}

file y = reduce(a);

Should reduce be invoked with only the available array elements? Should
it not be invoked at all? Should the type system be used to distinguish
between the two?

Mihael

On Mon, 2011-04-11 at 11:57 -0500, bugzilla-daemon at mcs.anl.gov wrote:
> https://bugzilla.mcs.anl.gov/swift/show_bug.cgi?id=343
> 
>            Summary: Add support for optional input and output files
>            Product: Swift
>            Version: 1.0
>           Platform: PC
>         OS/Version: Mac OS
>             Status: NEW
>           Severity: enhancement
>           Priority: P2
>          Component: SwiftScript language
>         AssignedTo: wozniak at mcs.anl.gov
>         ReportedBy: wilde at mcs.anl.gov
> 
> 
> A frequent situation is that some application may not produce all of their
> declared output files, while other applications dont require all of their input
> files.
> 
> This ticket is filed to determine whether this application pattern should be
> explicitly supported in Swift by a new notation to declare that outputs or
> inputs are optional.
> 
> The assumption is that current Swift future-based data dependencies would
> remain unchanged: optional output files would be considered to "exist" when the
> program that might produce them completes, even if the file was not in fact
> created.  Thus we'd need to change the wrapper and data transfer code to
> consider non-existance a valid situation in cases where it was declared so.
> 
> This will need more discussion, but am filing this to get the discussion
> started.
> 
> This feature was requested by the ParVis project, but many other users have
> asked how to handle such cases. The answer to date has always been to create
> wrappers that create or interpret zero-length files to signify non-existiing
> files.
>