So then running a reduce on an array with optional arguments will return nothing.  However, if we need to reduce on the elements that were actually returned to the array we would call something like reduce( extract( a[] ), "+" )?  Is that what you are saying?  That in order to implement the optional output files a function would need to be defined to extract all the elements that are mapped from the optional array and this will all the user to run a reduce on the extracted values?<div>
<br></div><div>If this is indeed how it will work then it will work fine for my case.  I am not sure what parvis is doing so I cannot say it will work for them but for the Montage wrappers it will work and will clean up code on my end.<br>
<div><br><div class="gmail_quote">On Tue, Apr 12, 2011 at 2:09 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm assuming we won't statically track optional data. In a static typing<br>
scenario, all optional data would need to be declared as such. This<br>
would be similar to the Maybe type in Haskell. I'm assuming we don't<br>
want to do that. Instead, optional types would be dynamic types. This<br>
would allow one to use an app defined with non-optional types with<br>
optional data.<br>
<br>
The typing rules would go something like this:<br>
1. f: X -> Y<br>
  type(f(Nothing/X)) = Nothing/Y<br>
  type(f(Just X)) = Just Y<br>
<br>
2. For a composite type Y = X1 x X2 x... x Xn, type(Y) = Nothing if any<br>
Xi = Nothing, type(Y) = Just Y if all Xi = Just Xi.<br>
<br>
3. Corollary of 1 and 2 is that f: X1 x X2 -> Y, f(x1, Nothing) =<br>
f(Nothing, x2) = f(Nothing, Nothing) = Nothing. This can be generalized.<br>
<br>
We should have an additional operator (catMaybes in Haskell) which<br>
extracts the present values from an array. In other words (and we need a<br>
name for it), ~([maybe x]) = [x}.<br>
<br>
There might be some contention here. I'm saying that a reduce operating<br>
on an array of optional data should by default return nothing if any of<br>
the array elements is a nothing. I think this should be done if we are<br>
to have consistency. Reduce is the successive application of some<br>
function to the elements of a list:<br>
<br>
reduce(a[], "+") = (...((a[0] + a[1]) + a[2]) + ... ) + a[n])<br>
If, by the first rule (which I think is fundamental) "+"(Just x,<br>
Nothing) = Nothing, it can be easily seen that reduce(a[], "+") =<br>
Nothing if any a[i] = Nothing.<br>
<br>
In order to reduce only the Just values, there would need to be a way to<br>
extract only those from the array.<br>
<br>
Thoughts? Questions?<br>
<font color="#888888"><br>
Mihael<br>
</font><div><div></div><div class="h5"><br>
On Mon, 2011-04-11 at 14:20 -0500, Jonathan Monette wrote:<br>
> Well the case I have in my scripts would be to only run the reduce on<br>
> the available elements in the array. I am not sure why the other case<br>
> would be valid. Not doin the reduce on the array because an outfile<br>
> was not mapped is the same as what swift currently does. The only<br>
> difference is that instead of causing the swift system to fail it just<br>
> tries to continue on the execution.<br>
><br>
> On Apr 11, 2011 2:06 PM, "Mihael Hategan" <<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>> wrote:<br>
><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.<br>- Albert Einstein<br>
<br><br>
</div></div>