[Swift-user] import position in swift script

[Mihael Hategan]

On Thu, 2015-06-18 at 19:48 +0000, Max Hutchinson wrote:
> I agree that it is a no interface function call.  Maybe this is also
> helpful with not needing to explicitly collect outputs to get staged out?

Good point. We, more or less, require that the app, perhaps through a
wrapper script, fully define its interface through the command line. On
the other hand, magical matching is allowed. If you have an output
carefully mapped to what the application produces, it will work even
without a wrapper, but it's impossible to make that work if two
invocations produce two files with the same name.

That should change. The reason it didn't is that we didn't have a good
idea about how to make the collect specification nice in the case of
non-trivial file lists.

> My understanding is that If run.swift contains a bunch of nested loops, one
> would have declare a bunch of [auto] outputs and remember to append
> everything to them (or they could be considered tmps and not staged out).
> There's value to being forced to be thoughtful, but it might also be nice
> to start with the trailing import while prototyping/debugging a script and
> then switch to a wrapper after the dust has settled.

I'd rather add code to allow mapping in struct expressions, so that you
could write something like this:

params = {
	prefix: "debug",
	json: <"debug.json">,
	...
}

test = sweep(params);

and perhaps:

with (params) {
	...
}

> 
> I'm focusing on direct staging, so the wrapper was straightforward.  For
> reference:
> https://github.com/maxhutch/nek-swift/blob/alcf/debug.swift
> https://github.com/maxhutch/nek-swift/blob/alcf/nek.swift
> 
> If imports are only going to be supported in the preamble, could that be
> added to the docs?
> http://swift-lang.org/guides/trunk/userguide/userguide.html#_imports

We're in the process of revamping the docs. It will be in there.

Mihael