Re: how to write literals of some Perl 6 types?

[TSa]

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?

[TSa]

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?

[Darren Duncan]

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

Support for ensuring invariants from one loop iteration to the next?

[Aristotle Pagaltzis]

Hi all,

I occasionally find myself annoyed at having to do something like
this (I use Perl 5 vernacular, but it actually crops up in every
single language I have ever used):

my $i;

@stuff = grep !$_->valid, @stuff;

while ( @stuff ) {
$_->do_something( ++$i ) for @stuff;

@stuff = grep !$_->valid, @stuff;
}

Here, both the `while` condition and the `for` iteration assume
that [EMAIL PROTECTED] will contain only valid elements. Since I don’t
know whether this is initially the case, I have to repeat the
statement both before the loop and at its bottom.

There is no good way to rearrange this in the general case. The
only way to improve it at all is some variant on this:

my $i;

while (1) {
@stuff = grep !$_->valid, @stuff;

last if not @stuff;

$_->do_something( ++$i ) for @stuff;
}

Here I am forced to give up the formal loop conditional and bury
the termination condition somewhere in the middle of the loop
body. The code doesn’t exactly lie now, but it’s more coy about
its intent than necessary.

Does Perl 6 have some mechanism so I could write it along the
following obvious lines?

my $i;
while ( @stuff ) {
$_->do_something( ++$i ) for @stuff;
}

# plus some way of attaching this fix-up just once
{ @stuff = grep !$_->valid, @stuff }

Regards,
-- 
Aristotle Pagaltzis // 

Re: [perl #42267] [CAGE] Work out how to encourage good editor-independent formatting habits

[Patrick R. Michaud]

On Tue, Dec 02, 2008 at 01:58:23PM -0800, Will Coleda via RT wrote:
> On Sun Apr 01 01:02:06 2007, pcoch wrote:
> > Figure out how to encourage good formatting habits, without assuming
> > that everyone uses emacs or vim, and with minimal clutter in our
> > source code.  Also write a coding standards test to codify this.
> 
> We already have a suite of coding standards tests; is there something 
> specific you had in mind that isn't specifically covered in the 
> corresponding PDD? If not, I vote to reject the ticket.

+1

Pm

Re: [perl #56458] Failure to promote RetContinuation objects -- fixed?

[Patrick R. Michaud]

On Tue, Dec 02, 2008 at 11:39:43PM -0800, Stephen Weeks via RT wrote:
> I think this is fixed in r33451.  Can anyone confirm?
> 
> If nobody speaks up in a few days, we should close this ticket.

I tried the test code in RT #56458 and if I remove the 'pop_eh' 
it appears to work correctly in r33451.  The 'pop_eh' has to
be removed because otherwise the context no longer has an exception
handler in effect at the point where the continuation is invoked.

Perhaps the continuation is expected to keep track of the handlers
in effect at the time the continuation is taken -- if so, I
suspect we need a lot more design/code work.  

In the meantime, I agree that the specific issue raised by this
ticket is fixed in r33451, so we can close the ticket.

Pm

Re: Support for ensuring invariants from one loop iteration to the next?

[Bruce Gray]

On Dec 3, 2008, at 7:14 AM, Aristotle Pagaltzis wrote:
--snip--

Does Perl 6 have some mechanism so I could write it along the
following obvious lines?

my $i;
while ( @stuff ) {
$_->do_something( ++$i ) for @stuff;
}

# plus some way of attaching this fix-up just once
{ @stuff = grep !$_->valid, @stuff }


In Perl 5 or Perl 6, why not move the grep() into the while()?

my $i;
while ( @stuff = grep !$_->valid, @stuff ) {
$_->do_something( ++$i ) for @stuff;
}

Perl 5 example:
$ perl -wle '@z=qw(a bb ccc); while (@z = grep { length($_) < 4 } @z)  
{ print "@z"; $_ .= "." for @z }'

a bb ccc
a. bb.
a..

By the way, your use of '!$_->valid' instead of '$_->valid'
sounds backwards when compared with your text
"...assume that [EMAIL PROTECTED] will contain only valid elements".

--
Hope this helps,
Bruce Gray (Util of PerlMonks)

Re: how to write literals of some Perl 6 types?

[TSa]

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

[perl #60992] .WHAT is treated as a method in Rakudo, not as a macro

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #60992]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=60992 >


 rakudo: class A { method WHAT { "B" } }; A.new.WHAT.say
 rakudo 33440: OUTPUT[B␤]
* masak cackles evilly
 we don't handle .WHAT properly yet.
 pmichaud: but that is correct! :)
 masak: no, it's actually wrong.
 A.new.WHAT.say   # 'A'
 A.new.'WHAT'.say   # 'B'
 pmichaud: WHAT? :)
 pmichaud: I just redefined .WHAT, shouldn't Perl 6 let me do that?
 masak, .WHAT is a macro
 yes, but to access that method you have to use ."WHAT"
 aha.
 because... what ruoso said.
* masak had forgotten that
* masak files rakudobug, then

[perl #60986] Win32 package refuses to install if not run by an administrator

[via RT]

# New Ticket Created by  GW 
# Please include the string:  [perl #60986]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=60986 >


Hi,

I think it is wrong that the Win32 installation package for Parrot
refuses to install if not run by an administrator.

I simply do not want to pollute my system and am therefore using a
non-administrator user for everything. I know that the installation will
then not be able to install filetype bindings, system wide entries in
the registry or install itself in Program Files and that I will need to
modify at least my PATH environment variable to get things working, but
 belive it or not - this is exactly what I want.


   gw

P.S.: Could you also add a link to the bugs page on the LaunchPad site.

Re: Support for ensuring invariants from one loop iteration to the next?

[Aristotle Pagaltzis]

* Bruce Gray <[EMAIL PROTECTED]> [2008-12-03 18:20]:
> In Perl 5 or Perl 6, why not move the grep() into the while()?

Because it’s only a figurative example and you’re supposed to
consider the general problem, not nitpick the specific example…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Support for ensuring invariants from one loop iteration to the next?

[Jon Lang]

Aristotle Pagaltzis wrote:
> * Bruce Gray <[EMAIL PROTECTED]> [2008-12-03 18:20]:
>> In Perl 5 or Perl 6, why not move the grep() into the while()?
>
> Because it's only a figurative example and you're supposed to
> consider the general problem, not nitpick the specific example…

But how is that not a general solution?  You wanted something where
you only have to set the test conditions in one place; what's wrong
with that one place being inside the while()?

-- 
Jonathan "Dataweaver" Lang

Re: Support for ensuring invariants from one loop iteration to the next?

[Mark J. Reed]

OK, so let's look at the general problem.  The structure is this:

doSomething();
while (someCondition())
{
doSomethingElse();
doSomething();
}

...and you want to factor out the doSomething() call so that it only
has to be specified once.

Is that correct, Aristotle?

The "gotcha" is that the first doSomething() is unconditional, while
the first doSomethingElse() should only happen if the loop condition
is met (which means just moving the test to the end of the block
doesn't solve the problem).

IFF the doSomething() can be reasonably combined with the conditional
test, then Bruce's solution works, but that won't necessarily be the
case in general.  Overall, the goal is to ensure that by the end of
the loop the program is in the state of having just called
doSomething(), whether the loop runs or not - while also ensuring that
the program is in that state at the top of each loop iteration.

It does seem like a closure trait sort of thing, but I don't think
it's currently provided by the p6 spec.

Re: Support for ensuring invariants from one loop iteration to the next?

[Mark J. Reed]

On Wed, Dec 3, 2008 at 2:26 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> Overall, the goal is to ensure that by the end of the loop the program is in 
> the state of having just
> called doSomething(), whether the loop runs or not - while also ensuring that 
> the program is in that
> state at the top of each loop iteration.

... including the first, just to point out the problem.

We can guarantee it's set at the top of each loop iteration with
ENTER, but that doesn't get run if the loop never runs.

We can guarantee it's set at the end of the loop with LAST, but that
also doesn't get run if the loop never runs, and doesn't take care of
the first iteration.

> It does seem like a closure trait sort of thing, but I don't think
> it's currently provided by the p6 spec.

I think the cleanest solution is the "coy" one.  This works in pugs:

do
{
doSomething();
if (someCondition())
{
   doSomethingElse();
   redo;
}
}

But I'm not sure that redo in a do block is supposed to be allowed.
If not, you have to do something like this:

loop
{
   doSomething();
   if (someCondition())
   {
  doSomethingElse();
   }
   else
   {
  last;
   }
}





-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Support for ensuring invariants from one loop iteration to the next?

[Patrick R. Michaud]

On Wed, Dec 03, 2008 at 02:26:57PM -0500, Mark J. Reed wrote:
> OK, so let's look at the general problem.  The structure is this:
> 
> doSomething();
> while (someCondition())
> {
> doSomethingElse();
> doSomething();
> }
> 
> ...and you want to factor out the doSomething() call so that it only
> has to be specified once.
> ...
> It does seem like a closure trait sort of thing, but I don't think
> it's currently provided by the p6 spec.

Perhaps PRE ... ?

while (someCondition()) {
PRE { doSomething(); }
doSomethingElse();
}

Or, if you wanted to be sure that doSomething() is always called
at least once:

repeat {
PRE { doSomething(); }
doSomethingElse();
} while someCondition();


In the original post, this would result in:

my $i;
repeat {
PRE { @stuff = grep { !.valid }, @stuff }
.do_something( ++$i ) for @stuff;
} while @stuff;

I don't know if the PRE block automatically throws an exception that 
needs to be caught, or if it simply prevents the block from being run.  
I'm guessing it throws an exception, but if so that should be catchable
w/o too much difficulty.

Pm

Re: Support for ensuring invariants from one loop iteration to the next?

[Mark J. Reed]

On Wed, Dec 3, 2008 at 3:05 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> It does seem like a closure trait sort of thing, but I don't think
>> it's currently provided by the p6 spec.
>
> Perhaps PRE ... ?

Isn't  PRE { blah; } just short for ENTER { die unless blah; } ?

It still has the problem that it won't get executed if the loop body never is.

>
>while (someCondition()) {
>PRE { doSomething(); }
>doSomethingElse();
>}

Might never call doSomething().

> Or, if you wanted to be sure that doSomething() is always called
> at least once:
>
>repeat {
>PRE { doSomething(); }
>doSomethingElse();
>} while someCondition();

Calls doSomethingElse() even if someCondition() is initially false
(violates the "gotcha" I mentioned).

Incidentally, I was just trying to clarify what I think Aristotle was
asking for, and am not saying it's needed. I suspect this might be too
specific a case to worry about, and I'm willing to settle for the
solution in my last message (using an if inside a do or loop block).

-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Support for ensuring invariants from one loop iteration to the next?

[mark . a . biggar]

loop {
doSomething();
next if someCondition();
doSomethingElse();
}

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Mark J. Reed" <[EMAIL PROTECTED]>
> OK, so let's look at the general problem.  The structure is this:
> 
> doSomething();
> while (someCondition())
> {
> doSomethingElse();
> doSomething();
> }
> 
> ...and you want to factor out the doSomething() call so that it only
> has to be specified once.
> 
> Is that correct, Aristotle?
> 
> The "gotcha" is that the first doSomething() is unconditional, while
> the first doSomethingElse() should only happen if the loop condition
> is met (which means just moving the test to the end of the block
> doesn't solve the problem).
> 
> IFF the doSomething() can be reasonably combined with the conditional
> test, then Bruce's solution works, but that won't necessarily be the
> case in general.  Overall, the goal is to ensure that by the end of
> the loop the program is in the state of having just called
> doSomething(), whether the loop runs or not - while also ensuring that
> the program is in that state at the top of each loop iteration.
> 
> It does seem like a closure trait sort of thing, but I don't think
> it's currently provided by the p6 spec.

Re: Support for ensuring invariants from one loop iteration to the next?

[mark . a . biggar]

oops make that 

last if !someCondition();

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: [EMAIL PROTECTED]
> loop {
> doSomething();
> next if someCondition();
> doSomethingElse();
> }
> 
> --
> Mark Biggar
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
>  -- Original message --
> From: "Mark J. Reed" <[EMAIL PROTECTED]>
> > OK, so let's look at the general problem.  The structure is this:
> > 
> > doSomething();
> > while (someCondition())
> > {
> > doSomethingElse();
> > doSomething();
> > }
> > 
> > ...and you want to factor out the doSomething() call so that it only
> > has to be specified once.
> > 
> > Is that correct, Aristotle?
> > 
> > The "gotcha" is that the first doSomething() is unconditional, while
> > the first doSomethingElse() should only happen if the loop condition
> > is met (which means just moving the test to the end of the block
> > doesn't solve the problem).
> > 
> > IFF the doSomething() can be reasonably combined with the conditional
> > test, then Bruce's solution works, but that won't necessarily be the
> > case in general.  Overall, the goal is to ensure that by the end of
> > the loop the program is in the state of having just called
> > doSomething(), whether the loop runs or not - while also ensuring that
> > the program is in that state at the top of each loop iteration.
> > 
> > It does seem like a closure trait sort of thing, but I don't think
> > it's currently provided by the p6 spec.
> 

Re: Support for ensuring invariants from one loop iteration to the next?

[Mark J. Reed]

On Wed, Dec 3, 2008 at 3:42 PM,  <[EMAIL PROTECTED]> wrote:
> loop {
>doSomething();
> next if someCondition();
>doSomethingElse();
> }

That loops forever, doesn't it?   But I think this works:

loop
{
   doSomething();
   last unless someCondition();
   doSomethingElse();
}

--
Mark J. Reed <[EMAIL PROTECTED]>

Re: Support for ensuring invariants from one loop iteration to the next?

[Mark J. Reed]

On Wed, Dec 3, 2008 at 3:44 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 3:42 PM,  <[EMAIL PROTECTED]> wrote:
>> loop {
>>doSomething();
>> next if someCondition();
>>doSomethingElse();
>> }
>
> That loops forever, doesn't it?   But I think this works:
>
> loop
> {
>   doSomething();
>   last unless someCondition();
>   doSomethingElse();
> }

That is, of course, merely the while(1) version from Aristotle's
original message rewritten with Perl 6's loop keyword.  As I said, I'm
OK with that, personally, but it's clearly not what he's looking for.

-- 
Mark J. Reed <[EMAIL PROTECTED]>

Re: Support for ensuring invariants from one loop iteration to the next?

[David Green]

On 2008-Dec-3, at 12:38 pm, Mark J. Reed wrote:
Overall, the goal is to ensure that by the end of the loop the  
program is in the state of having just
called doSomething(), whether the loop runs or not - while also  
ensuring that the program is in that

state at the top of each loop iteration.

... including the first, just to point out the problem.
[...] I think the cleanest solution is the "coy" one.



Me too.  I don't think having the condition in the middle of the block  
is necessarily a bad thing -- that's how the logic is actually  
working, after all.  Fake conditions like "while(1)" are kind of ugly,  
but P6 has "loop", and you can always make it stand out more:


loop
{
  doSomething();

   #CHECK OUR LOOP CONDITION!
   last unless someCondition;

  doSomethingElse();
}


Now for my own loop-related question: FIRST{} can do something on only  
the first iteration through the loop, but there's no NOT-FIRST block  
to do something on the second and subsequent iterations.  Is there an  
elegant way to do something on all but the first loop?



-David

Re: Support for ensuring invariants from one loop iteration to the next?

[Jon Lang]

Mark J. Reed wrote:
> Mark J. Reed wrote:
>> loop
>> {
>>   doSomething();
>>   last unless someCondition();
>>   doSomethingElse();
>> }
>
> That is, of course, merely the while(1) version from Aristotle's
> original message rewritten with Perl 6's loop keyword.  As I said, I'm
> OK with that, personally, but it's clearly not what he's looking for.

But maybe it is.  I suspect that the difficulty with the while(1)
version was the kludgey syntax; the loop syntax that you describe does
the same thing (i.e., putting the test in the middle of the loop block
instead of at the start or end of it), but in a much more elegant
manner.  The only thing that it doesn't do that a more traditional
loop construct manages is to make the loop condition stand out
visually.

-- 
Jonathan "Dataweaver" Lang

Re: how to write literals of some Perl 6 types?

[David Green]

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: Support for ensuring invariants from one loop iteration to the next?

[Eirik Berg Hanssen]

"Mark J. Reed" <[EMAIL PROTECTED]> writes:

> OK, so let's look at the general problem.  The structure is this:
>
> doSomething();
> while (someCondition())
> {
> doSomethingElse();
> doSomething();
> }
>
> ...and you want to factor out the doSomething() call so that it only
> has to be specified once.

  I think Perl 5 will always allow:

while ( doSomething(), someCondition() ) {
  doSomethingElse();
}

  I also think Perl 6 will always allow:

while ( doSomething(); someCondition() ) {
  doSomethingElse();
}

  ... but don't quote me on that.  Unless I'm right. ;-)


Eirik
-- 
Statistics means never having to say you're certain.

Re: how to write literals of some Perl 6 types?

[Jon Lang]

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?

[Patrick R. Michaud]

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?

[Darren Duncan]

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.



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