Re: how to write literals of some Perl 6 types?
Dave Whipp wrote: Carl Mäsak wrote: Paul (): I can't find anything in the existing synopses about Blobs. Probably looking in the wrong place, sorry. http://perlcabal.org/syn/S02.html#line_912 Re-reading that, a slightly tangent (though still on topic, I hope) thought come to mind. The definition of the Mapping immutable type: Mapping Set of Pairs with no duplicate keys The question is, what to do when a Mapping is created from a source that contains pairs with duplicate keys? The Perl5 answer is simply to silently drop all but the last in the list ... but I can think of many other answers: sometimes you might want an error; other times you might want to create a list/set/bag from the values of the duplicate keys; other times a junction might be appropriate. One theme of P6 is to not lose information unnecessarily -- which is what P5 does here. It would be nice indeed if there were a simple syntax for specifying that. OTOH it's not hard to do it manually in two lines or so. The option of creating a list of the values is interesting because, in scalar context, a list returns the value of its last item That's Perl 5 semantics, not Perl 6. In Perl 6 a List in scalar context becomes a List or Array object: $ ./perl6 -e 'my $x = 1, 2, 3; say $x.perl' [1, 2, 3] -- which is the existing P5 semantics but without losing information until the value is used as a scalar. And lists can be used to construct all the other interesting cases. Will there be a syntax for choosing the strategy for reducing a list of pairs that contains duplicate keys to a Mapping? Moritz
Re: how to write literals of some Perl 6 types?
Carl Mäsak wrote: Paul (): I can't find anything in the existing synopses about Blobs. Probably looking in the wrong place, sorry. http://perlcabal.org/syn/S02.html#line_912 Re-reading that, a slightly tangent (though still on topic, I hope) thought come to mind. The definition of the Mapping immutable type: Mapping Set of Pairs with no duplicate keys The question is, what to do when a Mapping is created from a source that contains pairs with duplicate keys? The Perl5 answer is simply to silently drop all but the last in the list ... but I can think of many other answers: sometimes you might want an error; other times you might want to create a list/set/bag from the values of the duplicate keys; other times a junction might be appropriate. One theme of P6 is to not lose information unnecessarily -- which is what P5 does here. The option of creating a list of the values is interesting because, in scalar context, a list returns the value of its last item -- which is the existing P5 semantics but without losing information until the value is used as a scalar. And lists can be used to construct all the other interesting cases. Will there be a syntax for choosing the strategy for reducing a list of pairs that contains duplicate keys to a Mapping?
Re: Re: how to write literals of some Perl 6 types?
Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? There are; As long as the short name is unambiguous, it can be used. What doe *short* name mean? Bool::T or True?
Re: Re: how to write literals of some Perl 6 types?
On Fri, Dec 5, 2008 at 1:19 AM, [EMAIL PROTECTED] wrote: There are; As long as the short name is unambiguous, it can be used. What doe *short* name mean? Bool::T or True? It means True. In this case short means unqualified - strip off the package name (leading stuff before the ::). As long as no other package in scope defines something named True, you don't have to specify the package. -- Mark J. Reed [EMAIL PROTECTED]
Re: how to write literals of some Perl 6 types?
* TSa [EMAIL PROTECTED] [2008-12-03 09:30]: And I want to pose the question if we really need two types Bool and Bit. I think so. Binary OR and logical OR are different beasts. As Duncan said, the real question is what’s the point of having Bit when we also have both Int and Blob. I think none. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Equality of values and types (was Re: how to write literals of some Perl 6 types?)
On 2008-Dec-4, at 4:41 pm, Leon Timmermans wrote: On Thu, Dec 4, 2008 at 6:34 PM, TSa [EMAIL PROTECTED] wrote: And how about 'Num 1.0 === Complex(1,0) === Int 1'? IMHO the spec on === is quite clear: two values are never equivalent unless they are of exactly the same type. I guess the question is what kind of similarity is the most useful? On the one hand, we have values that happen to have the same *representation* but different *meaning* (e.g. Weekday::Sun and Star::Sun); on the other hand, we have values with a different representation but the same meaning (e.g. Int 29 and int8 29). Usually the reason for comparing both value and type is to check for the same meaning, rather than accidentally equal representations. So let's imagine a syn operator that checks for the same value and the same family: 1 syn 1.0 syn Complex(1,0) Date '2008-1-2' syn Datetime '2008-1-2 0:00:00' We can't simply rely on == because my Date and Datetime objects can be coerced to numeric values, but they don't mean the same thing as a plain Num or Int. Presumably classes need to indicate their family resemblances somehow. Now, which is more useful? Is it worth having === and syn? -David
Re: how to write literals of some Perl 6 types?
(full quote below) As Duncan said, the real question is what’s the point of having Bit when we also have both Int and Blob. I think none. I can't find anything in the existing synopses about Blobs. Probably looking in the wrong place, sorry. Blobs can handle arbitrary numbers of bits? If so, I agree, a Bit type may be superfluous, since you could compose one easily enough. === Hodges' Rule of Thumb: Don't expect reasonable behavior from anything with a thumb. --- On Fri, 12/5/08, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: From: Aristotle Pagaltzis [EMAIL PROTECTED] Subject: Re: how to write literals of some Perl 6 types? To: perl6-language@perl.org Date: Friday, December 5, 2008, 7:42 AM * TSa [EMAIL PROTECTED] [2008-12-03 09:30]: And I want to pose the question if we really need two types Bool and Bit. I think so. Binary OR and logical OR are different beasts. As Duncan said, the real question is what’s the point of having Bit when we also have both Int and Blob. I think none. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: how to write literals of some Perl 6 types?
Paul (): I can't find anything in the existing synopses about Blobs. Probably looking in the wrong place, sorry. http://perlcabal.org/syn/S02.html#line_912 // Carl
Re: how to write literals of some Perl 6 types?
Jon Lang wrote: Darren Duncan wrote: Now, with some basic types, I know how to do it, examples: Bool # Bool::True Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? There are; As long as the short name is unambiguous, it can be used. Cheers, Moritz
Re: how to write literals of some Perl 6 types?
HaloO, David Green wrote: Using int8 vs Int is presumably a performance issue, but int8 29 and Int 29 *mean* the same thing, so they should be ===. An Enum doesn't mean the same thing as a plain Int, so it shouldn't. IIRC, === is defined to compare only values from the same type domain. For values from different domains it is false. The question I want to have answered here is in which respects int8 differs from Int and which they have in common and how that is expressed in Perl 6. E.g. Int could be a role and int8 is a class that does this role. The standard implementation for integers is some BigInt class that also does the Int role. This class has to be known to other types like int8 for failover when their range of values is left. Well, int8 could failover to int16 first. I wonder if int8 being a class that does the Int role can thus be used as implementation type of a variable: my $x is int8; Would that also imply a constraint of int8? I guess all my concerns boil down to the fact that I don't understand what a protoobject which is returned by WHAT exactly is. E.g. how can int8 and BigInt share the Int protoobject such that === compares them. (As you point out, you can always use something like Weekday::Sun eq Star::Sun or Weekday::Sun == 0 if you want string or numeric equality.) Yes, these comparisons are well defined in the Str and Num domains. 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 write literals of some Perl 6 types?
HaloO, David Green wrote: Using int8 vs Int is presumably a performance issue, but int8 29 and Int 29 *mean* the same thing, so they should be ===. An Enum doesn't mean the same thing as a plain Int, so it shouldn't. And how about 'Num 1.0 === Complex(1,0) === Int 1'? Should all these be identical irrespective the fact that they come from three different type domains? How is that implemented? 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 write literals of some Perl 6 types?
On Thu, Dec 4, 2008 at 6:34 PM, TSa [EMAIL PROTECTED] wrote: HaloO, And how about 'Num 1.0 === Complex(1,0) === Int 1'? Should all these be identical irrespective the fact that they come from three different type domains? How is that implemented? IMHO the spec on === is quite clear: two values are never equivalent unless they are of exactly the same type. IMHO, you shouldn't be using === but == anyway when doing that kind of numerical work. That one should DWIM. Regards, Leon Timmermans
Re: how to write literals of some Perl 6 types?
HaloO, Darren Duncan wrote: But some significant ones I don't know and really want to know: Bit Here we could get away with defining two new enums, e.g. Bit::High and Bit::Low. And I want to pose the question if we really need two types Bool and Bit. Blob Set Bag Mapping [..] having Seq|List is a start, but good Set|Mapping|Bag syntax is needed too. I also think that the Set and Bag types need better syntactic support. I value constructions like '$x (in) (1,2,3)' as good as '$x == 1|2|3' or even better because junctions have the potential to behave different than expected. With set operations the operator makes it clear what is intended. Junctive behavior is always lurking in seemingly harmless constructions like '$x == $y'. Note that the automatic creation of sets from lists of lists is ambiguous because it is unclear if they shall become a set of lists or a set of sets. 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 write literals of some Perl 6 types?
HaloO, [EMAIL PROTECTED] wrote: The literals for Bit are just 0 and 1. I doubt that this works. I assume that there are integer calculations that give the result 1 as an Int. Then comparing these with === to the literal 1 should fail because the types mismatch: my Int $x = 7 - 6; # $x.WHAT is Int $x === 1 ?? say one !! say no Bit; Well, or === behaves a bit more forgiving by canonicalizing types before the comparison. But how does that work, then? I guess a much saner approach is that no object will ever have a type Bit. This type is useful only as constraint on containers and in dispatch. 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 write literals of some Perl 6 types?
TSa wrote: Here we could get away with defining two new enums, e.g. Bit::High and Bit::Low. I like that approach. Go the same way as Bool and Order value literals. Don't know why I didn't think of it before. And I want to pose the question if we really need two types Bool and Bit. I was also pondering something similar. I question the usefulness of Bit as a base type when we have Bool, Int, and Blob. Perhaps Bit is a similar dust bunny, part of the original type list and then forgotten? Seen in the context of Blob, the Bit type seems about as appropriate as having a Char type seen in the context of Str. Char was once mentioned in the synopsis but was then dropped. Now I could see usefulness in a Bit type that was simply defined as a subtype, for example of Int such as UInt is ... making Bit then also a subtype of UInt. Or of Blob where .bits == 1 (.bits is styled like .codes|.graphs etc of Str). Bit is certainly not a replacement for Bool. If only one stays then Bool needs to stay. -- Darren Duncan
Re: how to write literals of some Perl 6 types?
HaloO,
Darren Duncan wrote:
Strong typing in Perl means that Perl is conveniently and reliably
keeping track of this user-intended interpretation of the data, so it is
easy for any piece of code to act on it in a reasonable way. Strong
typing lets user code be clean and understandable as it doesn't have to
do a lot of manual book keeping or error checking that Perl can do for
it, such as detecting the error of passing a character string to a
numeric multiplication operator.
First I have a question to the example of the behavior of a string
in a multiplication. Perl 6 automatically attempts a numerification.
But does that result in a failure for 'foo' or does that return 0?
That is, '3' * 3 == 9 is well formed and 'foo' * 3 is malformed, right?
This convenient and reliable book keeping to me means that there
are points in the execution sequence where type constraints are
checked. E.g. the constraint of a container is checked in an assignment.
But this must be seen as very different to the implementation types
of objects returned by WHAT. E.g. Bool, Bit, UInt and int8 are not
WHAT types. The int8 might be special because there could e.g. be an
overloaded optimized version of infix:+ where 127 + 1 == -128 stays
within the valid range albeit with funny semantics.
One approach to enums is that their WHAT is simply Int. But this
has got the drawback that there can be unwanted accidental equalities
that otherwise would indicate an error.
enum A « :One(1), :Two(2), :Three(3) »;
enum B « :One(1), :Two(2), :Three(3) »;
if A::One === B::One { say accidental equality! }
if A::One === 1 { say wanted equality? }
if A::Two == 2 { say wanted numeric equality! }
multi sub doit (Int $x) {...}
multi sub doit (A $a) {...}
multi sub doit (B $b) {...}
This multi is only allowed if A and B are types distinct from Int which
to me implies that enums have a WHAT that is not Int. Opinions?
A further question is which operators are automatically generated for
enums. Does
my Int $a = A::One;
$a++;
increment from A::One to A::Two or to the Int 2? What shall happen
when A::Three is incremented? Failure or switch to Int? What happens
with non-continuous enums? My vote would be to not generate any
operators with the consequence that
my A $a = A::One;
$a++;
fails when the Int 2 shall be written back into $a. I wonder if the
auto-generation of operators can be requested as follows:
enum A « :One(1), :Two(2), :Three(3) » does Int;
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 write literals of some Perl 6 types?
On 2008-Dec-3, at 10:18 am, TSa wrote: Darren Duncan wrote: Strong typing in Perl means that Perl is conveniently and reliably keeping track of this user-intended interpretation of the data, so it is easy for any piece of code to act on it in a reasonable way. Strong typing lets user code be clean and understandable as it doesn't have to do a lot of manual book keeping or error checking that Perl can do for it, such as detecting the error of passing a character string to a numeric multiplication operator. First I have a question to the example of the behavior of a string in a multiplication. Perl 6 automatically attempts a numerification. But does that result in a failure for 'foo' or does that return 0? That is, '3' * 3 == 9 is well formed and 'foo' * 3 is malformed, right? That's what I would expect. A reasonable default would be for lossless conversions to happen automatically and lossy ones to throw an error. [...Are Enums === Ints?] This multi is only allowed if A and B are types distinct from Int which to me implies that enums have a WHAT that is not Int. Opinions? Using int8 vs Int is presumably a performance issue, but int8 29 and Int 29 *mean* the same thing, so they should be ===. An Enum doesn't mean the same thing as a plain Int, so it shouldn't. (As you point out, you can always use something like Weekday::Sun eq Star::Sun or Weekday::Sun == 0 if you want string or numeric equality.) A further question is which operators are automatically generated for enums. Does my Int $a = A::One; $a++; increment from A::One to A::Two or to the Int 2? What shall happen when A::Three is incremented? Failure or switch to Int? What happens with non-continuous enums? My vote would be to not generate any operators Since ++ works on strings without making them numbers, I think it should increment from A::One to A::Two. But if that's ambiguous, we could drop the ++ and stick with .=succ for non-numeric objects instead. -David
Re: how to write literals of some Perl 6 types?
Darren Duncan wrote: Now, with some basic types, I know how to do it, examples: Bool # Bool::True Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? Otherwise, this approach seems awfully cluttered. -- Jonathan Dataweaver Lang
Re: how to write literals of some Perl 6 types?
On Wed, Dec 03, 2008 at 02:50:23PM -0800, Jon Lang wrote: Darren Duncan wrote: Now, with some basic types, I know how to do it, examples: Bool # Bool::True Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? Otherwise, this approach seems awfully cluttered. Nearly all enum-like things can be spelled without their namespace qualifier, as long as they're unambiguous. So yes, Bool::True can be spelled 'True' as long as there's not some other form of 'True' floating around. Pm
Re: how to write literals of some Perl 6 types?
TSa wrote: Darren Duncan wrote: Strong typing in Perl means that Perl is conveniently and reliably keeping track of this user-intended interpretation of the data, so it is easy for any piece of code to act on it in a reasonable way. Strong typing lets user code be clean and understandable as it doesn't have to do a lot of manual book keeping or error checking that Perl can do for it, such as detecting the error of passing a character string to a numeric multiplication operator. First I have a question to the example of the behavior of a string in a multiplication. Perl 6 automatically attempts a numerification. But does that result in a failure for 'foo' or does that return 0? That is, '3' * 3 == 9 is well formed and 'foo' * 3 is malformed, right? I would expect for both examples to fail, unless '*' is expressly defined to numify its arguments like '==' does, and in that case I would like to know how to get the strict version of '*' that does fail so Perl can do more of my error checking for me. The fact that the first argument is a Str should mean that the programmer expected for the argument to be a general character string (or if they actually meant it to be a number, then Perl should tell them so they can go correct their mistake where they made it a Str); just because it happens to now hold a string that would cleanly coerce to a number doesn't matter; in the general case we don't know that. Str.does(Num) is false since not every Str value has a corresponding Num value. What would be best, I think, is if '*' was defined to be strict to require number arguments, and if people wanted the coercion, they would do it explicitly with the nicely terse '+' prefix (spelling?); eg +$mystr * 3 == 9. This convenient and reliable book keeping to me means that there are points in the execution sequence where type constraints are checked. E.g. the constraint of a container is checked in an assignment. But this must be seen as very different to the implementation types of objects returned by WHAT. E.g. Bool, Bit, UInt and int8 are not WHAT types. I agree with the last 3, but Bool definitely *should* be a distinct .WHAT type. One approach to enums is that their WHAT is simply Int. As applied to all enums in general, that is a *bad* idea, for more reason than one. As one point, saying all enums are Int looks very much like a design smell, taking what has commonly been the way for types defined as enums in C-land and some places, and making it front and center in the user space where it should never generally be seen. But this has got the drawback that there can be unwanted accidental equalities that otherwise would indicate an error. snip Opinions? And there as you've illustrated is one primary reason that all-enums-are-Int is a bad idea. Before I go further, I think for helping context to conceive that every data type (which consists of a set of values) falls into exactly one of 2 disjoint categories, depending on how they are defined, which I will call root type and nonroot type. A root type is one that introduces new values into the type system, and the .WHAT of every value would name a root type; examples of root types are Perl's built-in primitive and collection types as well as all types declared using 'class' (and are defined in terms of named attributes). A nonroot type is one that simply reuses existing values in the type system, and no value would cite one of those as its .WHAT; examples of nonroot types are those declared using 'subtype' and type unions like Cat|Dog. I'm not aware of any Perl 6 types that both introduce new values into the type system and reuse existing ones also, but correct me if I'm wrong. So with that context, I've observed that there seems to be at least 2 distinct meanings that people use for what an enumerated type is. Some people would say an enum introduces new values into the type system (and so is a root type), and others would say an enum reuses existing values (and so is a nonroot type). Looking at the Enum section of Synopsis 12, I'm not quite sure how that is meant to be interpreted. Reading it literally suggests that Perl 6 takes the nonroot approach with enums, saying for example that a Bool is a subtype of integer. On the other hand, it could be saying that the 'enum' syntax is just shorthand for a 'class' declaration with an attribute that is an integer and a function named for each value. I certainly hope that Perl 6 'enum' actually behave like a root type, and when you say: enum Foo ... ... then each value of that has a .WHAT of Foo. -- Darren Duncan
Re: how to write literals of some Perl 6 types?
Moritz Lenz wrote: Darren Duncan wrote: But some significant ones I don't know and really want to know: Bit Blob Set Bag Mapping I guess that Mapping is analog to the List/Seq case: :a(2), :ab; Sure, but given how Pair literals work, how would you know whether the above (if you meant to surround it in parenthesis) is a List|Seq of 2 elements that are Pair, or a Mapping of 2 keys and 2 values? So some other delimiter than plain parenthesis is needed I would think. How does one write anonymous value literals of those types? And I mean directly, not by writing a literal of some other type and using a conversion function to derive the above? Type.new(...) In that case, what is the syntax for what you put in the ...? Is it just a comma-delimited list like when you spell out arguments for an arbitrary routine call with positional or named parameters? Also, if that was the default solution for built-in collection types with no special syntax, I would expect for consistency that you could also say eg Hash.new(...) or Array.new(...) or Seq.new(...) etc; if that's the case, then this situation looks better than otherwise. The above is my main question, but also I wonder about how to make an anonymous literal of a KeyHash|KeySet|KeyBag. I think that's (from a language user's point) the wrong question. These types are not designed to be very much visible for the user, but more like helpers. (Please correct me if I'm wrong here). Fair enough. Actually come to think of it I think those 3 are just subtype Foo of Hash where ... anyway and and they don't need special syntax. Regarding Blob, that's not a collection type and its a fundamental type and it still needs special syntax; I did suggest one in my previous message. As for the collection types, well Foo.new(...) could work if necessary, though terser syntax would be nice to have. What I would like is to be able to write value literals that involve arbitrarily complex nested structures where all the elements at every level are immutable types; having Seq|List is a start, but good Set|Mapping|Bag syntax is needed too. Thank you. -- Darren Duncan
Re: how to write literals of some Perl 6 types?
Darren Duncan wrote:
Hello,
I'm wondering how to write anonymous value literals of some Perl 6 basic
types,
and I didn't see mention of this in synopsis 2.
Now, with some basic types, I know how to do it, examples:
Bool # Bool::True
Int # 42 or 0x17 or :12AB9
Rat|Num # 18.2 or :853.07 or 4/3
Num 1/2
Rat 1 div 2
Seq # (5,6,7)
I'm not sure if that's a Seq or a List.
Array# [8,9,10]
Hash # { :ab, :cd } or { a = 'b', c = 'd' }
Correct me if I'm wrong with the above.
But some significant ones I don't know and really want to know:
Bit
Blob
Set
Bag
Mapping
I guess that Mapping is analog to the List/Seq case:
:a(2), :ab;
How does one write anonymous value literals of those types? And I mean
directly, not by writing a literal of some other type and using a conversion
function to derive the above?
Type.new(...)
The above is my main question, but also I wonder about how to make an
anonymous
literal of a KeyHash|KeySet|KeyBag.
I think that's (from a language user's point) the wrong question.
These types are not designed to be very much visible for the user, but
more like helpers. (Please correct me if I'm wrong here).
And also how does one specify a Rat vs a
Num or what does 18.2 or 4/3 actually get you?
I think that S03 elaborates on that. See also my example above.
Cheers,
Moritz
Re: how to write literals of some Perl 6 types?
The literals for Bit are just 0 and 1. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Carl Mäsak [EMAIL PROTECTED] Darren (): Bit Blob Set Bag Mapping How does one write anonymous value literals of those types? And I mean directly, not by writing a literal of some other type and using a conversion function to derive the above? Why is the latter method insufficient for your needs? // Carl
Re: how to write literals of some Perl 6 types?
Darren Duncan (): Regarding Blob, that's not a collection type and its a fundamental type and it still needs special syntax; I did suggest one in my previous message. Frankly, I don't see why it should need special syntax. Blobs are, most of the time, not typed in through the keyboard (too much/too error-prone). They might be a fundamental type (whatever that means in Perl 6), but they have this feel of low-level, internal, close-to-the-metal bitwise stuff that the user would rather not have to handle directly, but abstract away in some library. In the rare cases in code where a blob is directly assigned to a variable from a literal value, that code might be auto-generated by some script that doesn't get confused by a deluge of digits. For this, a list of integer values and a cast or a conversion function (maybe pack) will do as syntax, in my opinion. // Carl
Re: how to write literals of some Perl 6 types?
Em Seg, 2008-12-01 às 18:21 -0800, Darren Duncan escreveu: I'm wondering how to write anonymous value literals of some Perl 6 basic types, and I didn't see mention of this in synopsis 2. Getting away from your question entirely, I think the issue here is that while Perl 6 has support for strong typing, it is not really expected that you approach your code with such strong typing... Let me try to rephrase that... a Bit is something that .^does(Bit), therefore 0 and 1 can certainly be a Bit, while they can also certainly be an Int... But most importantly, they are probably going to be something implemented in low-level that can be used as a Bit, as a Num or as an Int. I'm not sure this is an aspect that everybody got, but there isn't really a way to tell the actual implementation type of an Object in Perl 6, you can introspect the object as long as you wish, but you'll be always asking something to that object, and the object itself is the one giving the answers, therefore it can lie about itself, and that's fine. There are even rumors that $obj.WHAT should return a canonical type, even if its implemented by some low-level optimized version... So, how to write anonymous value literals of that values? Well, you won't need to do that... daniel
Re: how to write literals of some Perl 6 types?
Carl Mäsak wrote:
Darren ():
Bit
Blob
Set
Bag
Mapping
How does one write anonymous value literals of those types? And I mean
directly, not by writing a literal of some other type and using a conversion
function to derive the above?
Why is the latter method insufficient for your needs?
I consider these types to be just as fundamental as the others I mentioned, some
more so, and it should be possible to define their values in a manner that is
just as clean and terse.
In my mind, having to gain one of the above values by converting to it from some
other type using a function, seems as stupid as having to write a Str literal
and use a strtoint function to get an Int value, when it makes more sense to
just have special syntax for an Int in the first place.
Besides-which, I don't even see any converter functions defined to derive these
from other types.
At the very least I want to know the tersest and cleanest thing I can write, for
each of the above 5 types, that will give me a value of that type.
As one suggestion for a Blob syntax if they don't already exist, is something
derived from both the syntaxes for character strings and numbers:
0b'1100101110' # 1 bit represented per sourcecode char
0o'62' # 3 bits represented per sourcecode char
0x'50B7168E'# 4 bits represented per sourcecode char
Also, the catenation operator ~ and friends should also be defined for Blob.
I'm not as sure what to suggest for the other 4 types, though I suppose in a
pinch they could look less special, like Set{...}, Bag{...}, Mapping{...}
with the contents of the braces like what you'd get declaring a Hash literal.
The point is, I'd like some sort of statement (which can be changed later) from
@Larry in the Synopsis so that I know how to write Perl 6 code that declares
(and addresses elements of where applicable) literals of the above types, and
also so that implementations like Rakudo have guidance to make them work.
Note, in general I like the distinctive syntax, say, of having [] for ordered
collections and {} for unordered collections, as is already the case for Array
and Hash, for both value declaration and element addressing.
-- Darren Duncan
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (): Bit Blob Set Bag Mapping How does one write anonymous value literals of those types? And I mean directly, not by writing a literal of some other type and using a conversion function to derive the above? Why is the latter method insufficient for your needs? Efficiency reasons, among others. We can quibble over the syntax, but it would be awfully nice if implementations were able to generate the data structure as early as possible -- at compile time (for literals containing only constants) or during runtime as a single build pass rather than build-other-type-then-convert (for literals containing runtime-evaluated expressions). If there isn't an easy way for the implementation to make this optimization, then we're stuck with some of the basic types taking twice the time and space to create that other similar types do, for no good reason. Mind you, some implementations may get lucky by using a common all-powerful collection implementation underneath, and turning the conversion into a simple type relabel (constant cost in time and space), but that doesn't generalize to highly-tuned implementations that optimize each collection type's data structures individually. -'f
Re: how to write literals of some Perl 6 types?
On 2008-Dec-2, at 12:33 pm, Geoffrey Broadwell wrote: On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (): How does one write anonymous value literals of those types? Why is the latter method [conversion] insufficient for your needs? Efficiency reasons, among others. Surely the optimizer will perform conversions of constants at compile time. In fact, numbers and strings have to be converted anyway (from a series of characters in the code to a binary int, or whatever). It matters only to the programmer, insofar as we'd like special types to get a special syntax -- I'd like that too, but there's a limit to how much syntax can be unique or special-looking. Numbers have a special syntax in most languages because they use special characters (Arabic numerals), and strings use special quoting characters. (I think Visual Basic uses #1/2/3004# for date-literals.) Cf. Lingua::Romana::Perligata for how Perl might look without special symbols. I can't think of anything significantly better than Set (1,2,3) and so on; we could use Unicode symbols, but I don't think that makes it any easier or clearer (except for symbols that are already established with the required meaning, and the only ones that come to mind are braces to indicate sets -- and of course Perl already uses braces for something else). -David
Re: how to write literals of some Perl 6 types?
Daniel Ruoso wrote:
Em Seg, 2008-12-01 às 18:21 -0800, Darren Duncan escreveu:
I'm wondering how to write anonymous value literals of some Perl 6 basic types,
and I didn't see mention of this in synopsis 2.
Getting away from your question entirely, I think the issue here is that
while Perl 6 has support for strong typing, it is not really expected
that you approach your code with such strong typing...
snip
I'm not sure this is an aspect that everybody got, but there isn't
really a way to tell the actual implementation type of an Object in Perl
6, you can introspect the object as long as you wish, but you'll be
always asking something to that object, and the object itself is the one
giving the answers, therefore it can lie about itself, and that's fine.
There are even rumors that $obj.WHAT should return a canonical type,
even if its implemented by some low-level optimized version...
So, how to write anonymous value literals of that values? Well, you
won't need to do that...
I think some people misunderstand the purpose of strong typing as far as users
are concerned.
In a high level language like Perl, strong typing isn't about physical
implementation details, but rather it is about applying alternative user
interpretations to data. If a user declares a piece of data an Int or a Str or
a Blob (or as any other type), it means that they want to interpret that data as
an integer or a string of characters or a string of bits (or whatever the type
represents).
Strong typing in Perl means that Perl is conveniently and reliably keeping track
of this user-intended interpretation of the data, so it is easy for any piece of
code to act on it in a reasonable way. Strong typing lets user code be clean
and understandable as it doesn't have to do a lot of manual book keeping or
error checking that Perl can do for it, such as detecting the error of passing a
character string to a numeric multiplication operator.
It is expected that the physical representation of data behind the scenes may be
arbitrarily different from the user conception, depending on what the
implementation decides to do, and as you say users don't generally need to know
about that.
On a tangent, as a thought exercise, if you want to have a conceptual level type
representation hierarchy that is very portable and future proof, then there
would be exactly one primitive scalar type, which is the ('big' / unlimited
size) integer, essentially the Int type of Perl 6. You can then say a Bool is
an object with a single Int attribute whose value is zero or one, a Blob is an
object with a single attribute that is a dense array of Int that are 0..1, a Str
is an object that is also a dense array of Int that each represents a character
codepoint or something, a Rat/float is an object with 3 Int attributes for
[radix,mantissa,exponent] and so on. And if you ask, aren't bits lower level on
a computer than integers, I say not if you implement a non-binary computer, such
as one where each memory cell can hold 3 or 4 distinct values rather than 2; so
the concept of integer is more fundamental and universal than bit. Once again,
actual implementations could be more efficient, and users don't usually have to
think down to this level of abstraction, as Perl 6 would provide special syntax
for those other types so users don't have to write them as integers.
Carl Mäsak wrote:
Darren Duncan ():
Regarding Blob, that's not a collection type and its a fundamental type and
it still needs special syntax; I did suggest one in my previous message.
Frankly, I don't see why it should need special syntax. Blobs are,
most of the time, not typed in through the keyboard (too much/too
error-prone). They might be a fundamental type (whatever that means
in Perl 6), but they have this feel of low-level, internal,
close-to-the-metal bitwise stuff that the user would rather not have
to handle directly, but abstract away in some library.
In the rare cases in code where a blob is directly assigned to a
variable from a literal value, that code might be auto-generated by
some script that doesn't get confused by a deluge of digits. For this,
a list of integer values and a cast or a conversion function (maybe
pack) will do as syntax, in my opinion.
Blobs aren't any more close to the metal than Ints or Strs, they're just the
users stated preferred interpretation of data.
For example, if you want to represent a bitmap image as an opaque value, say a
16x16 icon, it probably makes more sense to represent that as a Blob than as a
Str or an Int. Or if you want to represent an arbitrary (small) hex dump of
something as a value, that would make sense to be a Blob value literal.
Note that Blob literals would most likely and should have separator characters
to make it easier to write and read, such as an underscore (like with number
literals), or such as whitespace (if a Blob literal has delimiters).
Even if their use is
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 13:07 -0700, David Green wrote: On 2008-Dec-2, at 12:33 pm, Geoffrey Broadwell wrote: On Tue, 2008-12-02 at 08:50 +0100, Carl Mäsak wrote: Darren (): How does one write anonymous value literals of those types? Why is the latter method [conversion] insufficient for your needs? Efficiency reasons, among others. Surely the optimizer will perform conversions of constants at compile time. It would be nice to expect that (though I don't, actually) ... but the second half of my statement was at least as important. It also matters how this is handled for runtime expressions (literals that aren't constants). I was merely saying that we must avoid deciding the semantics in a way that prevents a runtime-varying literal from being constructed efficiently. -'f
Re: how to write literals of some Perl 6 types?
On Tue, 2008-12-02 at 21:21 +0100, Leon Timmermans wrote: If you really want it, a macro can fix all of this for you. That's the beauty of macros: these kinds of things are possible if you need them. Sure, but user-written macros are also an easy out that allows one to avoid making hard decisions about syntax and semantics. Where the base language is concerned, we should avoid waving our hands and telling the user to paper over our indecisiveness. Though perhaps you meant that the base language should implement a few standard macros that convert sugary syntax into something efficient, in which case I'm fine with that answer. -'f
Re: how to write literals of some Perl 6 types?
Darren (): Bit Blob Set Bag Mapping How does one write anonymous value literals of those types? And I mean directly, not by writing a literal of some other type and using a conversion function to derive the above? Why is the latter method insufficient for your needs? // Carl
