[Swift-devel] Appendable data structures in Swift/K and Swift/T

[Mihael Hategan]

On Wed, 2013-09-04 at 12:23 -0500, Tim Armstrong wrote:
> Hi All,
> 
> I've been working on adding appendable data structures to Swift/T.  I
> thought I would email to clarify a couple of points about the [auto] arrays
> in Swift/K and also to get feedback on the Swift/T implementation.  Ideally
> we'd do things the same way in both but I'm not confident that the Swift/K
> semantics will work well for us.
> 
> First, clarifying questions, since I'm not 100% clear on what happens when
> you "use auto key values from one array to access another", e.g. the
> example:
> 
> ======================
> int[auto] a;
> int[auto] b;
> 
> append(a, 1);
> append(a, 2);
> 
> foreach v, k in a {
>   b[k] = a[k] * 2;
> }
> =====================
> 
> There are a few corner cases I don't quite understand in the above example.
> Are there any guarantees about how the keys are assigned, e.g. in order
> from 0?

I don't think foreach guarantees an order at all, regardless of the key
types.

>   What is the type of k?

auto :)

Some unspecified internal representation that, from the perspective of
the type system, is different from every other type (except a universal
type if we had one).

Internally it is a string at the moment. I think a sequential integer
might be an alternative, but I suspect there is a reason why we didn't
pick it.

>  Can you treat it as an integer e.g. to
> trace?

No. It cannot safely be treated as anything that tracef currently has.
But %s would probably work by accident.

> 
> Also, is it possible to double-assign an index by doing that?  E.g. if I
> append(b, 1); before the loop, is it possible for that to conflict with one
> of the b[k] = ... assignments?

No. Which is probably why we use source location + thread ID instead of
integers as keys. You can't have two different assignment statements in
the same source location and running in the same thread.

> 
> Anyway, in Swift/T I've been playing around with an unordered set data
> structure: a "bag": with some similar functionality.  There were a couple
> of reasons I didn't just clone the Swift/K version:
> 
>    - We can't efficiently sequentially assign indices if the data structure
>    is split across multiple nodes (currently not the case, but possible in
>    future).

DHTs?

>    - The append(A, x) operation that mutates it's first argument is a
>    little awkward semantically/implementation-wise, since it looks like a
>    function call but can't be handled as one: the first argument is an LValue
>    whereas a function argument is an RValue.  The logic for handling L/RValues
>    in Swift/T is quite different in the grammar/frontend/semantic analyser.  I
>    can easily enough make "append" a reserved word and special-case it in the
>    grammar to work around this, but it feels a bit "wrong" and inconsistent to
>    have something that looks like a function that's doesn't obey the semantics
>    of a function.  I remember Swift/K had a += operator at one point - what
>    was the argument for moving away from it?

I think that we voted on 'a << value', and that is still supported.
Quoting from the swift parser's list of operators:
GE        :   ">=";
APPEND    :   "<<";
ASSIGN  :   '=' ;

I can't find the emails in the online archive, but I do have this in my
inbox:

Subject: 	Re: [Swift-devel] New syntax for appending to arrays
Date: 	Tue, 28 Jun 2011 15:48:05 -0500 (06/28/11 13:48:05)

> So far we have:
> 3, 0, 3, 5, 3, 3, (0, 1, 5)
>
> Anybody else?
>
> On Tue, 2011-06-28 at 14:29 -0500, Mihael Hategan wrote:
> > On Tue, 2011-06-28 at 09:08 -0500, Ian Foster wrote:
> > > $0,02 from me -- given that Swift has a C-like syntax, this syntax
will surely confuse people??
> > 
> > "+=" is a bit confusing, but then I don't think it's more so than
using
> > "+" as a string concatenation operator.
> > 
> > So please vote or propose an alternative:
> > 
> > 0. a += 1;
> > 1. a ++= 1;
> > 2. a ++ 1;
> > 3. a << 1;
> > 4. a[] = 1;
> > 5. a .= 1;

Mihael