Re: What should +:21a produce?
Hi, Good day! This is an *Immediate *Opening – *Oracle Apps CRM Tech Lead* – *San Jose**, CA** *– *6+ months contract* *Please send your reply to [EMAIL PROTECTED] Please do not send mails to this id.* *Required:* · The sentence essentially means For a radix of 12, use the characters A and B to represent the values 10 and 11 decimal, and not T and E. In other words, to represent the decimal values 10 and 11 using a base twelve radix, we write :12a and :12b instead of :12t and :12e. My main problem here, what I meant by confused, is that I had interpreted the sentence in the parenthesis as :A... means base 12 and :B... means base 12, which is either a contradiction or a statement that one may use either letter. So that sentence could be better written as For example, use A or B to indicate the literal is in base eleven or base twelve respectively, not E and T. On the other hand, if the N in :N... is always written as a base-10 literal, like :11... and :12..., then I still suggest the synopsis be updated for more clarity, such as using your essentially means sentence. -- Darren Duncan -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed [EMAIL PROTECTED]
Re: What should +:21a produce?
Mark J. Reed wrote: I read the statement use A or B for base 12, not T or E as meaning for the values ten and eleven in base 12, use :12A and :12B, not :12T and :12E. Does it say anywhere that you can use non-decimal notation for the radix specifier itself? 'Cause that strikes me as overcomplicating things for little gain. But even if you could, :A would have to be base 10 and :B base 11... I'm not proposing that Perl 6 support non-decimal notation for the radix specifier, at least not in combination with decimal notation always being used to indicate bases 2-10; better then to just be decimal all the way. However, *if* one wanted a system where a radix specifier could be unambiguously written to look the same as the literal is describing, then I have developed a clean system where that is possible. Essentially, the radix specifier would be a 1-character number written in the same radix as the literal, and whose value is one less than the base, and is equal to the maximum value that a single character literal in that base could have. For bases 2-10, it would look exactly like the current Perl 6 method but that the indicator is smaller by one. Pseudo-examples, in binary,octal,decimal,hex each of which equals twelve: :11100 :714 :912 :FB Now I think this general format has a lot of merit, but I'm not going to propose that Perl 6 changes away from its current system of just using decimal literals that equal the base in question; the current system is still just as good, if different, and does not need replacing, and any replacement needs exact syntax that won't confuse with other language constructs like Pair literals or routine calls. -- Darren Duncan
Offerings - edits pending
This is just a reminder that I have files posted at http://www.dlugosz.com/Perl6/offerings/ waiting for someone in authority to inspect and merge.
Re: How to define a new value type?
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote: Taking only the lhs into account doesn't work in Patrick's code because he has untyped variables. The Dog is only on the rhs. This is why I think we need a binary dispatch. I don't see much use for the type of the LHS, though. C++ dispatches assignment on the declared type of the container on the LHS. This hardly makes sense in Perl 6. I agree. I'm in the middle of a deep meditation on this, and will post later ... maybe in a few days, maybe tonight, depending on my muse. --John
Re: How to define a new value type?
Patrick R. Michaud wrote:
In [1], Larry writes:
[...] we left = in the language
to provide (to the extent possible) the same semantics that it
does in Perl 5. And when it comes to non-value types, there really
are still references, even if we try not to talk about them much.
So I think assignment is basically about copying around identities,
where value types treat identity differently than object types (or
at least, objects types that aren't pretending to be value types).
So, how does one get an object to pretend to be a value type for
purposes of assignment?
Currently if I do the following
class Dog { ... }
my $a = Dog.new;
my $b = $a;
then $a and $b both refer to the same Dog object. How would I
define Dog such that it acts like a value type -- i.e., so that
$b would be a copy of $a and future changes to the object in $a
don't affect $b.
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. Therefore assignment can actually work the same way for all types,
whether value types or not, by making the LHS container just hold an
additional reference to what the RHS container holds. Since the value
types are effectively immutable, there is no harm to them not being copied
by default, and in fact this would be a feature, making it simpler to avoid
unnecessary work.
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.
-- Darren Duncan
Re: Offerings - edits pending
On Mon, Sep 15, 2008 at 06:08:37PM -0500, John M. Dlugosz wrote: This is just a reminder that I have files posted at http://www.dlugosz.com/Perl6/offerings/ waiting for someone in authority to inspect and merge. Would it be worthwhile to provide them as diffs? That way we could easily see what is being changed (and is traditionally the way we have reviewed and applied edits to the Synopses). Yes, I know one can also download the files and make our own diffs, but tradition has been to review and apply diffs in the first place. Pm
Re: How to define a new value type?
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?
Currently if I do the following
class Dog { ... }
my $a = Dog.new;
my $b = $a;
then $a and $b both refer to the same Dog object. How would I
define Dog such that it acts like a value type -- i.e., so that
$b would be a copy of $a and future changes to the object in $a don't
affect $b.
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. Therefore assignment can actually work the
same way for all types, whether value types or not, by making the LHS
container just hold an additional reference to what the RHS container
holds. Since the value types are effectively immutable, there is no
harm to them not being copied by default, and in fact this would be a
feature, making it simpler to avoid unnecessary work.
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 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.
Furthermore, just because you CAN write an infix:= for some types that
give value assignment semantics, you SHOULDN'T do that, any more than
you should write an infix:= to do addition. We want to avoid the Java
et.al. mess, and the ideas behind value types in Perl 6, and the
conceptual separation already present in comparison operators, gives the
natural solution:
You don't have value types a'la Java that behave differently with
respect to assignment. Just like you can TEST for identity or value
equality by your choice of === or 'eqv', you can specify reference
assignment or value assignment (if available) by your choice of
operator. To match the testing operators and existing meaning for '=',
I suggest that '=' ALWAYS be reference assignment and not be overloaded
to do something else, and the word 'assign' (to go with words being used
for value tests: 'eqv', 'before', 'after') be a method that mutates the
object to become 'eqv' the argument. And, if you want to get fancy,
define ← as an infix operator for that meaning.
--John
Re: How to define a new value type?
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
