[Swift-devel] app semantics
Michael Wilde
wilde at mcs.anl.gov
Wed Jul 10 21:49:43 CDT 2013
Yes, I agree - we have long wanted to expand what an app() can do.
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.
Your example could be coded like:
app (file outf) myapp (file inf)
{
sh "-c" strcat("a ", @filename(inf), " | b ") stdout(@outf);
# or
sh "-c" strcat("a ", @filename(inf), ">tmp; b tmp") stdout(@outf);
}
so one could say :
bash (file outf) myapp (file inf)
{
a @inf | b > @outf
# or
a @inf >tmp; b tmp >@outf
}
as well as similarly interpreted app() functions for python, tcl, R, etc. Virtually anything that can be "#!"ed.
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.
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.
- Mike
----- Original Message -----
> From: "Mihael Hategan" <hategan at mcs.anl.gov>
> To: "Swift Devel" <swift-devel at ci.uchicago.edu>
> Sent: Wednesday, July 10, 2013 9:11:03 PM
> Subject: [Swift-devel] app semantics
>
> Maybe we talked about this before, but I think we should allow things
> like:
>
> app (file outf) myapp(file inf) {
> file tmp <"tmpfile">;
> a filename(inf) stdout=filename(tmp);
> b filename(tmp) stdout=filename(outf);
> }
>
> In a more general and theoretical sense, an app block can allow some
> delimited side-effects while enforcing sequential execution.
>
> From a practical perspective, this would solve the problem of large
> temporary files being staged in and out needlessly (e.g. tmpfile in
> our
> case).
>
> Mihael
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
More information about the Swift-devel
mailing list