"&&" in list context

[Christoph Bussenius]

Hi,

I read is S03,

The && and || operators are smarter about list context and return ()
on failure in list context rather than Bool::False. The operators
still short-circuit, but if either operator would return a false
value, it is converted to the null list in list context so that the
false results are self-deleting.

For "&&", wouldn't it be a better idea to return an empty list only if
the *first* operand is false?  In other words, I suggest that "$a && $b"
behave in list context like this:

* If $a is false, return ()
* Otherwise, return $b

Here's a use case that would benefit from this behaviour:

Suppose you want to generate an argument list for an external command.
For some reason you have a boolean value $include_arg3 and you want to
include $arg3 only if $include_arg3 is true:

   my @args = $arg1, $arg2, $include_arg3 && $arg3, $arg4;

Here you probably want to include $arg3 even if it is a false value like
"0", provided that $include_arg3 is true.

Regards,
Christoph

r28502 - in docs/Perl6/Spec: . S32-setting-library

[pugs-commits]

Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502

Modified:
   docs/Perl6/Spec/S02-bits.pod
   docs/Perl6/Spec/S03-operators.pod
   docs/Perl6/Spec/S32-setting-library/Containers.pod
Log:
[S02,S03,S32]
add Stringy role
attempt to distinguish numeric objects from Numeric, Real, Integral, etc roles
split Pair into immutable PairVal and mutable Pair
split Mapping into immutable PairValSet and mutable PairSet
general typological housekeeping that will doubtless gobsmack the implementors


Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-09-29 17:43:15 UTC (rev 28501)
+++ docs/Perl6/Spec/S02-bits.pod2009-09-29 17:50:27 UTC (rev 28502)
@@ -13,8 +13,8 @@
 
 Created: 10 Aug 2004
 
-Last Modified: 20 Sep 2009
-Version: 180
+Last Modified: 29 Sep 2009
+Version: 181
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -622,6 +622,23 @@
 
 =item *
 
+Perl supports generic types through what are called "roles"
+which represent capabilities or interfaces.  These roles
+are generally not used directly as object types.  For instance
+all the numeric types perform the C role, and all
+string types perform the C role, but there's no
+such thing as a "Numeric" object.  Common roles include:
+
+Stringy
+Numeric
+Real
+Integral
+Callable
+Positional
+Associative
+
+=item *
+
 Perl 6 intrinsically supports big integers and rationals through its
 system of type declarations.  C automatically supports promotion
 to arbitrary precision, as well as holding C and C values.
@@ -641,6 +658,8 @@
 may also be explicitly cast to C.  (Also, if either side is
 C already, C<< infix: >> gives you a C instead of a C.)
 
+C and C both do the C role.
+
 Lower-case types like C and C imply the native
 machine representation for integers and floating-point numbers,
 respectively, and do not promote to arbitrary precision, though
@@ -971,8 +990,20 @@
 Failure Failure (lazy exceptions, thrown if not handled properly)
 
 Whenever you declare any kind of type, class, module, or package, you're
-automatically declaring a undefined prototype value with the same name.
+automatically declaring a undefined prototype value with the same name, known
+as the I.  The name itself returns that type object:
 
+Object  Perl 6 object (default block parameter type, either Any or 
junction)
+Any Perl 6 object (default routine parameter type, excludes 
junction)
+Int Any Int object
+Widget  Any Widget object
+
+Type objects stringify to their name with empty parens concatenated.
+Note that type objects are not classes, but may be used to name
+classes:
+
+Widget.new()# create a new Widget
+
 Whenever a C value is put into a typed container, it takes
 on the type specified by the container but continues to carry the
 C role.  (The C function merely returns the most
@@ -1028,11 +1059,11 @@
 if and only if their types and contents are identical (that is, if
 C<$x.WHICH> eqv C<$y.WHICH>).
 
+Str Perl string (finite sequence of Unicode characters)
 Bit Perl single bit (allows traits, aliasing, undef, etc.)
 Int Perl integer (allows Inf/NaN, arbitrary precision, etc.)
-Str Perl string (finite sequence of Unicode characters)
-Num Perl number
-Rat Perl rational
+Num Perl number (approximate Real)
+Rat Perl rational (exact Real)
 Complex Perl complex number
 BoolPerl boolean
 Exception   Perl exception
@@ -1042,7 +1073,10 @@
 Range   A pair of Ordered endpoints
 Set Unordered collection of values that allows no duplicates
 Bag Unordered collection of values that allows duplicates
+PairVal An immutable Pair
+PairValSet  Set of PairVals with no duplicate keys
 Signature   Function parameters (left-hand side of a binding)
+Parcel  List of syntactic objects
 Capture Function call arguments (right-hand side of a binding)
 BlobAn undifferentiated mass of bits
 Instant A point on the continuous atomic timeline (TAI)
@@ -1073,6 +1107,33 @@
 a steady time base, such as POSIX systems, will simply have to make
 their best guess as to the correct atomic time.
 
+These types do (at least) the following roles:
+
+Class   Roles
+=   =
+Str Stringy
+Bit Numeric Boolean
+Int Numeric Integral
+Num Numeric Real
+Rat Numeric Real
+Complex Numeric
+BoolBoolean
+Exception   Failure
+Block   Callable
+ListIterable
+Seq Iterable
+Range   Iterable
+Set Associative[Bool]
+Bag Associative[UInt]
+   

updated num/str/etc roles/types (was Re: r28502 ...)

[Darren Duncan]

pugs-comm...@feather.perl6.nl wrote:

Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502

Log:
[S02,S03,S32]
add Stringy role
attempt to distinguish numeric objects from Numeric, Real, Integral, etc roles
split Pair into immutable PairVal and mutable Pair
split Mapping into immutable PairValSet and mutable PairSet
general typological housekeeping that will doubtless gobsmack the implementors


These generally look like good changes, but I have a few points on which I'd 
like clarification or to make suggestions.



+Perl supports generic types through what are called "roles"
+which represent capabilities or interfaces.  These roles
+are generally not used directly as object types.  For instance
+all the numeric types perform the C role, and all
+string types perform the C role, but there's no
+such thing as a "Numeric" object.  Common roles include:
+
+Stringy


Please clarify; does "Stringy" mean a dense homogeneous sequence of primitives 
in general, meaning that both strings of characters and strings of integers are 
covered (as with a Perl 5 string) or does it just mean characters?


Now, because below you say that both the immutable Str and the mutable Buf do 
Stringy, that implies the former definition, that this isn't restricted to 
characters.


Therefore I recommend that you add Blob to the list of types that does Stringy. 
 In general, a Blob would be a string of bits but it could also be used as a 
string of bytes etc when its length in bits is an appropriate multiple of 8 say.


Stringy operations like the "~" infix should work on Blob too as those aren't 
specific to characters.  (For that matter, maybe infix "~" should also work on 
arrays or other Positional-doers to mean list-stitching, eg "$ary3 = $ary1 ~ 
$ary2", unless you have another better way to do that or it would confuse 
people.)  Likewise, an analogy to substr() should work on Blob.



+Numeric
+Real
+Integral
+Callable
+Positional
+Associative



+C and C both do the C role.


You should add C to this list of things that do C.


+Str Perl string (finite sequence of Unicode characters)
 Bit Perl single bit (allows traits, aliasing, undef, etc.)
 Int Perl integer (allows Inf/NaN, arbitrary precision, etc.)
+Num Perl number (approximate Real)
+Rat Perl rational (exact Real)
 Complex Perl complex number


So, now that we have the Numeric role (or the Real role) to be a catch-all label 
for things that are numeric, does this mean that the Num type now consists 
specifically of approximate real numbers, conceptually meaning that all Num are 
floating-point now, rather than Num being "Rat plus extra" as it seemed before?


I think it would be useful for Num to be specifically float semantics all the 
time, just as Rat is the opposite, as this would help with some predictability.


And users who don't care what they get can now use Real in their routine 
signatures etc rather than Num as the catch-all for real numbers.



 BoolPerl boolean
+PairVal An immutable Pair
+PairValSet  Set of PairVals with no duplicate keys



+These types do (at least) the following roles:
+
+Class   Roles
+=   =
+Str Stringy
+Bit Numeric Boolean
+Int Numeric Integral


Again, you should add Real explicitly as a role that Int does.


+Num Numeric Real
+Rat Numeric Real
+Complex Numeric
+BoolBoolean
+Set Associative[Bool]
+Bag Associative[UInt]
+PairVal Associative
+PairValSet  Associative
+Blob


Again, Stringy should be a role of Blob (as it is of Buf), if Stringy means what 
I think it does.


On a tangent, I suggest renaming S32/Str.pod to S32/Stringy.pod as we now have a 
name of what Str and Buf both are (and Blob could go in there too).


On another tangent, since I'm not sure that Blob literals have been defined in 
Perl 6 yet, I suggest something that combines aspects of numeric and character 
string literals, meaning a radix prefix plus string quotes; for example:


  0b'1100100101'
  0o'57013'
  0x'DEADBEEF'

  :2'1100100101'
  :8'57013'
  :16'DEADBEEF'

Unlike numbers in general, the radixes would be restricted to a positive power 
of 2 because we're talking about binary bits, so eg no :5'' allowed.


Also, as with numbers, an underscore could be allowed in the middle of the 
string simply as a visual separator that doesn't affect the value.


To me, the string quotes says string rather than numeric (which don't use 
quotes), and the radix modifier at the front says bit string rather than 
character string (which don't use radixes).


Unless that conflicts with something, please give it some consideration.

P.S.  On the other hand, if we're ever going to deal with machines where say 
each bit can have 3 or 4 values, as some hardware supports, mayb

r28506 - docs/Perl6/Spec

[pugs-commits]

Author: lwall
Date: 2009-09-29 23:05:11 +0200 (Tue, 29 Sep 2009)
New Revision: 28506

Modified:
   docs/Perl6/Spec/S06-routines.pod
   docs/Perl6/Spec/S11-modules.pod
Log:
[S06,S11] kill infix:, replace with statement_control:


Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-09-29 19:45:52 UTC (rev 28505)
+++ docs/Perl6/Spec/S06-routines.pod2009-09-29 21:05:11 UTC (rev 28506)
@@ -289,7 +289,7 @@
 you may play aliasing tricks like this:
 
 module B {
-GLOBAL defines <&saith $next_id>;
+import GLOBAL <&saith $next_id>;
 saith($next_id);# Unambiguously the global definitions
 }
 

Modified: docs/Perl6/Spec/S11-modules.pod
===
--- docs/Perl6/Spec/S11-modules.pod 2009-09-29 19:45:52 UTC (rev 28505)
+++ docs/Perl6/Spec/S11-modules.pod 2009-09-29 21:05:11 UTC (rev 28506)
@@ -154,14 +154,14 @@
 in different scopes is likely to lead to confusion.)
 
 The C declaration is actually a composite of two other declarations,
-C and C.  Saying
+C and C.  Saying
 
 use Sense ;
 
 breaks down into:
 
 need Sense;
-Sense defines ;
+import Sense ;
 
 These further break down into:
 
@@ -232,18 +232,18 @@
 multi fact (Int $n) is export { [*] 1..$n }
 }
 ...
-Factorial defines 'fact';   # imports the multi
+import Factorial 'fact';   # imports the multi
 
 The last declaration is syntactic sugar for:
 
 BEGIN MY.import_alias(Factorial, );
 
-Despite having the form of an infix operator, this form functions as
-a compile-time declarator, so that these notations can be combined:
+This form functions as a compile-time declarator, so that these
+notations can be combined by putting a declarator in parentheses:
 
-role Silly {
+import (role Silly {
 enum Ness is export ;
-} defines ;
+}) ;
 
 This really means:
 
@@ -254,6 +254,8 @@
 
 );
 
+Without an import list, C imports the C<:DEFAULT> imports.
+
 =head1 Runtime Importation
 
 Importing via C also installs names into the current lexical scope by
@@ -310,8 +312,8 @@
 You may also import symbols from the various pseudo-packages listed in S02.
 They behave as if all their symbols are in the C<:ALL> export list:
 
-CONTEXT defines <$IN $OUT $ERR>;
-CALLER defines <$x $y>;
+import CONTEXT <$IN $OUT $ERR>;
+import CALLER <$x $y>;
 
 # Same as:
 # my ($IN, $OUT, $ERR) ::= ($*IN, $*OUT, $*ERR)
@@ -381,7 +383,7 @@
 class Dog:auth:ver<1.2.1>;
 class Dog:auth:ver<1.2.1>;
 
-Since these are somewhat unwieldy to look at, we allow a shorthand in
+Since these are somewhat unweildy to look at, we allow a shorthand in
 which a bare subscripty adverb interprets its elements according to their
 form:
 

Re: updated num/str/etc roles/types (was Re: r28502 ...)

[Jon Lang]

Darren Duncan wrote:
> These generally look like good changes, but I have a few points on which I'd
> like clarification or to make suggestions.
>
>> +Perl supports generic types through what are called "roles"
>> +which represent capabilities or interfaces.  These roles
>> +are generally not used directly as object types.  For instance
>> +all the numeric types perform the C role, and all
>> +string types perform the C role, but there's no
>> +such thing as a "Numeric" object.  Common roles include:
>> +
>> +    Stringy
>
> Please clarify; does "Stringy" mean a dense homogeneous sequence of
> primitives in general, meaning that both strings of characters and strings
> of integers are covered (as with a Perl 5 string) or does it just mean
> characters?

It's a role, which means to me that it's form over function; interface
rather than implementation.  As such, I'd expect to make Stringy
things that are built out of stuff other than characters.  If need be,
consider making it a parametric role, with a type that defaults to
characters.

> Therefore I recommend that you add Blob to the list of types that does
> Stringy.  In general, a Blob would be a string of bits but it could also be
> used as a string of bytes etc when its length in bits is an appropriate
> multiple of 8 say.
>
> Stringy operations like the "~" infix should work on Blob too as those
> aren't specific to characters.  (For that matter, maybe infix "~" should
> also work on arrays or other Positional-doers to mean list-stitching, eg
> "$ary3 = $ary1 ~ $ary2", unless you have another better way to do that or it
> would confuse people.)  Likewise, an analogy to substr() should work on
> Blob.

I'd rather keep infix:<~> out of Positional, as you can already do
that using infix:<,>.  But I agree about the Blob.

>> +    Numeric
>> +    Real
>> +    Integral
>> +    Callable
>> +    Positional
>> +    Associative
>
>> +C and C both do the C role.
>
> You should add C to this list of things that do C.

No; you should note that C does C.  Likewise, you
should note that C does C.

>> +    Str         Perl string (finite sequence of Unicode characters)
>>     Bit         Perl single bit (allows traits, aliasing, undef, etc.)
>>     Int         Perl integer (allows Inf/NaN, arbitrary precision, etc.)
>> +    Num         Perl number (approximate Real)
>> +    Rat         Perl rational (exact Real)
>>     Complex     Perl complex number
>
> So, now that we have the Numeric role (or the Real role) to be a catch-all
> label for things that are numeric, does this mean that the Num type now
> consists specifically of approximate real numbers, conceptually meaning that
> all Num are floating-point now, rather than Num being "Rat plus extra" as it
> seemed before?
>
> I think it would be useful for Num to be specifically float semantics all
> the time, just as Rat is the opposite, as this would help with some
> predictability.
>
> And users who don't care what they get can now use Real in their routine
> signatures etc rather than Num as the catch-all for real numbers.

As well, both Num and Complex should be Numeric, solving the
long-standing dilemma concerning Real and Complex numbers in Perl.

You might also want to note Ordered (or whatever it's called) as a
common role in Perl; Real does Ordered, but Numeric and Complex do
not.

> On a tangent, I suggest renaming S32/Str.pod to S32/Stringy.pod as we now
> have a name of what Str and Buf both are (and Blob could go in there too).
>
> On another tangent, since I'm not sure that Blob literals have been defined
> in Perl 6 yet, I suggest something that combines aspects of numeric and
> character string literals, meaning a radix prefix plus string quotes; for
> example:
>
>  0b'1100100101'
>  0o'57013'
>  0x'DEADBEEF'
>
>  :2'1100100101'
>  :8'57013'
>  :16'DEADBEEF'

So what about custom delimiters?

q:2<1100100101>
q:8[57013]
q:16~DEADBEEF~

>> -As with C types, C and C are mutable in their
>> +As with C types, C and C are mutable in their
>>  values but not in their keys.  (A key can be a reference to a mutable
>>  object, but cannot change its C<.WHICH> identity.  In contrast,
>>  the value may be rebound to a different object, just as a hash
>>  element may.)
>
> So given that PairSet is mutable as a whole (while PairValSet is immutable),
> can you please clarify the difference between PairSet and Hash, both of
> which have immutable keys and mutable values?

Back when it was Mapping, I was under the impression that the
difference involved whether or not the component Pairs were ordered -
that is, a Mapping was Positional as well as Associative.  I could be
wrong.

-- 
Jonathan "Dataweaver" Lang

Re: updated num/str/etc roles/types (was Re: r28502 ...)

[Darren Duncan]

Jon Lang wrote:

Darren Duncan wrote:

On another tangent, since I'm not sure that Blob literals have been defined
in Perl 6 yet, I suggest something that combines aspects of numeric and
character string literals, meaning a radix prefix plus string quotes; for
example:

 0b'1100100101'
 0o'57013'
 0x'DEADBEEF'

 :2'1100100101'
 :8'57013'
 :16'DEADBEEF'


So what about custom delimiters?

q:2<1100100101>
q:8[57013]
q:16~DEADBEEF~


Well, sure, if its useful; the idea is to amalgam numeric and Str syntax. 
However, because a Blob literal presumably just has 0..9,A-Z,_ characters in its 
payload, one of the main uses of custom delimiter flexibility, which is avoiding 
conflicts with payload elements, isn't necessary.



-As with C types, C and C are mutable in their
+As with C types, C and C are mutable in their
 values but not in their keys.  (A key can be a reference to a mutable
 object, but cannot change its C<.WHICH> identity.  In contrast,
 the value may be rebound to a different object, just as a hash
 element may.)

So given that PairSet is mutable as a whole (while PairValSet is immutable),
can you please clarify the difference between PairSet and Hash, both of
which have immutable keys and mutable values?


Back when it was Mapping, I was under the impression that the
difference involved whether or not the component Pairs were ordered -
that is, a Mapping was Positional as well as Associative.  I could be
wrong.


I was never under the assumption that Mapping was Positional; it was an 
immutable Hash essentially, and both were associative not ordered.  So Mapping 
was renamed to PairValSet, and PairSet was added as a mutable alternative, hence 
how the latter differs from Hash is the question.  I think only Capture et al 
are both associative and ordered.  If you want an ordered list of Pair, I don't 
think that has its own type otherwise, but you can parameterize one from 
Seq/Array/etc.


-- Darren Duncan

Re: updated num/str/etc roles/types (was Re: r28502 ...)

[Jon Lang]

Darren Duncan wrote:
> Jon Lang wrote:
>> So what about custom delimiters?
>>
>> q:2<1100100101>
>> q:8[57013]
>> q:16~DEADBEEF~
>
> Well, sure, if its useful; the idea is to amalgam numeric and Str syntax.
> However, because a Blob literal presumably just has 0..9,A-Z,_ characters in
> its payload, one of the main uses of custom delimiter flexibility, which is
> avoiding conflicts with payload elements, isn't necessary.

True enough.  OTOH, I've also used custom delimiters for visual distinction.

 -As with C types, C and C are mutable in their
 +As with C types, C and C are mutable in their
  values but not in their keys.  (A key can be a reference to a mutable
  object, but cannot change its C<.WHICH> identity.  In contrast,
  the value may be rebound to a different object, just as a hash
  element may.)
>>>
>>> So given that PairSet is mutable as a whole (while PairValSet is
>>> immutable),
>>> can you please clarify the difference between PairSet and Hash, both of
>>> which have immutable keys and mutable values?
>>
>> Back when it was Mapping, I was under the impression that the
>> difference involved whether or not the component Pairs were ordered -
>> that is, a Mapping was Positional as well as Associative.  I could be
>> wrong.
>
> I was never under the assumption that Mapping was Positional; it was an
> immutable Hash essentially, and both were associative not ordered.  So
> Mapping was renamed to PairValSet, and PairSet was added as a mutable
> alternative, hence how the latter differs from Hash is the question.  I
> think only Capture et al are both associative and ordered.  If you want an
> ordered list of Pair, I don't think that has its own type otherwise, but you
> can parameterize one from Seq/Array/etc.

Note that before this most recent change, the document read as "As
with C types, C and C are mutable in their values
but not in their keys."  Now it reads as "As with C types,
C and C are mutable in their values but not in their
keys."  I may be wrong about what the difference between a Mapping and
a Hash used to be; but the above says that Mapping was mutable in its
values, not immutable; and that it was replaced by PairSet, not Pair.
Presumably, there was already something in place to differentiate a
Mapping from a Hash; and whatever that difference was, it still
applies to PairSet vs. Hash (which would possibly make PairSet a poor
choice of names, depending on the difference).

-- 
Jonathan "Dataweaver" Lang

r28512 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: colomon
Date: 2009-09-30 04:30:39 +0200 (Wed, 30 Sep 2009)
New Revision: 28512

Modified:
   docs/Perl6/Spec/S32-setting-library/Numeric.pod
Log:
[docs/Perl6] postfix: should return a Complex.

Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod
===
--- docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-09-30 00:28:37 UTC 
(rev 28511)
+++ docs/Perl6/Spec/S32-setting-library/Numeric.pod 2009-09-30 02:30:39 UTC 
(rev 28512)
@@ -193,7 +193,7 @@
 
 =item i
 
- our Num multi postfix: ( Num $x )
+ our Complex multi postfix: ( Num $x )
 
 Returns a complex number representing the parameter multiplied by the imaginary
 unit C.  Note that there is no C<.i> method.  To follow a variable name