Re: For your encouragement

[Mark J. Reed]

On Fri, Dec 5, 2008 at 2:11 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> Someone needs to reply to the comments from readers who have confused
> DBI and DBDI, and have thus decided we are turning Perl into Java.

DBDI may not be DBI, but they're related, and DBI uses underscores
(though I guess the p6 version might switch to hyphens).  I know
there's no official preference for camelCase vs wide_names in userland
code, but it still seems a tad inconsistent. Unless it's an
intentional "make the two levels of DB access obviously different"
design decision.

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

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

[Carl Mäsak]

Paul (>):
> I can't find anything in the existing synopses about Blobs.
> Probably looking in the wrong place, sorry.

 

// Carl

Re: why infix::(Int, Int --> Rat)

[TSa]

HaloO,

David Green wrote:

On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using "div" instead of "/" should make it pretty clear that you're 
disposing of the remainder.


I strongly agree to that. Actually you are disposing of the
fractional part.



I misremembered div vs. idiv, but how standard is it?


IIRC, that was in the discussion about the euclidean modulo
operation. The final outcome at the time was to have floor
semantics by default.


 I know "div" 
commonly means int division, but not always.  On the one hand, some 
things you just have to learn; on the other, lots of P6 operators have 
word-names as well as symbols, and "div" is the obvious way to spell "/" 
(what else would you call it?).


It's not only the name that is at stake but the rest of the
specification of the div and mod pair. It is specced to be type
specific. E.g. if one implements the Gaussian integers---that
is complex numbers with integer coordinates---I would expect div
to be *closed* on that type and not lead out of the type as it is
prescribed in the Int case. In general I would expect that a type Foo
that supports a notion of division implements div and mod with
signature :(Foo, Foo --> Foo).

Note that the wording of the spec enforces infix::(Num,Complex-->Num)
instead of infix::(Num,Complex-->Complex) and I wonder how a Complex
is numified. This should be changed, too.

The mixed signature cases of div and mod should return the larger of the
two types. E.g. :(Rat, Int --> Rat) and :(Num, Int --> Num) as long as
Num can hold the result. Does Num in general failover to Rat?



A way to get both [quotient and reminder] in one fell swoop would be nice


Agreed; though having two different operators seems a bit unperlish.  


We have the pair of infix (!) operators min, max and the operator
minmax that delivers both values in one go. Copying that prior art
would simply mean to define divmod. I'm fine with that.


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: why infix::(Int, Int --> Rat)

[TSa]

HaloO,

Mark J. Reed wrote:

Well, respelling it is OK, just not sure how.  Python 3 uses // for
integer division, but we don't want to open up that can of worms
again..


We still haven't used '÷' which is Latin1. But if we use that it
should be as infix:<÷>:(Int, Int --> Rat) because this doesn't
need to be accompanied with a mod. That allows div on two Ints to
return an Int which complies to the general prescription for
overloading div and mod homogenously.

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

[David Green]

On 2008-Dec-5, at 7:43 am, David Green wrote:
Now the condition is in the middle and is syntactically separate.   
(It's still not up front, but if the first block is really long, you  
can always... add a comment!)


Well, you don't need a comment -- why not allow the condition to come  
first?


repeat while ( condition(); )
{ something(); },
{ something_else(); }

You need the comma there because the final semicolon is optional, and  
we don't want Perl to think it's an ordinary loop followed by an  
independent block. Probably better is to name the introductory block,  
and then programmers as well as compilers know that something unusual  
is going on:


repeat while (condition)
preamble { something }
{ something_else }



-David

Re: Regex - Accessing captured subrules could be problematic

[Patrick R. Michaud]

On Thu, Dec 04, 2008 at 07:00:55PM +0100, Moritz Lenz wrote:
> GW wrote:
> > I found something that could be problematic (haven't yet found out if it
> > should be a special case) in Synopsis 5. More precisely it is under the
> > chapter "Accessing captured subrules" in the test case
> > t/regex/from_perl6_rules/capture.t lines 67–71:
> > 
> > ok(eval(' "bookkeeper" ~~ m/ ($/)/ '), 'Named backref',
> > :todo);
> > 
> > How can the parser know what you mean by $/? Maybe you want $/
> > followed by  or maybe $/?

I suspect $/ would parse as a single variable.  If you want
the separate subrule one can use whitespace (as noted in other posts)
or brackets (if whitespace is an issue):

[$/]

> The same rule applies for interpolation in strings:
> 
> "my big $house.uc" is parsed as "my big { $house.uc }", ie $house.uc is
> taken as one token, even though a valid interpretation would be to
> interpolate $house first and then append .uc to that string.

Alas, this is not exactly the case here.  Interpolation in strings 
only occurs for things that end with a postcircumfix (parens, braces,
brackets), thus

my $house = 'building';

say "a big $house.uc";#   "a big building.uc"
say "a big { $house.uc }";#   "a big BUILDING"
say "a big $house.uc()";  #   "a big BUILDING"
say "a big { $house }.uc";#   "a big building.uc"

> The Perl 6 solution is that you disambiguate with whitespace if you
> don't want to follow the LTM-rule (ie you'd say '$/ ' in the regex).

I think I would tend to recommend disambiguating with brackets
instead of whitespace -- it's slightly more explicit (similar to
how we recommend disambiguating with parens in other types of expressions).

Pm

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

[Paul Hodges]

(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 // 

Re: why infix::(Int, Int --> Rat)

[Mark J. Reed]

On Fri, Dec 5, 2008 at 9:10 AM, David Green <[EMAIL PROTECTED]> wrote:
> I misremembered div vs. idiv, but how standard is it?  I know "div" commonly
> means int division, but not always.

True enough. In ANSI C, / already does integer division, but there's
also a div() function - the difference there is that div() is
guaranteed to round toward zero, whereas the rounding semantics of /
is implementation-dependent.

> On the one hand, some things you just have to learn; on the other, lots of P6 
> operators have
> word-names as well as symbols, and "div" is the obvious way to spell "/" 
> (what else would you
> call it?).

Well, respelling it is OK, just not sure how.  Python 3 uses // for
integer division, but we don't want to open up that can of worms
again..

>> A way to get both [quotient and reminder] in one fell swoop would be nice
>
> Would it make sense to include the remainder as a trait on the quotient?

Maybe, but it smacks of the old and smelly "0 but true" type hacks to me.

> Or return some other special compound type that numifies to the quotient.

There could be a special-purpose Quotient type with the desired
behavior, but maybe Perl6 would benefit from a generic "stealth list"
type, like Lisp's multiple values.  Such an object behaves like a
simple scalar, even in list context, but if you use the right methods
you can access additional values beyond the obvious one.

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

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

[David Green]

On 2008-Dec-4, at 9:09 am, Aristotle Pagaltzis wrote:
And while it does seems like a closure trait, that seems somewhat  
problematic in that the order of evaluation is weird when compared  
to other closure traits, which I suppose is what led you to declare  
the “coy” solution as the most natural.



I tried to break down the reasons for wanting to write such loops  
different ways:


1) Simple code -- the "coy" solution, with the condition checked in  
the middle of the loop, is the cleanest in that if we put the  
condition anywhere else, we still also need to mark where in the  
middle it should be checked.


2) Clear code -- putting the condition up front (or maybe at the end)  
makes it stand out and more clearly identifies the purpose of the  
loop.  Of course, you still need something in the middle as well as up  
front, so you could simply put a comment up front to explain what's  
going on.


3) Self-documenting code -- this is different from the previous point  
(introspection rather than [non-self] documentation...  like my other  
comment about counting iterations -- you can always add "$i++; #to  
check for second loop", but then the meaning is accidental rather than  
implicit).
I think this gets at the heart of the problem: not merely making code  
do the right thing, but making it "look" the right way, making it use  
a natural idiom.  So something like:


repeat using $block
{
something();

check-condition;
# means: last unless $block;

something_else();
}

But I don't really like the need to add the "check-condition" command.
Maybe something like:

repeat using 
{
something();

LABEL: last unless $block;

something_else();
}


But that still seems too sloppy.  What we need is something a bit like  
the "continue" block, except that it gets executed before the loop- 
condition is checked the first time.  So what if we split the loop- 
body into two parts?


repeat { something(); }
while ( condition(); )
{ something_else(); }


Now the condition is in the middle and is syntactically separate.   
(It's still not up front, but if the first block is really long, you  
can always... add a comment!)



-David

Re: why infix::(Int, Int --> Rat)

[David Green]

On 2008-Dec-4, at 3:08 pm, Mark J. Reed wrote:
Using "div" instead of "/" should make it pretty clear that you're  
disposing of the remainder.


I misremembered div vs. idiv, but how standard is it?  I know "div"  
commonly means int division, but not always.  On the one hand, some  
things you just have to learn; on the other, lots of P6 operators have  
word-names as well as symbols, and "div" is the obvious way to spell  
"/" (what else would you call it?).


A way to get both [quotient and reminder] in one fell swoop would be  
nice


Agreed; though having two different operators seems a bit unperlish.   
Int-div could return two values, but that seems prone to accidentally  
interpolating unwanted remainders into lists or things like that.   
Would it make sense to include the remainder as a trait on the  
quotient?  Or return some other special compound type that numifies to  
the quotient.



-David

Equality of values and types (was Re: how to write literals of some Perl 6 types?)

[David Green]

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?

[Aristotle Pagaltzis]

* 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 // 

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

[Mark J. Reed]

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: Re: how to write literals of some Perl 6 types?

[xyf . xiao]

> 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?

Questions on $! (dollar-bang)

[Moritz Lenz]

Hi,

Stephen Weeks asked for clarification on #perl6 on how to implement $!,
I didn't find the answer for most the issues.

In particular:

* S04 states that .defined and .true mark the Exception object as
handled. But what do those methods return? alway true (since $! contains
undef anyway if there was no exception)? Or do they proxy their payload
(ie try { die $object }; $!.true returns the same as $object.true)?

* What about the other methods? t/spec/S02-magicals/dollar_bang.t
assumes that $! stringifies like its payload. Is that correct?

* Another test (forgot which) actually assumes that $! has the type of
the payload, so that try { die 1; }; $! ~~ Int would return True. This
seems unlikely to me, but I think I should ask anyway: is that
assumption correct?

* dollar_bang.t also has this test:

: try {
: try {
: die 'qwerty';
: }
: ok ~($!) ~~ /qwerty/, 'die sets $! properly';
: die; # use the default argument
: }
: #?rakudo todo 'stringification of $!'
: ok ~($!) ~~ /qwerty/, 'die without argument uses $! properly';

that seems to assume that an empty 'die;' re-uses the previous $! value
- is that correct?

* S04 also says
"Because the contextual variable C<$!> contains all exceptions collected
in the current lexical scope[...]"

What does that mean in terms of implementation? Does $! contain a list
of all assembled exceptions, and item context always gives access to the
last one? Is there a user visible way to access these exceptions?

Cheers,
Moritz