[Swift-devel] app semantics

[Tim Armstrong]

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.

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.

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.

exec sh "-c" strcat("a ", @filename(inf), " | b ") stdout(@outf);

- Tim

On Wed, Jul 10, 2013 at 9:49 PM, Michael Wilde <wilde at mcs.anl.gov> wrote:

>
> 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
> >
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20130711/636e8a57/attachment.html>