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

[Mihael Hategan]

I'm assuming we won't statically track optional data. In a static typing
scenario, all optional data would need to be declared as such. This
would be similar to the Maybe type in Haskell. I'm assuming we don't
want to do that. Instead, optional types would be dynamic types. This
would allow one to use an app defined with non-optional types with
optional data.

The typing rules would go something like this:
1. f: X -> Y
  type(f(Nothing/X)) = Nothing/Y
  type(f(Just X)) = Just Y

2. For a composite type Y = X1 x X2 x... x Xn, type(Y) = Nothing if any
Xi = Nothing, type(Y) = Just Y if all Xi = Just Xi.

3. Corollary of 1 and 2 is that f: X1 x X2 -> Y, f(x1, Nothing) =
f(Nothing, x2) = f(Nothing, Nothing) = Nothing. This can be generalized.

We should have an additional operator (catMaybes in Haskell) which
extracts the present values from an array. In other words (and we need a
name for it), ~([maybe x]) = [x}.

There might be some contention here. I'm saying that a reduce operating
on an array of optional data should by default return nothing if any of
the array elements is a nothing. I think this should be done if we are
to have consistency. Reduce is the successive application of some
function to the elements of a list:

reduce(a[], "+") = (...((a[0] + a[1]) + a[2]) + ... ) + a[n])
If, by the first rule (which I think is fundamental) "+"(Just x,
Nothing) = Nothing, it can be easily seen that reduce(a[], "+") =
Nothing if any a[i] = Nothing.

In order to reduce only the Just values, there would need to be a way to
extract only those from the array.

Thoughts? Questions?

Mihael

On Mon, 2011-04-11 at 14:20 -0500, Jonathan Monette wrote:
> Well the case I have in my scripts would be to only run the reduce on
> the available elements in the array. I am not sure why the other case
> would be valid. Not doin the reduce on the array because an outfile
> was not mapped is the same as what swift currently does. The only
> difference is that instead of causing the swift system to fail it just
> tries to continue on the execution. 
> 
> On Apr 11, 2011 2:06 PM, "Mihael Hategan" <hategan at mcs.anl.gov> wrote:
>