Re: references and pointers jargon question

> On Wed, Jan 13, 2016 at 5:36 PM, ToddAndMargo > wrote: > > Hi All, > > Just out of curiosity, is the word "Pointer" a "forbidden" word > in Perl 6 correspondences? Will using the two together "Reference > Pointer" get me in hot water? > > -T >

Re: references and pointers jargon question

Nothing is Forbidden! Everything is Permissible! Also it would make it hard to talk about "is repr('CPointer')" and the Pointer type in NativeCall. While underneath the hood Scalar containers have pointers to values, it's not a particularly useful view of Perl 6. It's more useful to use an OO o

Re: References to parts of declared packages

On Friday, 13. February 2009 20:30:24 Larry Wall wrote: > While taking a shower I refined the design somewhat in my head, > thinking about the ambiguities in package names when you're redefining. > By my previous message, it's not clear whether the intent of > > multi package Foo::Bar {...} > >

Re: References to parts of declared packages

Larry Wall wrote: > Jon Lang wrote: > : And with package versioning, you may not need an "is instead" > : equivalent: if you want to "redefine" a package, just create a newer > : version of it in a tighter lexical scope than the original package was > : in. You can still access the original packag

Re: References to parts of declared packages

On Fri, Feb 13, 2009 at 10:46:42AM -0800, Jon Lang wrote: : And with package versioning, you may not need an "is instead" : equivalent: if you want to "redefine" a package, just create a newer : version of it in a tighter lexical scope than the original package was : in. You can still access the o

Re: References to parts of declared packages

Larry Wall wrote: > Jon Lang wrote: > : Well, we _do_ have a mechanism in place for adding to an existing > : class (e.g., "class Foo is also { ... }"), and classes are a special > : case of modules; so I don't see why you shouldn't be able to do > : likewise with modules and even packages. That s

Re: References to parts of declared packages

On Fri, Feb 13, 2009 at 09:44:12AM -0800, Jon Lang wrote: : TSa wrote: : > Does that imply that packages behave like C++ namespaces? That is : > a package can be inserted into several times: : > : > package A : > { : > class Foo {...} : > } : > # later elsewhere : > package A : >

Re: References to parts of declared packages

TSa wrote: > Does that imply that packages behave like C++ namespaces? That is > a package can be inserted into several times: > > package A > { > class Foo {...} > } > # later elsewhere > package A > { > class Bar {...} > } > > I would think that this is just different sy

Re: References to parts of declared packages

On Fri, Feb 13, 2009 at 06:27:07PM +0100, TSa wrote: > Does that imply that packages behave like C++ namespaces? That is > a package can be inserted into several times: > >package A >{ >class Foo {...} >} ># later elsewhere >package A >{ >class Bar {...} >

Re: References to parts of declared packages

HaloO, Jon Lang wrote: Carl Mäsak wrote: * A should be treated as a post-declared package. Whatever this means, it sounds preferable. :) It means that you can define package A without ever declaring it, by declaring all of its contents using such statements as 'role A::B ', 'sub A::Foo', and

Re: References to parts of declared packages

On Feb 11, 2009, at 2:46 PM, Carl Mäsak wrote: Jon (>), Jonasthan (>>): If we declared, for example: role A::B {}; Then what should a reference to A be here? At the moment, Rakudo treats it as a post-declared listop, however I suspect we should be doing something a bit smarter? If so, w

Re: References to parts of declared packages

Carl Mäsak wrote: >> * A should be treated as a post-declared package. > > Whatever this means, it sounds preferable. :) It means that you can define package A without ever declaring it, by declaring all of its contents using such statements as 'role A::B ', 'sub A::Foo', and so on. -- Jonathan

Re: References to parts of declared packages

Jon (>), Jonasthan (>>): >> If we declared, for example: >> >> role A::B {}; >> >> Then what should a reference to A be here? At the moment, Rakudo treats it >> as a post-declared listop, however I suspect we should be doing something a >> bit smarter? If so, what should the answer to ~A.WHAT be? >

Re: References to parts of declared packages

On Wed, Feb 11, 2009 at 12:15 PM, Jonathan Worthington wrote: > Hi, > > If we declared, for example: > > role A::B {}; > > Then what should a reference to A be here? At the moment, Rakudo treats it > as a post-declared listop, however I suspect we should be doing something a > bit smarter? If so,

Re: References to hash elements?

Simon Cozens <[EMAIL PROTECTED]> writes: > Arthur Bergman: >> I am wondering how the references to hash elements are planned to be >> done? The call to set_ must somehow be delayed until the time is right. > > I would have thought that a hash element would itself be a PMC rather > than an immedia

Re: References to hash elements?

Paul Johnson <[EMAIL PROTECTED]> wrote: > Leopold Toetsch said: >> >> IMHO we are additionally lacking vtable methods to achieve the HLL value >> assign behavior: We only have references inside our aggregates. That >> doesn't matter per se, you can always clone the PMCs before storing, or >> you s

Re: References to hash elements?

Leopold Toetsch said: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > >> This is entirely a matter of opinion and data design ... > > Yep, that's it. The current behavior additionally is inconsistent. > Retrieving a reference (that is Parrot) out of a non-existant hash key > gives and unrelated new Pe

Re: References to hash elements?

Dan Sugalski <[EMAIL PROTECTED]> wrote: > This is entirely a matter of opinion and data design ... Yep, that's it. The current behavior additionally is inconsistent. Retrieving a reference (that is Parrot) out of a non-existant hash key gives and unrelated new PerlUndef, when assigning to that, n

Re: References to hash elements?

At 1:32 PM -0800 1/6/04, Jeff Clites wrote: On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote: Arthur Bergman <[EMAIL PROTECTED]> wrote: Hi, I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. $foo = \$hash{

Re: References to hash elements?

Arthur Bergman <[EMAIL PROTECTED]> wrote: > Hi, > I am wondering how the references to hash elements are planned to be > done? The call to set_ must somehow be delayed until the time is right. Here is a pointer to the last discussion on that topic: Date: Thu, 21 Aug 2003 17:50:00 +0200

Re: References to hash elements?

On Jan 6, 2004, at 1:31 PM, Simon Cozens wrote: Jeff Clites: But here what I'm copying is the _contents_ of the hash slot. True, but irrelevant. :) And here I'm not making a copy, but also the thing I'm taking a reference to is not the same thing I copied above. Here, it's a reference to a hash s

Re: References to hash elements?

Jeff Clites: > But here what I'm copying is the _contents_ of the hash slot. True, but irrelevant. :) > And here I'm not making a copy, but also the thing I'm taking a > reference to is not the same thing I copied above. Here, it's a > reference to a hash slot. No, it isn't. It's a reference t

Re: References to hash elements?

On Jan 6, 2004, at 9:25 AM, Leopold Toetsch wrote: Arthur Bergman <[EMAIL PROTECTED]> wrote: Hi, I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. $foo = \$hash{key}; $$foo = "bar"; $has{key} is now "ba

Re: References to hash elements?

[ apologies for the duplicate email message from my last post--mail client problems... ] On Jan 6, 2004, at 11:50 AM, Simon Cozens wrote: Jeff Clites: $a = $hash{bar}; Here you used the copy constructor before taking the reference. It might look like an assignment operator, but it isn't. You're

Re: References to hash elements?

At 4:53 PM + 1/6/04, Arthur Bergman wrote: Hi, I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. Nope, actually they don't have to be. Simon was correct here. Accessing an element of an aggregate retu

Re: References to hash elements?

Arthur Bergman writes: > > On 6 Jan 2004, at 17:05, Simon Cozens wrote: > > > > >I would have thought that a hash element would itself be a PMC rather > >than an immediate value, so a reference to that should be treated just > >like any other reference to a PMC. > > > > But this does not hold tru

Re: References to hash elements?

On 6 Jan 2004, at 17:05, Simon Cozens wrote: I would have thought that a hash element would itself be a PMC rather than an immediate value, so a reference to that should be treated just like any other reference to a PMC. But this does not hold true if the hash element is in fact conjured up by

Re: References to hash elements?

Simon Cozens writes: > > $a = $hash{bar}; > > Here you used the copy constructor before taking the reference. It might look > like an assignment operator, but it isn't. You're better off thinking that > assignment doesn't exist. It's a copy constructor. It makes the PMC referred > to by $a a copy

Re: References to hash elements?

Jeff Clites: > But there's a semantic difference between a "reference to a hash > element" and a "reference to something which happens to have come out > of a hash". True, but irrelevant. :) > $a = $hash{bar}; Here you used the copy constructor before taking the reference. It might look like a

Re: References to hash elements?

On Jan 6, 2004, at 9:05 AM, Simon Cozens wrote: Arthur Bergman: I am wondering how the references to hash elements are planned to be done? The call to set_ must somehow be delayed until the time is right. I would have thought that a hash element would itself be a PMC rather than an immediate valu

Re: References to hash elements?

Arthur Bergman <[EMAIL PROTECTED]> wrote: > Hi, > I am wondering how the references to hash elements are planned to be > done? The call to set_ must somehow be delayed until the time is right. > $foo = \$hash{key}; > $$foo = "bar"; > $has{key} is now "bar" There was some discussion WRT that is

Re: References to hash elements?

Arthur Bergman: > I am wondering how the references to hash elements are planned to be > done? The call to set_ must somehow be delayed until the time is right. I would have thought that a hash element would itself be a PMC rather than an immediate value, so a reference to that should be treated

Re: References ...

At 11:05 PM 10/9/2003 +0100, Nicholas Clark wrote: On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote: > Melvin Smith <[EMAIL PROTECTED]> wrote: > > > I think if you have the op for dereferencing, you don't need the > > additional ops for > > getting the type of the reference. > > Too

Re: References ...

On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote: > Melvin Smith <[EMAIL PROTECTED]> wrote: > > > I think if you have the op for dereferencing, you don't need the > > additional ops for > > getting the type of the reference. > > Too true, thanks Yes, but if you have to go via anot

Re: References ...

Melvin Smith <[EMAIL PROTECTED]> wrote: > I think if you have the op for dereferencing, you don't need the > additional ops for > getting the type of the reference. Too true, thanks leo

Re: References ...

I think if you have the op for dereferencing, you don't need the additional ops for getting the type of the reference. Maybe in a typed VM it would make sense, but in Parrot, everything is a reference to a PMC, and a PMC knows what type it is. At least that is my opinion. I think the deref op m