[Swift-devel] Swift/T mappers

Tim Armstrong tim.g.armstrong at gmail.com
Fri Jul 19 15:40:59 CDT 2013


There is a little about this topic in the Swift/T user guide, but I thought
that I could dmore concisely describe them by relating them to Swift/K
mappers.  The tl;dr version is:

   1. Swift/T uses plain old vanilla functions to do everything that input
   mappers can do.
   2. We only support output mapping individual file variables, but you can
   provide arbitrary string expressions, so it's very flexible.
   3. Mapping arrays is feasible and on the radar, but doesn't seem to be
   blocking anything and will be some work.

*Input mappers
*
Input mappers don't exist as a distinct feature in Swift/T.  Instead you
just declare an unmapped file variable, and assign it.  Swift/T provides
some functions to initialise arrays of files that achieve the same purpose
as input mappers in Swift/K.
E.g.

file f = input_file("a_single_file.txt");
file fs[] = glob("file*.txt");

I preferred doing things this way as you can do the same things without a
special language concept of input mapping.  It also makes semantics more
consistent (e.g. a variable is only assigned a value via. the assignment
operator, rather than implicitly as in the input mappers).

*Output mappers
*
The general concept of output mappers is the same as Swift/K afaict.  The
way I interpret it is that, if a programmer maps a variable, then assigns
to that variable, then a side-effect of the assignment is that the file
contents are created at or copied to that path in the file system.  We only
support mapping individual files.

file f<"output.txt">;
f = some_function();

You can provide arbitrary string expressions as the mapping, which gives
you some flexibility. E.g. if you want to create files result.1.txt,
result.2.txt, ..., result.n.txt.

file results[];
foreach i in [1:N] {
  file f<"result." + fromint(i) + ".txt"> = some_function();
  results[i] = f;
}

We don't have support for mapping arrays of files.  I don't think there's
any difficulty for language semantics, but it will need some implementation
work and decisions about what mappers to support.  Lack of other mappers
hasn't blocked any applications so far, so it hasn't been prioritised.  The
current obstacles are:

   - We need runtime/compiler support for attaching mappers to arrays.
   Fitting that logic into the STC IR will be a little convoluted but should
   be possible.
   - It seems like there is opportunity to streamline interfaces/naming of
   the Swift/K mappers, but I'm not sure exactly how.

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20130719/f4c19ba1/attachment.html>


More information about the Swift-devel mailing list