### Re: Packed arrays and assignment vs binding

```On 11/14/2010 03:46 AM, Mason Kramer wrote:
I understand everything you've written except the following:

On Nov 13, 2010, at  12:09 PM, Jonathan Worthington wrote:

Hi,
...

my Int @x;

Where we get an array of scalar containers, each of which is only allowed to
contain an Int (strictly, something that Int.ACCEPTS(...) hands back true
on).
@x[0] = 1;
@x[0] := 1;

In the first, we look up the container in slot 0 or the array and assign a 1
into it. In the second, we bind a 1 directly into the slot. There's no
container any more (so any future assignment attempts will fail, for
example).

...

Jonathan

What's a 1?  If it's not an Int, I don't know what it is.  If it is an Int, I
don't understand how you could bind it into a packed array.

On IRC, Jonathan said that 1 is basically an Int, which is something
like a boxed int. So whatever operation works removes the box, and puts
the result in the variable.

However I wonder how well that's going to work, since Int can store
arbitrarily large integers, while int can't.
What happens on overflow?

Cheers,
Moritz

```

### Re: Packed arrays and assignment vs binding

```On Sun, Nov 14, 2010 at 2:54 AM, Moritz Lenz mor...@faui2k3.org wrote:
On IRC, Jonathan said that 1 is basically an Int, which is something
like a boxed int. So whatever operation works removes the box, and puts
the result in the variable.

However I wonder how well that's going to work, since Int can store
arbitrarily large integers, while int can't.
What happens on overflow?

An exception gets thrown, I'm guessing.

--
Jonathan Dataweaver Lang

```

### Packed arrays and assignment vs binding

```
Hi,

Per S09, we can write in Perl 6:

my int @x;

And the idea is that we get a packed array - conceptually, a single lump
of memory allocated and and storing a bunch of ints contiguously.
Contrast this to:

my Int @x;

Where we get an array of scalar containers, each of which is only
allowed to contain an Int (strictly, something that Int.ACCEPTS(...)
hands back true on).

In the latter case, it's fairly clear how these differ:

@x[0] = 1;
@x[0] := 1;

In the first, we look up the container in slot 0 or the array and assign
a 1 into it. In the second, we bind a 1 directly into the slot. There's
no container any more (so any future assignment attempts will fail, for
example).

With packed arrays, however, I'm less clear what they mean. Since the
point of a packed array is compact storage, there's no chance to
actually have containers. Thus does assignment to a slot in a compact
array ever make sense? There's not a container to look up and store
things in.

While I can happily convince myself that:

@x[0] := 1; # works, just sticks 1 into the appropriate location
@x[0] = 1; # dies, can't assign when there's no container

Actually makes sense, I can also somewhat see users not liking it. So my
questions are:

1) What semantics would users expect? Is it OK to say no, you can't

2) If proposing that both should work, what, roughly, would that look
like at an implementation level?

@x[0] = 42;

Currently really means:

infix:=(@x[0], 42);

That is, we really do look up the container and then perform an
operation in it. So if you de-sugar it all, it's kinda like:

VAR(@x[0]).STORE(42)

So just saying oh, just given assignment semantics like binding ones
is not so simple, since it'd seem that we do not get anything we could
call .STORE on back from @x[0] from a natively typed array.

Any thoughts? (Same questions/answers apply for natively typed
attributes in objects, or at least I'd be very surprised if they are
different.)

Thanks,

Jonathan

```

### Re: Packed arrays and assignment vs binding

```Jonathan ():
Per S09, we can write in Perl 6:

my int @x;

And the idea is that we get a packed array - conceptually, a single lump of
memory allocated and and storing a bunch of ints contiguously. Contrast this
to:

my Int @x;

Where we get an array of scalar containers, each of which is only allowed to
contain an Int (strictly, something that Int.ACCEPTS(...) hands back true
on).

In the latter case, it's fairly clear how these differ:

@x[0] = 1;
@x[0] := 1;

In the first, we look up the container in slot 0 or the array and assign a 1
into it. In the second, we bind a 1 directly into the slot. There's no
container any more (so any future assignment attempts will fail, for
example).

With packed arrays, however, I'm less clear what they mean. Since the point
of a packed array is compact storage, there's no chance to actually have
containers. Thus does assignment to a slot in a compact array ever make
sense? There's not a container to look up and store things in.

While I can happily convince myself that:

@x[0] := 1; # works, just sticks 1 into the appropriate location
@x[0] = 1; # dies, can't assign when there's no container

Actually makes sense, I can also somewhat see users not liking it. So my
questions are:

1) What semantics would users expect? Is it OK to say no, you can't assign
in this case?

By this point in the email, you have me convinced that only binding
makes sense in the 'int'-with-a-lowercase-'i' case. So if you ask me,
it is OK to say no, you can't assign in this case.

// Carl

```

### Re: Packed arrays and assignment vs binding

```On Sat, Nov 13, 2010 at 06:09:00PM +0100, Jonathan Worthington wrote:
...
With packed arrays, however, I'm less clear what they mean. Since
the point of a packed array is compact storage, there's no chance to
actually have containers. Thus does assignment to a slot in a
compact array ever make sense? There's not a container to look up
and store things in.

While I can happily convince myself that:

@x[0] := 1; # works, just sticks 1 into the appropriate location
@x[0] = 1; # dies, can't assign when there's no container

Actually makes sense, I can also somewhat see users not liking it.
So my questions are:

1) What semantics would users expect? Is it OK to say no, you can't

2) If proposing that both should work, what, roughly, would that
look like at an implementation level?

I have already come up with exactly the same conclusion on my own.  +1

Also, given my int \$x, \$x := 5 should work, but not \$x = 5.

-sorear

signature.asc
Description: Digital signature

```

### Re: Packed arrays and assignment vs binding

```On 11/13/2010 06:09 PM, Jonathan Worthington wrote:
With packed arrays, however, I'm less clear what they mean. Since the
point of a packed array is compact storage, there's no chance to
actually have containers. Thus does assignment to a slot in a compact
array ever make sense? There's not a container to look up and store
things in.

While I can happily convince myself that:

@x[0] := 1; # works, just sticks 1 into the appropriate location
@x[0] = 1; # dies, can't assign when there's no container

Actually makes sense, I can also somewhat see users not liking it.

Indeed. As a user I think of the = operator as put the thing on the RHS
into the var (or array slot) on the LHS. I don't care about the
underlying container model. I just care that

1) the RHS now contains a 1
2) I don't get any spooky action at a distance.

I'd like those two points to remain the same for packed arrays.

So my questions are:

1) What semantics would users expect? Is it OK to say no, you can't

see above

2) If proposing that both should work, what, roughly, would that look
like at an implementation level?

@x[0] = 42;

Currently really means:

infix:=(@x[0], 42);

That is, we really do look up the container and then perform an
operation in it. So if you de-sugar it all, it's kinda like:

VAR(@x[0]).STORE(42)

So just saying oh, just given assignment semantics like binding ones
is not so simple, since it'd seem that we do not get anything we could
call .STORE on back from @x[0] from a natively typed array.

Any thoughts? (Same questions/answers apply for natively typed
attributes in objects, or at least I'd be very surprised if they are
different.)

I don't have a good idea right now; just consider that whatever ends up
storing a 1 into the array also might need to do a coercion; after all
an Int is not an int. Maybe the two things (handling of assignment and
coercion) are somehow related?

Do we always know at compile time that a certain container is natively
typed? if yes, maybe we can automagically rewrite assignment to binding
at compile time...

If nobody comes up with a practical idea on how to solve it, I'd
grumpily accept only binding for storing things in a natively typed
container. We'd need a *VERY* good error message in that case.

Cheers,
Moritz

```

### Re: Packed arrays and assignment vs binding

```Jonathan Worthington wrote:
In the latter case, it's fairly clear how these differ:

@x[0] = 1;
@x[0] := 1;

In the first, we look up the container in slot 0 or the array and assign a 1
into it. In the second, we bind a 1 directly into the slot. There's no
container any more (so any future assignment attempts will fail, for
example).

I'll have to beg to differ.  My understanding of it is as follows: the
first case works as you describe.  The second case differs, though,
because there is no way to bind a variable directly to a value;
variables can only be bound to containers.  So the interpreter creates
a new item container, assigns 1 to it, and binds the zero slot to
it.  Mind you: when the optimizer gets its hands on this, it'll
probably just simplify it to the first case, as the two are
functionally equivalent.  The distinction only really matters when
you're binding to an already-existing container (e.g., @x[0] = \$foo
vs. @x[0] := \$foo).

With packed arrays, however, I'm less clear what they mean. Since the point
of a packed array is compact storage, there's no chance to actually have
containers. Thus does assignment to a slot in a compact array ever make
sense? There's not a container to look up and store things in.

Assignment makes perfect sense: the compact storage is the container
(which is bound to @x), and you assign a value to a slot in that
container.  What doesn't make sense is binding a slot of a packed
array to some other container:

@x[0] := \$foo; # this should die.

The only way I can see this working is if perl first converts the
packed array into a normal array, and then binds slot 0 to \$foo.

--
Jonathan Dataweaver Lang

```

### Re: Packed arrays and assignment vs binding

```I understand everything you've written except the following:

On Nov 13, 2010, at  12:09 PM, Jonathan Worthington wrote:

Hi,
...

my Int @x;

Where we get an array of scalar containers, each of which is only allowed to
contain an Int (strictly, something that Int.ACCEPTS(...) hands back true on).
@x[0] = 1;
@x[0] := 1;

In the first, we look up the container in slot 0 or the array and assign a 1
into it. In the second, we bind a 1 directly into the slot. There's no
container any more (so any future assignment attempts will fail, for example).

...

Jonathan

What's a 1?  If it's not an Int, I don't know what it is.  If it is an Int, I
don't understand how you could bind it into a packed array.

Could you shed some light on that?

```