[Swift-devel] [Swift-commit] r5316 - in branches/release-0.93/src/org/griphyn/vdl: karajan/lib mapping

[Mihael Hategan]

I guess this has uncovered a fundamental flaw with createArray() (or the
way data works in swift).

createArray() allows the composition of what otherwise would be data
that has no ancestry. Swift has a distinction between data that is part
of a structure and data that isn't. The latter is represented by either
a RootDataNode or a RootArrayDataNode. These two are special in that
they allow mappers to be attached to them and that they assume they are
not part of another data structure.

Any time a Root*Node is assigned to a structure/array field, copies are
made. That works properly (the example below).

I think there are two possible solutions:
1. compile [e1, e2, ...] to a := newArray(), a[0] = e1, ...
2. relax the Root*Node restrictions to allow them to be part of another
structure and have a composite mapper that delegates to the e1, e2, ...
mappers.

Thoughts?

On Fri, 2011-11-25 at 23:30 -0800, Mihael Hategan wrote:

> The theoretically equivalent code:
> file f[];
> f[0] = out; f[1] = out2;
> 
> should work properly.
> 
> In terms of the mapping it will follow the standard swift mapped data
> assignment, which is as follows:
> 1. if lhs is remappable (e.g. concurrent mapper), set the lhs mapping to
> that of the rsh
> 2. if rhs is not remappable but lhs is, set the rhs mapping to that of
> lhs
> 2. if rhs nor lhs are remappable, do a copy.
> 
> What r5316 fixes is code of the form @filename([1, 2, 3]) (i.e. argument
> is something that has no mapping), which is what I thought the problem
> was.
> 
>