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

[Tim Armstrong]

Awesome, thanks, that clears things up.  For some reason I was thinking
that [auto] was something like an auto-incremented integer.

Does that mean that "b[k] = x"  and append(b, x) are semantically identical
in these two code fragments?

==============
foreach v, k in a {
   b[k] = a[k] * 2;
}
---------------------------
foreach v in a {
   append(b, a[k] * 2);
}
==============

Also, I was wondering how this interacts with mappers?  E.g. if a have an
[auto] array mapped with simple_mapper, then what filenames would be
produced for something like this?
file outfile[] <simple_mapper;prefix="baz",suffix=".txt">;

append(outfile , ...);

append(outfile , ...);


- Tim


On Wed, Sep 4, 2013 at 3:01 PM, Mihael Hategan <hategan at mcs.anl.gov> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20130904/51ca55ce/attachment.html>