<div dir="ltr"><div>FWIW in Swift/T we allow arbitrary expressions in the app command line, mainly for expressiveness/convenience (e.g. you can call another app function from within an app function). We don't allow multiple statements: the main reason against that would be that the complexity of the language increases and you end up with a language-within-a-language.<br>
<br></div><div>In Swift/T we can actually deal with the temporary file situation above with a compile-time optimization. It's a bit complicated and depends on some other, more general, transformations taking place. The chain of reasoning is "Command B depends on command A, so we should defer any execution until after A finishes" => "Command B will definitely have its input dependencies filled once A finishes, so we can launch B immediately after A finishes" => "We can merge B into A since they're sequentially dependent. If there's a task C that's also sequentially dependent on A, have to pick one" => "The result of A isn't needed outside this scope, so don't need to copy out". The nice thing about this is that it works anywhere you have a pipeline of tasks in your code.<br>
</div><div><br></div>I've thought in the past about the idea of supporting shell statements inline in any Swift function. To fit it in the grammar you would have to change the syntax slightly (e.g. prefix it with keyword exec). You would also need to have some way of identifying which files are output files.<br>
<br>exec sh "-c" strcat("a ", @filename(inf), " | b ") stdout(@outf);<br><div class="gmail_extra"><br></div><div class="gmail_extra">- Tim<br></div><div class="gmail_extra"><br><div class="gmail_quote">
On Wed, Jul 10, 2013 at 9:49 PM, Michael Wilde <span dir="ltr"><<a href="mailto:wilde@mcs.anl.gov" target="_blank">wilde@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Yes, I agree - we have long wanted to expand what an app() can do.<br>
<br>
Most discussions centered around enabling inline code from a variety of interpreters to be embedded, with easy substitution of input and output parameters from the app() function template.<br>
<br>
Your example could be coded like:<br>
<br>
app (file outf) myapp (file inf)<br>
{<br>
sh "-c" strcat("a ", @filename(inf), " | b ") stdout(@outf);<br>
# or<br>
sh "-c" strcat("a ", @filename(inf), ">tmp; b tmp") stdout(@outf);<br>
}<br>
<br>
so one could say :<br>
<br>
bash (file outf) myapp (file inf)<br>
{<br>
a @inf | b > @outf<br>
# or<br>
a @inf >tmp; b tmp >@outf<br>
}<br>
<br>
as well as similarly interpreted app() functions for python, tcl, R, etc. Virtually anything that can be "#!"ed.<br>
<br>
What might also be desirable is to be able to call any Swift app() function from within an app function: ie if a() and b() were already coded as apps. I.e. ensure that any app() can also serve as the equivalent of a bash function. Im not sure how this would work across interpretive languages, but one could envision simple semantic rules that would enable this.<br>
<br>
One more case of interest is to enable any swift function call or expression to be interpreted on a single node, including all the functions it calls. This would be as you suggest in your example, for the purpose of file exchange locality.<br>
<br>
- Mike<br>
<div class=""><div class="h5"><br>
<br>
----- Original Message -----<br>
> From: "Mihael Hategan" <<a href="mailto:hategan@mcs.anl.gov">hategan@mcs.anl.gov</a>><br>
> To: "Swift Devel" <<a href="mailto:swift-devel@ci.uchicago.edu">swift-devel@ci.uchicago.edu</a>><br>
> Sent: Wednesday, July 10, 2013 9:11:03 PM<br>
> Subject: [Swift-devel] app semantics<br>
><br>
> Maybe we talked about this before, but I think we should allow things<br>
> like:<br>
><br>
> app (file outf) myapp(file inf) {<br>
> file tmp <"tmpfile">;<br>
> a filename(inf) stdout=filename(tmp);<br>
> b filename(tmp) stdout=filename(outf);<br>
> }<br>
><br>
> In a more general and theoretical sense, an app block can allow some<br>
> delimited side-effects while enforcing sequential execution.<br>
><br>
> From a practical perspective, this would solve the problem of large<br>
> temporary files being staged in and out needlessly (e.g. tmpfile in<br>
> our<br>
> case).<br>
><br>
> Mihael<br>
><br>
> _______________________________________________<br>
> Swift-devel mailing list<br>
> <a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
> <a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
><br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br></div></div>