[Swift-devel] Associative array in Swift [GSoC]

[Tim Armstrong]

Maybe I missed something, but from the discussion I'm not quite clear about
what the use case is.

It seems like there are three possibilities for the data structure:

1 Order is completely unimportant (i.e. the data structure is a set or
multi-set)
2 Relative order is important (i.e. if the assignment happens in a later
iteration of a for loop, it should be later in the list)
3 Absolute order is important - i.e. we're using explicit array indices

It seems like you're proposing 2, which seems a bit odd to me in the context
of swift as it adds some kind of sequential dependency between iterations of
a for loop when determining array indices.

The idea of building a nested (ragged) array and then flattening it seems
more swift-like to me.

Ie.
 foreach i in a {
   foreach j in b {
     output[i][j] = f(i,j)
   }
 }
file output2[];
output2 = flatten(output)

That is kind of clunky though.  Would it be possible to have some kind of
syntax for implicitly flattening arrays, e.g.:

file output2[];
foreach i in a {
  foreach j in b {
     output[i,j] = f(i,j)
  }
}

- Tim

On Sat, Jun 18, 2011 at 5:57 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> On Sun, 2011-06-19 at 01:36 +0100, Ben Clifford wrote:
> > On Jun 19, 2011, at 1:21 AM, Mihael Hategan wrote:
> >
> > > I wasn't discussing an issue of semantics. I think we agree on that.
> I'm
> > > simply saying that I prefer one syntax to the other
> >
> > ok. I'm not overly enthused about the syntax either way.
> >
> > >>
> > >> I personally find the idea of expression what looks like a mutating
> > >> concatenation but isn't really to be more distasteful.
> > >
> > > Except it is a mutating concatenation. But it's one that is acceptable
> > > because there is no way to have code that is nondeterministic because
> of
> > > it. It's a non-destructive mutation.
> >
> > do you regard the 2nd statement in:
> >
> > a[0] = 4343;
> > a[1] = 54354;
> >
> > to be mutating?
>
> Looks like it: a_without_it != a_with_it (where it = second statement),
> Though, again, swift doesn't allow you to compare a before with a after.
> There is no explicit or implicit notion of time or time sequence.
>
> >  if so, then a += 54354; is also a mutating concatenation in that
> > definition of the word, and I agree with you. Otherwise I disagree
> > with you.
>
> Right. The statement above applies equally well.
>
> >
> > But my perspective is that in a swift run, the 'a' array above has a
> > single value, described as: "the 0th element is 4343, and the 1st
> > element is 4343" and that the value becomes more accurately known as
> > the run progresses until such time as you know its value completely.
> > In that sense, the 2nd statement above, and the concatenation-like
> > operators discussed in this thread are absolutely not mutating: they
> > define the final value and that is all. From that perspective, the
> > ability to pipeline based on partial knowledge of that value is
> > somewhat accidental.
> >
> I agree. Point being that both may look like a mutating operation in
> some arbitrary non-swift language, but they are what they are in swift.
> So I don't think that a = a + [1] looks more mutating than a[next_index]
> = 1. Given that they are equivalent from that perspective, the remaining
> deciding factors should be unrelated to this issue.
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20110618/041c9a3e/attachment.html>