[Swift-devel] Standard Library Proposal/Discussion Page

Tim Armstrong tim.g.armstrong at gmail.com
Thu Jan 22 00:26:02 CST 2015


I agree that the language can pick whatever schedule with whatever degree
of parallelism as long as it satisfies the partial order defined by data
flow and there are no false control dependencies inserted that will prevent
progress.  The issue is more that adding those variables to the language
adds additional ordering requirements based on sequential control flow.  A
schedule that satisfies the stricter ordering requirements will satisfy the
weaker ones (unless the additional dependencies prevent it from making
progress), but the difference in ordering requirements is real.  I don't
think it's all that relevant that it's possible for an implementation to
exist that satisfies both semantics in many circumstances.

The involvement of foreach is very relevant.  You can unfold a foreach to
<iter 1>; <iter 2> <iter 3> under the current semantics.  You can also
unfold it to <iter 2>; <iter 1>; <iter 3> and it's the same.  The language
needs this to run the iterations out of order based on data availability -
there is no problem doing so since the two unfoldings are equivalent.
What's being proposed is that the first unfolding is the canonical one, and
you can't do the second one unless you prove that it's equivalent.  So an
implementation must guarantee that the loop iterations *don't* execute out
of order unless it analyses the loop body sufficiently to prove that there
is nothing in there that depends on the sequential order of loop
iterations.  But there's another issue.  We would need to provide a strong
guarantee that the iterations *do* execute out of order if there is nothing
in the loop body to prevent them from doing so, since otherwise the program
might fail to make progress when it should, or even deadlock if there is
some sort of recursive dependency where the array being iterated over
depends directly or indirectly on the computation in the loop body.  So
essentially foreach would have to be one of two different control flow
constructs (in-order foreach or out-of-order foreach) depending on what you
do inside it.

That also doesn't address the issue of other array key types.  If you
iterate over an array with [auto] keys, what is the canonical order of
iterations?

Also,, now that I think about it, presumably negative numbers would go
before 0, so if you were iterating over an array with integer keys that had
keys [0] to [N] filled in, you couldn't process key [0] until the array was
entirely closed.  Seems strange...

I just feel that Swift is fundamentally a language with relaxed ordering.
I don't have anything against a more sequential version for some situations
but I feel like it's just a different language.

- Tim


On Wed, Jan 21, 2015 at 6:06 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Wed, 2015-01-21 at 17:09 -0600, Tim Armstrong wrote:
> > Function pointers are probably not a short-term addition - might be
> simpler
> > just to add functions we think are important and have function pointers
> as
> > a longer-term addition.
>
> I agree. However, comparable in effort to auto-update variables. So
> maybe we can decide to not waste effort on one of them.
>
> Mihael
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150122/da95cfda/attachment.html>


More information about the Swift-devel mailing list