Re: Packed arrays and assignment vs binding

2010-11-14 Thread Moritz Lenz
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

2010-11-14 Thread Jon Lang
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

2010-11-13 Thread Jonathan Worthington

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 
assign in this case?


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


When answering (2), consider that:

@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

2010-11-13 Thread Carl Mäsak
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

2010-11-13 Thread Stefan O'Rear
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
 assign in this case?
 
 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

2010-11-13 Thread Moritz Lenz
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 
 assign in this case?

see above

 2) If proposing that both should work, what, roughly, would that look 
 like at an implementation level?
 
 When answering (2), consider that:
 
 @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

2010-11-13 Thread Jon Lang
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

2010-11-13 Thread Mason Kramer
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?