Re: What should +:21a produce?
* Patrick R. Michaud [EMAIL PROTECTED] [2008-09-15 02:25]: So, I'm wondering what happens in the string-to-number case if there happen to be characters within the angles that are not valid digits for the given radix. A similar question holds for calling radix converters as functions Since the radix specifier/function feels is followed by some variety of circumfix, it feels like an assertion that everything within brackets is a single entity – unlike something undelimited like `0b010ax`, say. So I’d expect it to be like however it is that `say +'oops'` behaves, which is probably to say `0`. Although it would be useful if this were an interesting kind of 0 that knows it came from a parse error (and maybe even which radix was asserted). Larry? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: How to define a new value type?
On Tue, Sep 16, 2008 at 6:11 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Mon, Sep 15, 2008 at 10:09:41PM -0500, John M. Dlugosz wrote: Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote: So, how does one get an object to pretend to be a value type for purposes of assignment? I have been under the impression that value types are supposed to define immutable objects, or at least objects that pretend to be immutable; any operators on them would produce new objects rather than mutating existing ones. [...] I agree. A value type is immutable, where the identity is keyed to the value. Making a value type that can mutate can cause confusion. I'm now thinking that the normal = you write should always give reference assignment semantics. In the case of value types, assuming they are indeed immutable, it does not matter whether they have value or reference assignment semantics, since the same value will give the same identity, regardless of memory (or in-register) representation. [...] I think I can accept this reasoning for now, although it has some strong implications for managing array elements and binding operations (especially given Parrot's model of them). But we'll come up with something, and thanks. Pm I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. For a mutable object, I don't know if that copy should be immediate or deffered by a mechanism of copy on write. Probably that behavior could depend on a trait of the class that implements to be copied object. -- cognominal stef
Re: How to define a new value type?
On Tue, Sep 16, 2008 at 4:26 AM, Stéphane Payrard [EMAIL PROTECTED] wrote: I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. Assignment does copy the value between two containers, but in this case, the value just happens to be a reference to an object. Binding makes another name refer to the same container (not the same value). Imagine that some college roommates have a keyrack near their door where they keep their car keys, each hook labeled with the occupant whose key goes there (maybe at the insistence of one particularly OCD roommate). Mary's car goes into the shop, but her schedule is such that she can use John's car when he doesn't need it, so for a while John and Mary are driving the same car. If she gets a copy of his key and puts it on her own hook, that's like assignment. If she just peels the label off her hook and moves it next to his hook, that's like binding. Either way she's referencing the same object (driving the same car), but the key copy is a more flexible arrangement. -- Mark J. Reed [EMAIL PROTECTED]
Re: How to define a new value type?
HaloO, Darren Duncan wrote: If you are wanting to actually mutate a Dog in a user-visible way rather than deriving another Dog, then I don't think that calling Dog a value type is appropriate. I think that mutating methods of immutable value types just have to modify the identity. The problem is how that relates to references. Take e.g. the Str type my $s = 'abc'; # $s points to 'abc' $s.reverse; where the reverse method returns a new string that somehow has to find its way into $s. That is, the method call sequence has to be different for object types and value types. The start is identical: 1) fetch pointer from container 2) bind self to this pointer and call method For object types this is sufficient because the pointer in the container remains valid. A value type on the other hand needs 3) capture new pointer 4) store new pointer in container Note that the return value of the method is independent of this new pointer to the modified value. To unify these two sequences the system either has to know which type of object the pointer in the container belongs to or all four steps are executed for both types where the mutable ones always return the same pointer. The price to pay for the flexibility of the latter approach is with expensive store operations of the container. Well, or the language is explicit about the capture of the new value. Is this meant with $s.=reverse; # means $s = $s.reverse or is this an error that 'abc' is readonly? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: How to define a new value type?
TSa wrote: HaloO, Darren Duncan wrote: If you are wanting to actually mutate a Dog in a user-visible way rather than deriving another Dog, then I don't think that calling Dog a value type is appropriate. I think that mutating methods of immutable value types just have to modify the identity. The problem is how that relates to references. Take e.g. the Str type my $s = 'abc'; # $s points to 'abc' $s.reverse; [...] Well, or the language is explicit about the capture of the new value. Is this meant with $s.=reverse; # means $s = $s.reverse or is this an error that 'abc' is readonly? $s.reverse returns a reversed copy of $s, and $s.=reverse does the in place reverse, ie it directly modifies $s (but not the string stored in $s. At least conceptually. But you can't observe the differences, afaict) When you read carefully through S29 you'll notice that most methods in immutable classes (like Str, List, Int) only return modified copies, even if they mutate the string in Perl 5. (There are some exceptions like Str.substr, which explicitly 'is rw', and which implies that the object somehow has to gain access to its container). Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: {SPAM} Re: How to define a new value type?
Ter, 2008-09-16 às 18:04 +0200, TSa escreveu: I think that mutating methods of immutable value types just have to modify the identity. The problem is how that relates to references. Take e.g. the Str type I really think we are looking at this problem from the wrong perspective. For an Object to be a value, it means that if you build an object with the same value, it will be seen as the same value that some other object with this value. A sane requirement for this to happen is that value objects are read-only, which is something pretty straight-forward. The thing is that, for a value object, there isn't any difference in saying: my $a := 3; or my $a := 3.clone(); Because the number '3' is a value, and you usually doesn't expect a value to change its value at a distance, that's why Int is Immutable. daniel
Re: How to define a new value type?
Stéphane Payrard cognominal-at-gmail.com |Perl 6| wrote: I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. For a mutable object, I don't know if that copy should be immediate or deffered by a mechanism of copy on write. Probably that behavior could depend on a trait of the class that implements to be copied object. Not the best illustration, but the only one I have prepared so far: http://www.dlugosz.com/Perl6/web/assignment/assign-1.png This shows $x = $y;. The use of := (binding) would affect the leftmost column. my $z := $y; would have $z's symbol table entry point to the same Item as $y, namely #8CD9. Assignment (=) does not clone or copy the object. In the illustration, note that both Items refer to the same Dog (#A829) after assignment. With reference assignment semantics, if you want a copy or clone, you make one as an explicit step. Hence the existence of methods like deepcopy in the base Object of languages with that feature. The copy-on-write behavior you suggest is what Perl 5 does to make operator overloading appear to have value semantics. But Perl 6 does not describe this mechanism in any way. Instead, value types are immutable so it doesn't matter that the object is not cloned. --John
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: I think that mutating methods of immutable value types just have to modify the identity. The problem is how that relates to references. Take e.g. the Str type my $s = 'abc'; # $s points to 'abc' $s.reverse; where the reverse method returns a new string that somehow has to find its way into $s. That is, the method call sequence has to be different for object types and value types. The start is identical: Don't do that. Changing the identity of the object will mean that other containers pointing to the same copy will change, but other containers pointing to another physical copy (but the same id) will not. Well, or the language is explicit about the capture of the new value. Is this meant with $s.=reverse; # means $s = $s.reverse Yes. Define .reverse to return a new object, and use .= if you want it to go back into the same container. I suppose that seeing .= will make it easy for the compiler to optimize, if the object is not shared it can reuse the structure. --John
Re: How to define a new value type?
Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote: For an Object to be a value, it means that if you build an object with the same value, it will be seen as the same value that some other object with this value. Perl 6 formalizes this by defining a value type as one whose identity is keyed to its value. Multiple physical copies in memory (or copies without memory like numbers in registers) will test as identity-equvilent. A sane requirement for this to happen is that value objects are read-only, which is something pretty straight-forward. The thing is that, for a value object, there isn't any difference in saying: my $a := 3; or my $a := 3.clone(); Because the number '3' is a value, and you usually doesn't expect a value to change its value at a distance, that's why Int is Immutable. Yes, with immutable objects you don't have to clone it. Multiple copies can be shared. By making value types as described above also immutable, it formally removes all distinction between reference assignment and value assignment.
