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 CNumeric role, and all
+string types perform the CStringy 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.  CInt automatically supports promotion
 to arbitrary precision, as well as holding CInf and CNaN values.
@@ -641,6 +658,8 @@
 may also be explicitly cast to CNum.  (Also, if either side is
 CNum already, C infix:/  gives you a CNum instead of a CRat.)
 
+CRat and CNum both do the CReal role.
+
 Lower-case types like Cint and Cnum 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 Itype object.  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 CFailure value is put into a typed container, it takes
 on the type specified by the container but continues to carry the
 CFailure role.  (The Cundef 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
+   

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 CNumeric role, and all
+string types perform the CStringy 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



+CRat and CNum both do the CReal role.


You should add CInt to this list of things that do CReal.


+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 

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:defines, replace with statement_control:import


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 Cuse declaration is actually a composite of two other declarations,
-Cneed and Cdefines.  Saying
+Cneed and Cimport.  Saying
 
 use Sense common @horse;
 
 breaks down into:
 
 need Sense;
-Sense defines common @horse;
+import Sense common @horse;
 
 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, fact);
 
-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 Dilly String Putty;
-} defines Ness;
+}) Ness;
 
 This really means:
 
@@ -254,6 +254,8 @@
 Ness
 );
 
+Without an import list, Cimport imports the C:DEFAULT imports.
+
 =head1 Runtime Importation
 
 Importing via Crequire 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:authhttp://www.some.com/~jrandom:ver1.2.1;
 class Dog:authmailto:jran...@some.com:ver1.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 CNumeric role, and all
 +string types perform the CStringy 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

 +CRat and CNum both do the CReal role.

 You should add CInt to this list of things that do CReal.

No; you should note that CIntegral does CReal.  Likewise, you
should note that CReal does CNumeric.

 +    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:21100100101
q:8[57013]
q:16~DEADBEEF~

 -As with CHash types, CPair and CMapping are mutable in their
 +As with CHash types, CPair and CPairSet 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:21100100101
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 CHash types, CPair and CMapping are mutable in their
+As with CHash types, CPair and CPairSet 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:21100100101
 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 CHash types, CPair and CMapping are mutable in their
 +As with CHash types, CPair and CPairSet 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 CHash types, CPair and CMapping are mutable in their values
but not in their keys.  Now it reads as As with CHash types,
CPair and CPairSet 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:i 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:i ( Num $x )
+ our Complex multi postfix:i ( Num $x )
 
 Returns a complex number representing the parameter multiplied by the imaginary
 unit Ci.  Note that there is no C.i method.  To follow a variable name