Re: Declarations of constants

2005-05-31 Thread Adam Kennedy

Ingo Blechschmidt wrote:

Hi,

  # Way 1
  my $MEANING_OF_LIFE is constant = 42;


Forgive my ignorance here, but for all of these different ways of doing 
constants, will they all optimize (including partial 
evaluation/currying) at compile/build/init/run-time?


my $gravity is constant = 10; # One significant figure

sub time_to_ground ($height, $accel) {
...acceleration math...
}

my $time = time_to_ground( 500, $gravity );

... thus simplifying internally to

my $time = 1234;

Adam K


Re: Declarations of constants

2005-05-31 Thread Simon Cozens
[EMAIL PROTECTED] (Adam Kennedy) writes:
 Forgive my ignorance here, but for all of these different ways of
 doing constants, will they all optimize (including partial
 evaluation/currying) at compile/build/init/run-time?

Gosh, I hope not.

 my $gravity is constant = 10; # One significant figure
 sub time_to_ground ($height, $accel) {
   ...acceleration math...
 }

The ability to play around with the working of time_to_ground before it
runs is one of the things I like about Perl.

-- 
A language that doesn't have everything is actually easier to program
in than some that do.
-- Dennis M. Ritchie


date and time formatting

2005-05-31 Thread Nathan Gray
As I am interested in human-readable dates and times, and having found
no conclusive discussion on time formatting, I make my recommendation
for a syntax (to start discussion, and allow for date formatting to be
implemented in pugs):

I would like for time() to return an object, which in numeric context is
the number of seconds from the epoch (the new epoch, of course), and
which in string context is a human-readable string.  We could also use
localtime(), and leave time() alone.

Possible syntax could be:

  $time_object = time();
  $epoch_seconds = +$time_object;
  $human_readable = ~$time_object;
  $human_readable = $time_object.format; # default format
  $human_readable = $time_object.format($pattern);
  $human_readable = $time_object.format($pattern, offset = 'local');

The default offset would probably be 'local', and would account for
daylight saving time.  The offset could be changed to a 
floating-point value indicating hours offset from UTC.  A timezone
module could perhaps allow for timezone names, which would allow for
daylight saving time computation for non-local times.  The default
offset would probably be stored in a global variable.

The default format would probably be an ISO 8601 format, like:

  1994-11-05T08:15:30-05:00

and the default format pattern would probably be stored in a global
variable, possibly as an strftime() pattern.

-kolibrie


Re: date and time formatting

2005-05-31 Thread Rob Kinyon
On 5/31/05, Nathan Gray [EMAIL PROTECTED] wrote:
 As I am interested in human-readable dates and times, and having found
 no conclusive discussion on time formatting, I make my recommendation
 for a syntax (to start discussion, and allow for date formatting to be
 implemented in pugs):

What's wrong with porting DateTime?

Rob


Re: date and time formatting

2005-05-31 Thread Patrick R. Michaud
On Tue, May 31, 2005 at 09:23:11AM -0400, Nathan Gray wrote:
 As I am interested in human-readable dates and times, and having found
 no conclusive discussion on time formatting, I make my recommendation
 for a syntax (to start discussion, and allow for date formatting to be
 implemented in pugs):
 
 I would like for time() to return an object, which in numeric context is
 the number of seconds from the epoch (the new epoch, of course), and
 which in string context is a human-readable string.  We could also use
 localtime(), and leave time() alone.

Just a friendly note that since this is a language design issue 
(as opposed to an implementation one) this thread likely belongs 
only on perl6-language and not on perl6-compiler.  I'm just trying
to keep the traffic on the lists at a reasonable volume ... :-)

Followups to p6l, please, unless there's an obvious reason why they
need to be on p6c.

Pm


Re: date and time formatting

2005-05-31 Thread David Storrs


On May 31, 2005, at 9:51 AM, Rob Kinyon wrote:


On 5/31/05, Nathan Gray [EMAIL PROTECTED] wrote:

As I am interested in human-readable dates and times, and having  
found

no conclusive discussion on time formatting, I make my recommendation
for a syntax (to start discussion, and allow for date formatting  
to be

implemented in pugs):



What's wrong with porting DateTime?

Rob



It's back to the old question of what's in core?  Are dates and  
times something that are used in such a large proportion of programs  
that they deserve to be shipped in the basic grammar?  Or perhaps in  
the basic set of packages?


Perl 5 has an entire swath of modules designed to manipulate dates  
and times; this suggests that they are (A) commonly used and (B)  
something that people feel very strongly about the semantics of.



--Dks


Re: comprehensive list of perl6 rule tokens

2005-05-31 Thread Patrick R. Michaud
On Sun, May 29, 2005 at 12:52:25PM -0400, Jeff 'japhy' Pinyan wrote:
 I'm curious if commit and cut capture anything.  They don't start 
 with '?', so following the guidelines, it would appear they capture, but 
 that doesn't make sense.  Should they be written as ?commit and ?cut, 
 or is the fact that they capture silently ignored because they're not 
 consuming anything?
 
 Same thing with null and prior.  And with after P and before P. 
 It should be assumed that !after P doesn't capture because it can only 
 capture if P matches, in which case !after P fails.
 
 So, what's the deal?

I'm not the language designer, but FWIW here is my interpretation.

First, we have to remember that capture now means more than just
grabbing characters from a string -- it also generates a successful 
match and a corresponding match object.  Thus, even though after, 
before, commit, cut, and null are zero width assertions,
maybe they should still produce a corresponding match object 
indicating a successful match.  This might end up being useful in 
alternations or other rule structures:

m/ [ abc commit def | ab ]/ ;
if $commit { say we found 'abcdef'; }

m/ [ abc | def null ]/;
if $null { say we found 'def'; }

I don't *know* that this would be useful, and certainly there are
other ways to achieve the same results, but keeping the same
capture semantics for zero-length assertions seems to work 
out okay.  Of course, to avoid the generation of the match objects 
one can use ?commit, ?cut, ?null, etc.  I suspect that for the 
majority of cases the choice of commit vs. ?commit isn't going to 
make a whole lot of difference, and for the places where it does make 
a difference it's nice to preserve the interpretation being used by 
other subrules.

Things could be a bit interesting from a performance/optimization
perspective; conceivably an optimizer could do a lot better for the
common case if we somehow declared that null, commit, cut, etc. 
never capture.  But I think the execution cost of capturing vs. 
non-capturing in PGE is minimal relative to other considerations,
so we're a bit premature to try to optimize there.  Overall I think
we'll be better off keeping things consistent for programmers at
the language level, and then build better/smarter optimizers into 
the pattern matching engine to handle the common cases.

Pm


Re: date and time formatting

2005-05-31 Thread Rob Kinyon
  What's wrong with porting DateTime?
 
 It's back to the old question of what's in core?  Are dates and
 times something that are used in such a large proportion of programs
 that they deserve to be shipped in the basic grammar?  Or perhaps in
 the basic set of packages?
 
 Perl 5 has an entire swath of modules designed to manipulate dates
 and times; this suggests that they are (A) commonly used and (B)
 something that people feel very strongly about the semantics of.

Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?

Rob


Re: date and time formatting

2005-05-31 Thread Rod Adams

Nathan Gray wrote:


possibly as an strftime() pattern.

 



Can we please make sure that strftime() is _not_ OS dependent like the 
POSIX version is now?


-- Rod Adams


Re: date and time formatting

2005-05-31 Thread David Storrs


On May 31, 2005, at 1:16 PM, Rob Kinyon wrote:


What's wrong with porting DateTime?



It's back to the old question of what's in core?  Are dates and
times something that are used in such a large proportion of programs
that they deserve to be shipped in the basic grammar?  Or perhaps in
the basic set of packages?

Perl 5 has an entire swath of modules designed to manipulate dates
and times; this suggests that they are (A) commonly used and (B)
something that people feel very strongly about the semantics of.



Which still begs the question - why not port DateTime to P6? Why can't
installing a module provide new keywords?

Rob



In reverse order:

- No reason it can't.  Nor did I imply otherwise.

- I didn't say we shouldn't port DateTime.  My point was simply that,  
based on the amount of date-related code on CPAN, this is an issue  
that many people care about quite a bit.  We would probably be well  
served to consider it carefully and decide on what semantics we  
really want.  Maybe DateTime is exactly what everyone wants and all  
we need to do is port it.  On the other hand, there is something to  
be said for Nathan's approach; isn't it worth discussing?



Personally, I've always found date handling to be difficult.  The  
various modules go a long way towards simplifying it, but they  
require calling functions and methods, which forces one to think in a  
low-level algorithmic style.   It would be great if there was a more  
intuitive time/date handling model built into the language...the kind  
of quantum leap in power and intuitiveness that we got from the new  
Rules engine (as opposed to the old regex engine).


Perhaps something like the typed operations that were discussed  
recently:


my ($launch_date = now() + 6 weeks) but time(9am);
say We will launch on a $lauch_date.day_of_week, at  
$launch_date.time_of_day.;
say This gives us  . $launch_date but hours .  hours,  
including weekends and evenings.;


#  outstanding_tickets() returns user-written ticket objects;  
created() returns a time object representing

#  creation time.  The objects stringify to their report.
say Remaining issues, oldest first:;
say \t $_ for sort { $a.creation().age = $b.creation().age }  
outstanding_tickets();


#  Prints 'Meetings are...is Sunday, June 19.;
say Meetings are the third Sunday of each month.  The first  
June meeting is  .
(month(6).days(0))[2] but format(/dayname, monthname  
day/);


The above examples are just noodlings and are not well thought out,  
but hopefully they point in the right direction.


--Dks


Re: date and time formatting

2005-05-31 Thread David Storrs

On May 31, 2005, at 2:22 PM, Rob Kinyon wrote:

 my ($launch_date = now() + 6 weeks) but time(9am);


Sure. $launch_date is of type DateTime. It will numify to the
seconds-since-the-epoch, stringify to some date string, and provide
all the neat-o-keen methods you want it to have.


Works for me.


Frankly, I think we're in violent agreement here.


Sounds like it.  I don't really care if it's built in or comes in a  
module.  I do think that date manipulation is common enough that, if  
it's in a module, the module should come in the basic set.


I met a guy once who made his living doing Java programming.  I asked  
him what he liked about Java and he said Nothing.  I hate it. I only  
do it because it pays.  He then went on to list the reasons he hated  
it--high on the list was that Java is not good at date manipulation.   
Personally, I've done so little Java that I can't really speak to the  
accuracy of his statements, but the message has stuck with me--date  
manipulation is important, and needs to be got right.


To put it another way--it's one of those hard things that Perl 6 is  
trying to make easy.


--Dks



Re: date and time formatting

2005-05-31 Thread Jonathan Scott Duff
On Tue, May 31, 2005 at 01:11:21PM -0500, Rod Adams wrote:
 Nathan Gray wrote:
 possibly as an strftime() pattern.
 
 Can we please make sure that strftime() is _not_ OS dependent like the 
 POSIX version is now?

I don't mind an OS dependent strftime() as long as we have some
formatter that is OS independent.  I expect that strftime() will
eventually fall into disuse as people use the newer, better
formatters.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]


Re: reduce metaoperator on an empty list

2005-05-31 Thread Larry Wall
On Mon, May 23, 2005 at 08:54:19PM +, [EMAIL PROTECTED] wrote:
: 
: There are actuall two usefull definition for %.  The first which Ada calls 
'mod' always returns a value 0=XN and yes it has no working value that is an 
identity.  The other which Ada calls 'rem' defined as follows:
: 
: Signed integer division and remainder are defined by the relation: 
: 
: A = (A/B)*B + (A rem B)
: 
:where (A rem B) has the sign of A and an absolute value less than the 
absolute value of B. Signed integer division satisfies the identity: 
: 
: (-A)/B = -(A/B) = A/(-B)
: 
: It does have a right side identity of +INF.

I think % should behave as Perl 5 has it, especially insofar as it
coerces to integer.  That doesn't mean we can't have mod and/or
rem variants that have other semantics.  Infix operators are pretty
much in their own namespace anyway, so they won't clobber sub names.

Larry


Re: comprehensive list of perl6 rule tokens

2005-05-31 Thread Larry Wall
On Thu, May 26, 2005 at 11:19:42AM -0500, Patrick R. Michaud wrote:
: Do we still have the rule syntax, or was that abandoned in
: favor of ?rule ?  (I know there are still some remnants of ...
: in S05 and A05, but I'm not sure they're intentional.)

It's gone, though we're reserving it for something else we haven't
thought of yet.  :-)

Larry


Re: Sub call resolution

2005-05-31 Thread Larry Wall
On Mon, May 30, 2005 at 08:39:57AM +, Luke Palmer wrote:
: Okay, I'd like to set myself straight.  Sanity check:
: 
: bar($foo, $baz);   # looks for subs (lexical then package), and
: falls back to MMD

Er, no.

: $foo.bar($baz);# looks in ref($foo), then falls back to MMD
: 
: If this is correct, can we simplify the latter to mean MMD only ? 
: Would there be a more symmetric MMD only form?

bar($foo, $baz) is the MMD form.  However, MMD is defined to pay
attention to lexical scoping, and if the innermost definition of
the sub isn't multi, it reverts to ordinary sub dispatch.  If the
innermost definition is multi, then all multies out to a scope
that is not multi are considered.

Basically, all sub calls are inherently MMD, but ordinary subs are
a degenerate wildcard case that hide any outer definitions.

Larry


Re: mod/div

2005-05-31 Thread Mark Reed
On 2005-05-30 05:15, TSa (Thomas Sandlaß) [EMAIL PROTECTED]
wrote:

 Mark Reed wrote: 
 I would really like to see ($x div $y) be (floor($x/$y))
 
 That is: floor( 8 / (-3) ) == floor( -2. ) == -3
 Or do you want -2?
 
 and ($x mod $y) be ($x - $x div $y).
 
 Hmm, since 8 - (-3) == 11 this definition hardly works.

Sorry.  As you surmised, I left off a multiplication.
($x mod $y) should be ($x - $y * ($x div $y)).


 But even with $q = floor( $x / $y ) and $r = $x - $q * $y
 we get 8 - (-3) * (-3) == -1 where I guess you expect -2.

Why would I expect -2?  I don't actually have an preconceptions for negative
divisors.  But after just now taking a second to think about it, I would
expect it to generalize such that 0 = abs($r)  abs($y), with sgn($r) in
{0, sgn($y)}.  So having (8 div -3) == -3 and (8 mod -3) == -1 works fine,
especially since it's consistent with (-8 div 3) == -3 and (-8 mod 3) == 1,
as given by my (corrected) formulae above.

 Looks like you want some case distinction there on the
 sign of $x. 

Absolutely not!  My entire goal is to avoid ever having to do something like
this:

if ($x  0) 
{
$y = formula1($x);
}
elsif ($x == 0)
{
$y = formula2($x);
}
else
{
$y = formula($x);
}

At least, not in cases where the intended result is consistent across 0.
Lots of date arithmetic falls into this category, and works beautifully with
the definitions above.  It lets me do things without bounds checking and
correct the ranges later, because, e.g., plugging in January -20, 0 AD
yields the correct result for December 11, 2 BC.  Such calculations break
dramatically across 0 if you use the definition found in some C
implementations, where (-3 mod 5) == -3.

 If there is a definition that needs no special casing
 then it is the euclidean definition that 0 = $r  abs $y.

In which case, for or your example of 8 == $q * (-3) + $r, $q == -2 and $r
== +2?  Seems odd to me that just swapping the signs (from -8,3 to 8,-3)
yields completely different numbers like that.





Re: comprehensive list of perl6 rule tokens

2005-05-31 Thread Patrick R. Michaud
On Tue, May 31, 2005 at 01:20:57PM -0700, Larry Wall wrote:
 On Thu, May 26, 2005 at 11:19:42AM -0500, Patrick R. Michaud wrote:
 : Do we still have the rule syntax, or was that abandoned in
 : favor of ?rule ?  (I know there are still some remnants of ...
 : in S05 and A05, but I'm not sure they're intentional.)
 
 It's gone, though we're reserving it for something else we haven't
 thought of yet.  :-)

Excellent.  I'll start updating S05 and A05 to match.

While we're on the topic, can we also bless +alnum-digit as
the official syntax instead of +alnum-digit ?  I can make
that change as well.  

And I think I have another post brewing regarding the relationship 
between character classes and subrules, but will save that for a bit 
later.

Pm


Re: (1,(2,3),4)[2]

2005-05-31 Thread Larry Wall
On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote:
: the only advantage in the above case is the different prececences of =
: and == which allows dropping of parens with the latter. i don't
: consider that so important a win as to be used often. and they are at
: equal huffman levels as the =() is matched in length by ==.

There's also the fact that == can bind a lazy list, since we've said
(if I recall correctly) that == actually does binding rather than
assignment, possibly even to the extent that

my $b == foo();

declares $b to be an iterator rather than an array ref.

Larry


Re: (1,(2,3),4)[2]

2005-05-31 Thread Larry Wall
On Tue, May 31, 2005 at 03:42:42PM -0700, Larry Wall wrote:
: On Wed, May 25, 2005 at 07:07:02PM -0400, Uri Guttman wrote:
: : the only advantage in the above case is the different prececences of =
: : and == which allows dropping of parens with the latter. i don't
: : consider that so important a win as to be used often. and they are at
: : equal huffman levels as the =() is matched in length by ==.
: 
: There's also the fact that == can bind a lazy list, since we've said
: (if I recall correctly) that == actually does binding rather than
: assignment, possibly even to the extent that
: 
: my $b == foo();
: 
: declares $b to be an iterator rather than an array ref.

Though that would seem to imply that *$x slurpy parameters should
work that way too, and that's not how they work right now...

Larry


Re: Unicode Operators cheatsheet, please!

2005-05-31 Thread Sam Vilain

Rob Kinyon wrote:

I would love to see a document (one per editor) that describes the
Unicode characters in use and how to make them. The Set implementation
in Pugs uses (at last count) 20 different Unicode characters as
operators.


I have updated the unicode quickref, and started a Perlmonks discussion node
for this to be explored - see http://www.perlmonks.org/index.pl?node_id=462246

Sam.


Re: comprehensive list of perl6 rule tokens

2005-05-31 Thread Patrick R. Michaud
On Thu, May 26, 2005 at 11:19:42AM -0500, Patrick R. Michaud wrote:
   $rule N   indirect rule 
   ::$rulename   N   indirect symbolic rule 
   @rulesN   like '@rules'
   %rulesN   like '%rules'
   { code }  N   code produces a rule
   foo()N   subroutine returns rule
   ( code )  N   code must return true or backtracking ensues
 
 Here the leading tokens are actually $, ::$, @, %, {, , 
 and (, and I suspect we have ?$, ?::$, ?@, and !$, !::$,
 !@, etc. counterparts.  

Oops.  After re-reading A05 I would now assume we don't have
non-capturing counterparts for $rule, @rules, %rules, ... --
they're already non capturing.  From A05:

[Update: Only rules of the form ident are captured by 
default. You can use := to force capture of anything else, 
or the :keepall adverb to capture everything else.]

Somewhere I thought I read that $rule captures to $/{'$rule'},
but I don't find it now, so if A05 holds here, then we don't
need ?$, ?@, ?::$, etc.  (Whew!)  Somehow I much prefer
A05's formulation, in that only rules of the form ident
capture, and we use aliases or parentheses to capture anything
else.

Thus one can say that +alpha, -alpha, [aeiou], !alpha, ?alpha, 
$alpha, @alpha, etc. are all non-capturing constructs.

Pm


Re: Default invocant of methods

2005-05-31 Thread Larry Wall
On Fri, May 27, 2005 at 10:59:25PM +0200, Ingo Blechschmidt wrote:
: Hi,
: 
: what is the default invocant of methods?
: 
:   method blarb ($normal_param) {...}
:   # Same as
:   method blarb (Class | ::?CLASS $invocant: $normal_param) {...}
:   # or
:   method blarb (::?CLASS $invocant: $normal_param) {...}
:   # ?
: 
: I prefer the latter, as then one can't accidentally call a instance
: method on the class -- i.e.
:   Foo.blarb   # will die.

It will almost certainly die anyway the moment you try to do something
instancely with it.

: You can always specify Class as invocant, if you want to have a class
: method.

Hmm, well, maybe, provided Class is the parent of all possible class
classes, but it's not entirely clear we want to assume that.  We could
get potentially get other kinds of metaclass and dispatcher classes
involved, especially if we've inherited things across languages.
At some point you have to trust your dispatcher to hand you things
you can work with, and that may involve some kinds of structural
or role equivalence rather than just class name equivalence.

Hmm, maybe Class is really a role then, and anything that does Class
can pretend to be one.

: Opinions?

From the efficieny viewpoint, I'd rather leave it untyped, and rely
on the dispatcher to do my type checking.  Of course, there are times
you'd like the compiler to know that the type of $?SELF is consistent
with the current class, but that's a different matter than run-time
type checking, which an explicit type tends to imply.

Larry


returns and context

2005-05-31 Thread Gaal Yahas
How do I specify the signature of a context-sensitive function?

 sub foo() returns (what?) {
 return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
 }

If it were two subs, one would is returns Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.

-- 
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/


Re: construction clarification

2005-05-31 Thread Damian Conway

Carl Franks wrote:


I have a class that normally takes a list of named arguments.
I also want to be able to handle a single argument.

class Foo {
  multi method new (Class $class: Str $date) {
return $class.bless(date = $date);
  }
  
  submethod BUILD ($.date, $.time, $.offset) {

# some error checking here
  }
}

my $foo = Foo.new('2005-05-30');

#
Is this the correct way to handle my scenario?


It's *a* correct way. But redundant in this particular case.
The universal new() would handle the one-argument call exactly the same
as your overloaded new() does. Presumably, however, the one-argument variant 
would do something else as well.



My explicit 'new' method should only handle the case of 
a single argument - otherwise the 'new' method 
inherited from Class will handle a list of named 
arguments.


Correct.

My explicit BUILD submethod is called, regardless 
of which 'new' method is called, correct?


Yes. It's invoked by bless().

Damian


Re: Declarations of constants

2005-05-31 Thread Damian Conway

Adam Kennedy wrote:

Forgive my ignorance here, but for all of these different ways of doing 
constants, will they all optimize (including partial 
evaluation/currying) at compile/build/init/run-time?


my $gravity is constant = 10; # One significant figure

sub time_to_ground ($height, $accel) {
...acceleration math...
}

my $time = time_to_ground( 500, $gravity );

... thus simplifying internally to

my $time = 1234;


No. But you could get the effect by explicitly asking for time_to_ground() to 
be called at compile-time:


  my $gravity is constant = 10; # One significant figure

  macro time_to_ground ($height, $accel) {
 ...acceleration math...
  }

  my $time = time_to_ground( 500, $gravity );

Damian


Re: returns and context

2005-05-31 Thread Rod Adams

Gaal Yahas wrote:


How do I specify the signature of a context-sensitive function?

sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}

If it were two subs, one would is returns Int and the other List of
Sheep. The draft S29 uses things like Int|List to express this kind
of thing but that looks weird to me (how would you return a typed
junction?). S06 and E06 don't raise this issue.
 



Being that I'm the one who wrote it that way, it doesn't look at all 
weird to me to do it that way. =)


I suspect a typed junction would look like : Junction of Int|Str.

-- Rod Adams



Re: reduce metaoperator on an empty list

2005-05-31 Thread Damian Conway
All this discussion of identity defaults for reductions has been very 
interesting and enlightening.


But it seems to me that the simplest correct behaviour for reductions is:

2+ args: interpolate specified operator
1 arg:   return that arg
0 args:  fail (i.e. thrown or unthrown exception depending on use fatal)

Then, as Brad previously reminded us all, to cover the possibility of empty 
arg lists, you just prepend the desired identity value:


$sum  = [+] 0, @values;
$prod = [*] 1, @values;
$prob = [*] 0, @probs;

or else, as Stuart observed, postpend them as a default:

$sum  = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs  err 0);


Damian


Re: reduce metaoperator on an empty list

2005-05-31 Thread Dave Whipp

Damian Conway wrote:

0 args:  fail (i.e. thrown or unthrown exception depending on use 
fatal)

...


$sum  = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs  err 0);


Just wanted to check, if I've said use fatal: will that err 0 DWIM, 
or will the fatalness win? Would I need to write


Re: reduce metaoperator on an empty list

2005-05-31 Thread Damian Conway

Dave Whipp wrote:


Damian Conway wrote:

0 args:  fail (i.e. thrown or unthrown exception depending on use 
fatal)


...



$sum  = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs  err 0);



Just wanted to check, if I've said use fatal: will that err 0 DWIM,


That depends what you mean. ;-)
Under use fatal you'll get an exception if you don't provide any args.



or will the fatalness win?


The fatalness will win.



Would I need to write


Yes. :-)

And what you'd need to write would be:

$sum  = (try{ [+] @values } err 0);

Damian


Re: construction clarification

2005-05-31 Thread Larry Wall
On Mon, May 30, 2005 at 05:00:26PM +0100, Carl Franks wrote:
: I have a class that normally takes a list of named arguments.
: I also want to be able to handle a single argument.
: 
: class Foo {
:   multi method new (Class $class: Str $date) {
: return $class.bless(date = $date);
:   }
:   
:   submethod BUILD ($.date, $.time, $.offset) {
: # some error checking here
:   }
: }
: 
: my $foo = Foo.new('2005-05-30');
: 
: #
: Is this the correct way to handle my scenario?

I think you probably want a multi sub there.  In the current plan,
multi method is an MMD dispatch that occurs *after* dispatch to
the class.  (Though it's possible we changed that and I've just
forgotten...)

: My explicit 'new' method should only handle the case of 
: a single argument - otherwise the 'new' method 
: inherited from Class will handle a list of named 
: arguments.

Saying

multi sub new (Class $class, Str $date) {...}

should have that effect, provided you call it as new(Foo,'2005-05-30').

However, when called as Foo.new('2005-05-30'), all the multi subs
defined in the class hierarchy add themselves to the dispatch list
as if they were ordinary single-invocant methods, with additional
invocants treated as tie-breakers in the case that there are
multiple multi-subs in a single class.  Or to put it another way,
all class-based instances of multi sub behave like multi method
when invoked via SMD.  It dispatches first to the class, then looks
to see if there are multiple methods of that name within the class.
This is probably not what you want in this case, unfortunately.
We have specified that there's some kind of pragmatic way to
turn Foo.new() into MMD from the get-go, but that seems a bit crude.

So maybe that kind of dispatch needs to be reformulated a bit.
Perhaps Foo.new() should be forced to ordinary MMD any time any parent
class defines multi sub new, so that all invocants are considered.
Or maybe Foo.new() is still not quite ordinary MMD in that it only
considers that subset of multis defined in Foo or parent classes of
Foo.  If that dispatch fails it retries under ordinary MMD, including
methods defined outside of the classes in question.  (Or another way to
say that might be that such non-class multis are always ordered after
all the class multis when invoked as Foo.new('2005-05-30'), unlike with
new(Foo,'2005-05-30'), which pays no attention to class boundaries.)

: My explicit BUILD submethod is called, regardless 
: of which 'new' method is called, correct?

Yes, as long as the constructor in question calls the .bless built-in,
which always BUILDALL.  (Though you could, of course, also redefine
BUILDALL evilly to bypass calling the correct BUILDs.  But don't
do that.)

Larry


Re: reduce metaoperator on an empty list

2005-05-31 Thread Dave Whipp

Damian Conway wrote:

And what you'd need to write would be:

$sum  = (try{ [+] @values } err 0);


The err ... idiom seems too useful to have it break in this case. 
Afterall, the purpose of err 0 is to tell the stupid computer that I 
know what to do with the empty-array scenario.


Feels like fine grained control over fatalness is needed (and not just 
per-function). For example use fatal :void_context_only would be nice, 
but wouldn't help in this case. This needs use fatal :void_or_assign.


Re: reduce metaoperator on an empty list

2005-05-31 Thread Damian Conway

Dave Whipp wrote:


Damian Conway wrote:


And what you'd need to write would be:

$sum  = (try{ [+] @values } err 0);



The err ... idiom seems too useful to have it break in this case. 
Afterall, the purpose of err 0 is to tell the stupid computer that I 
know what to do with the empty-array scenario.


Feels like fine grained control over fatalness is needed (and not just 
per-function). For example use fatal :void_context_only would be nice, 
but wouldn't help in this case. This needs use fatal :void_or_assign.


What it probably needs is: use fatal :untested

That is, die unless the failed result is in a boolean or definedean context.

This might even be a more reasonably dwimmy default, with 'use fatal :always' 
being required to get always throw the exception.


Damian


Re: reduce metaoperator on an empty list

2005-05-31 Thread Juerd
Damian Conway skribis 2005-06-01 10:44 (+1000):
 2+ args: interpolate specified operator
 1 arg:   return that arg
 0 args:  fail (i.e. thrown or unthrown exception depending on use fatal)

Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 fail 
too?

I dislike this, and would prefer [op] with no elements to simply return
whatever () returns: an empty list in list context, undef in scalar
context.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html


Re: reduce metaoperator on an empty list

2005-05-31 Thread Damian Conway

Juerd asked:



   2+ args: interpolate specified operator
   1 arg:   return that arg
   0 args:  fail (i.e. thrown or unthrown exception depending on use fatal)
 
Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 fail too?


No. It returns empty string. You could think of Cjoin as being implemented:

sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b } , 
@list }

Just as Csum is probably implemented:

sub sum ([EMAIL PROTECTED]) { [+] 0, @list }



I dislike this, and would prefer [op] with no elements to simply return
whatever () returns: an empty list in list context, undef in scalar
context.


I'd have assumed that empty list in list context, undef in scalar
context *is* what Cfail returns when Cuse fatal isn't in effect.

Damian


Perl 6 Summary for 2005-05-24 through 2005-05-31

2005-05-31 Thread Matt Fowles
Perl 6 Summary for  2005-05-24 through  2005-05-31
All~

Welcome to another Perl 6 summary, brought to you by Aliya's new
friends, Masha Nannifer and Philippe, and my own secret running joke.
Without further ado, I bring you Perl 6 Compiler.

  Perl 6 Compiler
   method chaining
Alex Gutteridge discovered that he couldn't chain attribute access like
 $bowl.fish.eyes.say;  in Pugs. Later he provided his example in test
form (in case anyone wanted to add it). Maybe they were added to the
test suite, maybe not: Warnock applies.

http://xrl.us/f95k

   Pugs link issues on Debian Sid
BÁRTHÁZI András was having trouble making Pugs work on Debian Sid with
perl 5 support. Autrijus provided helpful pointers. I assume from his
final silence that the final pointer worked.

http://xrl.us/f95m

   Pugs.AST.* compilation
Samuel Bronson wanted to speed up the compilation of Pugs.AST.* modules
by turning off optimizations. Autrijus told him that this was a core
module that needed it speed, and optimizations would stay.

http://xrl.us/f95n

   Pugs.Types export list
Samuel Bronson added an export list to Pugs.Types. Autrijus happily
applied it and send him a commit bit.

http://xrl.us/f95o

   export withArgs from Main
Samuel Bronson added an export to Main. Samuel Bronson happily applied
it himself this time.

http://xrl.us/f95p

   out-of-date hs-plugins
Vadim was having trouble compiling Pugs with Parrot support. Autrijus
helped him fix his problem, and there was much rejoicing.

http://xrl.us/f95q

   chomp problem
Jens Rieks found a problem with chomp and submitted a test. Warnock
applies.

http://xrl.us/f95s

   Pugs makefile issue
Grégoire Péan noticed that pugs was creating a useless Pugs.exe.bat.
Autrijus asked if he would be willing to investigate a patch. He
responded that he would put it in his queue.

http://xrl.us/f95t

   loop or do
Gerd Pokorra wondered why  do { ... }  was in Pugs reasoning that 
loop { ... } while  was the correct thing. Luke Palmer explained that 
do { ... }  was part of the with or without a postfix  while .

http://xrl.us/f95u

   PxPerl 5.8.6.2 with Pugs 6.2.5 and Parrot 0.2.0
Grégoire Péan announced that the release of PxPerl 5.8.6.2 which
includes Pugs 6.2.5 and Parrot 0.2.0. This means that windows folk can
test Pugs and Parrot without having to fight with compilers.

http://xrl.us/f95v

   BUILD errors
Carl Franks was confused by that handling of a named argument to a
constructor. He asked for confirmation but none was provided. Perhaps
this poor summary save him.

http://xrl.us/f95w

   whitespace and function calls
David D Zuhn didn't know that whitespace between and function call and
its parentheses was forbidden. Carl told him that and about the  .() 
variant which allows whitespace.

http://xrl.us/f95x

   Pug's make cean issues LONG commands
Carl Franks noticed that make clean issued a command so long that it
broke his nmake. Fortunately he had a really old nmake and updating
fixed the problem.

http://xrl.us/f95y

  Parrot
   thr_windows.h with MinGW
François Perrad provided a patch fixing two compilation problems in
thr_windows.h. Warnock applies.

http://xrl.us/f95z

   Parrot Slides?
Adam Preble posted a request for slides and notes on Parrot and Perl 6
for a presentation he was working on. Many people provided links in
various languages. I usually steal from Dan's presentations when I need
something like this...

http://xrl.us/f952

   Problems with Perl 5.6.1
François Perrad had a problem building Parrot with MinGW and Perl 5.6.1.
The problem was related to windows and its binary vs text distinction.
This problem will also crop up if you ever try to seek on files in
windows. Not that I have ever lost several days debugging that problem.

http://xrl.us/f953

   ordered hash thoughts
Leo posted his thoughts on a modification to ordered hash as adding a
new element by index breaks the string hashing part of it. Dan suggested
that the ordered hash just pitch exceptions in the bad cases as it was
designed to be lightweight and fast.

http://xrl.us/f954

   subrules tests
Dino Morelli provided a patch adding tests for subrules to PGE. Warnock
applies.

http://xrl.us/f955

   python on parrot
Bloves inquired as to the state of python on parrot. The phrasing of the
question itself provided some confusion. Michal Wallace provided a link
to pirate, hoping it would help.

http://xrl.us/f956

   Resizable*Array defeats list.c
Slowly but steadily my {Fixed,Resizable}typeArray PMCs are defeating
the less consistent array implementations. Leo offered the job of
slaying list.c to any interested partied. Jerry Gay expressed interest.

http://xrl.us/f957

   

RE: reduce metaoperator on an empty list

2005-05-31 Thread Joe Gottman


 -Original Message-
 From: Damian Conway [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, May 31, 2005 11:14 PM
 To: perl6-language@perl.org
 Subject: Re: reduce metaoperator on an empty list
 
 Juerd asked:
 
 
 2+ args: interpolate specified operator
 1 arg:   return that arg
 0 args:  fail (i.e. thrown or unthrown exception depending on use
 fatal)
 
  Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 
  fail too?
 
 No. It returns empty string. You could think of Cjoin as being
 implemented:
 
  sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b } , 
 @list }
 
 Just as Csum is probably implemented:
 
  sub sum ([EMAIL PROTECTED]) { [+] 0, @list }
 

   If this were the case, then
join '~', 'a', 'b', 'c'
 would equal '~a~b~c' instead of 'a~b~c'

Joe Gottman



Re: date and time formatting

2005-05-31 Thread Sam Vilain

Rob Kinyon wrote:

What I'm trying to get at isn't that DateTime's API should be
preserved. I'm saying that the concept of DateTime should be ported.
Core or not core - it doesn't matter. When use'd (or installed), it
should override now() (and anyone else we can think of) to return an
object that DWIMs, plus provides the interface you've outlined below.


I've made a start on this.  See ext/Date in pugs.  I don't think that
your views are necessarily contrary.

The biggest reason I didn't use DateTime was that I found it awkward
for the common case; most of the time I just want to stuff in an
ISO8601 date.  I also don't like implicit normalisation to seconds
underneath the hood when I'm doing basic date calculations, and
the way that the DateTime base class is inherantly based on the
Gregorian calendar.

The Date and Duration roles are extremely minimal; see

   http://svn.openfoundry.org/pugs/ext/Date/lib/Date.pm
   http://svn.openfoundry.org/pugs/ext/Date/lib/Duration.pm

The major API is described at:

   http://svn.openfoundry.org/pugs/ext/Date/lib/Date/Gregorian.pod

This module is supposed to be somewhere between DateTime and
Class::Date, with built-in ISO-8601 support (as it's the standard ;)).

With a bit of luck, all Date implementation can share this `Date'
Role, and Gregorian calendar modules share the `Date::Gregorian' Role,
so that the multitude of implementations that crop up will be mutually
exchangable, and the simple case fast, efficient and useful.

Sam.


Re: returns and context

2005-05-31 Thread Sam Vilain

Rod Adams wrote:

How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}

I suspect a typed junction would look like : Junction of Int|Str.


Not quite.  AIUI that means a Junction of which the members are Int or Str.

This is how I've been writing it:

  sub foo() returns Scalar|List {
  return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
  }

I think the default return type of unlabeled subs would be:

  returns Void|Scalar|List

but of course $?SELF =:= none(@Larry) ;)

Sam.


Re: Perl 6 Summary... p6rules

2005-05-31 Thread Dino Morelli
Thank you for the summary, Matt

I have a correction, though:

   subrules tests
Dino Morelli provided a patch adding tests for subrules to PGE. Warnock
applies.

http://xrl.us/f955

This and my other two patches to p6rules tests (RT #35950, 35971, 35994)
have not yet been applied.


-Dino

-- 
 .~.Dino Morelli
 /V\email: [EMAIL PROTECTED]
/( )\   weblog: http://categorically.net/d/blog/
^^-^^   preferred distro: Debian GNU/Linux  http://www.debian.org


Re: returns and context

2005-05-31 Thread Rod Adams

Sam Vilain wrote:


Rod Adams wrote:


How do I specify the signature of a context-sensitive function?
sub foo() returns (what?) {
return want ~~ Scalar ?? cheap_integer_result :: List_of_Sheep;
}


I suspect a typed junction would look like : Junction of Int|Str.



Not quite.  AIUI that means a Junction of which the members are Int or 
Str.



Yep, which is how I interpreted the question inside the parens inside 
the paragraph, completely ignoring the question in the code block, since 
Gaal answered it himself.



-- Rod Adams



Re: reduce metaoperator on an empty list

2005-05-31 Thread Damian Conway

Joe Gottman pointed out:


No. It returns empty string. You could think of Cjoin as being
implemented:

sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b } , 
@list }



   If this were the case, then
join '~', 'a', 'b', 'c'
 would equal '~a~b~c' instead of 'a~b~c'


Good point. Thanks. Make that:

sub join (Str $sep, [EMAIL PROTECTED]) {
reduce { $^a ~ $sep ~ $^b } @list || 
}

Presuming (of course) that my earlier plea that || should preserve context 
across both operands is granted. ;-)


Damian


Re: Perl 6 Summary... p6rules

2005-05-31 Thread Patrick R. Michaud
On Tue, May 31, 2005 at 11:58:12PM -0400, Dino Morelli wrote:
 Thank you for the summary, Matt
 
 I have a correction, though:
 
subrules tests
 Dino Morelli provided a patch adding tests for subrules to PGE. Warnock
 applies.
 
 http://xrl.us/f955
 
 This and my other two patches to p6rules tests (RT #35950, 35971, 35994)
 have not yet been applied.

My apologies for taking so long to apply these patches; I've been
out of town for much of the past week and barely keeping up with
email.  Also, since 35971 is a bit of a big change I wanted to review
it a bit -- it'll happen within the next twelve hours.

I *really* appreciate the tests -- they've been very helpful and useful.

Pm