On 7/7/05, wolverian <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 07, 2005 at 08:18:40PM +0300, wolverian wrote:
> > I'm a pretty high level guy, so I don't know about the performance
> > implications of that. Maybe we want to keep seek() low level, anyway.
>
> Sorry about replying to myself, but I wa
On 7/8/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
> > * Constrained types in MMD position, as well as value-based MMDs, are _not_
> > resolved in the type-distance phase, but compile into a huge given/when
> > loop that accepts the first alternative. So this:
> >
> > multi sub f
On 7/8/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I have a draft of a proposition for what I think is proper MMD
> dispatching order:
>
> http://svn.openfoundry.org/pugs/docs/mmd_match_order.txt
He meant:
http://svn.openfoundry.org/pugs/docs/notes/mmd_match_order.txt
Luke
On 7/8/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I have a draft of a proposition for what I think is proper MMD
> dispatching order:
>
> http://svn.openfoundry.org/pugs/docs/mmd_match_order.txt
--
> Order of definition tie breaking:
>
> Two signatures defined in the same file:
>
On 7/8/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > If we're going to reorder things for the user,
> > it does need to happen in a predictable way, even if it's not correct
> > 100% of the time. I find your tree to be pretty complex (that could
> > be because I don't understand the reasoning fo
On 7/11/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> my $x = 42;
> my $y = $x;
> $y++;
> say $x; # Still 42, of course
>
>
> class Foo {
> has $.data;
> method incr () { $.data++ }
>
> # Please fill in appropriate magic here
> }
I think it's just `
On 7/11/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> class Foo {
> has $.data;
> method incr () { $.data++ }
>
> # Please fill in appropriate magic here
> }
>
> my Foo $x .= new(:data(42));
> my Foo $y = $x;
> $y.incr();
> say $x.data;# Should still be 42
> sa
Thanks for your very detailed explanation of your views on the Pure
MMD scheme, Damian. I finally understand why you're opposed to it. I
could never really buy your previous argument: "Manhattan distance is
better".
Damian writes:
> Similarly, since the number of potential variants is the Cartes
On 16 Jul 2005 12:22:31 -, David Formosa (aka ? the Platypus)
<[EMAIL PROTECTED]> wrote:
> On Sat, 16 Jul 2005 12:14:24 +0800, Autrijus Tang
> <[EMAIL PROTECTED]> wrote:
>
> [...]
>
> > On Sat, Jul 16, 2005 at 12:24:21AM +0300, Yuval Kogman wrote:
> >> > There is a new generic comparison oper
On 7/16/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> I'm going to have some coffee mugs thrown at me for saying this, but perhaps:
>
> Generic StringNumericIdentity
>+---+---++
On 7/17/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I have another view.
>
> The Num role and the Str role both consume the Eq role. When your
> class tries to both be a Num and a Str, == conflicts.
>
> I have two scenarios:
>
> class Moose does Num does Str { ... }
>
> # Moos
On 7/17/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> "You keep using that word. I do not think
> it means what you think it means"
> -- Inigo Montoya
Quite. I abused Liskov's name greatly here. Sorry about that.
Anyway, my argument is founded on anothe
On 7/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> # Perl 5
> my %hash = (a => 1, b => 2, a => 3);
> warn $hash{a}; # 3
>
> But I vaguely remember having seen...:
>
> # Perl 6
> my %hash = (a => 1, b => 2, a => 3);
> say %hash;# 1
>
> Can somebody c
On 7/26/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> are the following assumptions correct?
>
> sub foo ([EMAIL PROTECTED]) { @args[0] }
>
> say ~foo("a", "b", "c"); # "a"
Yep.
> my @array = ;
> say ~foo(@array);# "a b c d" (or "a"?)
> say ~foo(@array, "
On 7/26/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
> Piers Cawley wrote:
> > I would like to be able to iterate over all the
> > objects in the live set.
>
> My Idea actually is to embedd that into the namespace syntax.
> The idea is that of looking up non-negativ integer literals
> wit
http://repetae.net/john/recent/out/supertyping.html
This was a passing proposal to allow supertype declarations in
Haskell. I'm referencing it here because it's something that I've had
in the back of my mind for a while for Perl 6. I'm glad somebody else
has thought of it.
Something that is wor
On 7/19/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> > And now maybe you see why I am so disgusted by this metric. You see,
> > I'm thinking of a class simply as the set of all of its possible
> > instances.
>
> There's your problem. Classes are not isomorphic to sets of instances and
> derived
I just realized something that may be very important to my side of the
story. It appears that I was skimming over your example when I should
have been playing closer attention:
On 7/18/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Consider the following classes:
>
>class A {..
On 7/27/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > role Complex
> > does Object
> > contains Num
> > {...}
>
> I've probably misunderstood you, but...:
>
> role Complex does Object {...
On 7/27/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 27, 2005 at 11:00:20AM +0000, Luke Palmer wrote:
>> Everything that is a Num is a Complex right?
>
> Not according to Liskov. Num is behaving more like a constrained
> subtype of Complex as soon as you admit
On 7/29/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> In S06's Currying section, there are some strange looking examples:
>
> &textfrom := &substr.assuming(:str($text) :len(Inf));
>
> &textfrom := &substr.assuming:str($text):len(Inf);
>
> &woof ::= &bark:(Dog).assuming :pitch;
>
>
On 8/1/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> In general, (@foo, @bar) returns a new list with the element joined,
> i.e. "@foo.concat(@bar)". If you want to create a list with two sublists,
> you've to use ([EMAIL PROTECTED], [EMAIL PROTECTED]) or ([EMAIL PROTECTED],
> [EMAIL PROTECTE
On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote:
> On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
> > So how *do* I pass an unflattened array to a function with a slurpy
> > parameter?
>
> Good question. I would have thought that one of the major gains from
> turning arrays and hashes into refe
On 8/3/05, Nigel Hamilton <[EMAIL PROTECTED]> wrote:
> Instead of passing the "buck" from object to object via parameter lists
> and type inference (traversing OO hierarchies etc) maybe we could ..
>
> Model the flow of control through a program as a simple linear queue of
> topic changes. A centr
I vaguely recall that we went over this already, but I forgot the
conclusion if we did.
In Damian and Larry's talk here at OSCON, I saw the example:
if foo() -> $foo {
# use $foo
}
How can that possibly work? If a bare closure { } is equivalent to ->
?$_ is rw { }, then the norm
On 8/4/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> my $pair = (a => 1);
> say $pair[0]; # a?
> say $pair[1]; # 1?
>
> I've found this in the Pugs testsuite -- is it legal?
Nope. That's:
say $pair.key;
say $pair.value;
Also:
say $pair; # 1
say $pa
On 8/4/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> (found in the Pugs testsuite.)
>
> my $undef = undef;
> say $undef.chars? # 0? undef? die?
> say chars $undef; # 0? undef? die?
>
> I'd opt for "undef.chars" to be an error ("no such method") and "chars
> undef" to
I'm writing a new module that optimizes sets of conditions into
decision trees. Initially I allowed the user to specify conditions as
strings, and if that condition began with a "!", it would be the
inverse of the condition without the "!".
But then I thought, "the user will more than likely have
On 8/5/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> my $str = "Hello";
> $str.ref = Int; # allowed?
> $str.meta = &some_sub.meta; # allowed?
I hardly think those work. Both of those require a change of
implementation, which we can't do generically. So
On 8/5/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> ~Str;# ""? "Str"?
"Str"
> ~::Str; # ""? "Str"?
I don't know how :: works anymore. I'll avoid these.
> ~Str.meta; # ""? (fill in please)?
"Class"
>
On 8/9/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> So why not just use "describes"? Then maybe Object.isa(Foo) delegates
> to $obj.meta.describes(Foo).
Hmm. We have a similar problem with the new class-set notation.
These two things:
$a.does(Foo);
Bar.does(Foo);
Mean two different thi
On 8/10/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> But it's an toplevel optimization, which is not applicable to
> module authors. So I'd very much welcome a lexical pragma that
> forces static binding of subroutine calls.
Yeah, but the whole point of not allowing that is so that you can
over
On 8/10/05, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Luke Palmer wrote:
> > On 8/9/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> >
> >>So why not just use "describes"? Then maybe Object.isa(Foo) delegates
> >>to $obj.meta.describes(F
On 8/10/05, TSa <[EMAIL PROTECTED]> wrote:
> Here is an example of a 2D distance method
>
>role Point
>{
> has Num $.x;
> has Num $.y;
>}
>method distance( Point $a, Point $b --> Num )
>{
> return sqrt( ($a.x - $b.x)**2 - ($a.y - $b.y)**2);
>}
>
> Now comes
On 8/11/05, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Autrijus Tang wrote:
> > On Thu, Aug 11, 2005 at 08:02:00PM +1000, Stuart Cook wrote:
> >>my Foo ::x;
> >>a) ::x (<=) ::Foo (i.e. any type assigned to x must be covariant wrt. Foo)
> >>b) ::x is an object of type Foo, where Foo.does(Class
On 8/10/05, Sam Vilain <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-10 at 21:00 -0400, Joe Gottman wrote:
> >Will there be an operator for symmetric difference? I nominate (^).
>
> That makes sense, although bear in mind that the existing Set module for
> Perl 6, and the Set::Scalar and Set::
ce it's not a container.
Luke
> - Flavio S. Glock
>
> 2005/8/10, Dave Whipp <[EMAIL PROTECTED]>:
> > Luke Palmer wrote:
> >
> > > A new development in perl 6 land that will make some folks very happy.
> > > There is now a Set role. Among its operations are (including
> > > parentheses):
>
On 8/10/05, Dave Rolsky <[EMAIL PROTECTED]> wrote:
> [changing the subject line for the benefit of the summarizer ...]
>
> On Wed, 10 Aug 2005, Larry Wall wrote:
>
> > And now some people will begin to wonder how ugly set values will look.
> > We should also tell them that lists (and possibly any
On 8/16/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 1_234; # surely 1234
> 1e23; # surely 1 * 10**23
>
> 1._5; # call of method "_5" on 1?
> 1._foo; # call of method "_foo" on 1?
>
> 1.e5; # 1.0 * 10**5?
> 1.efoo; # call of me
On 8/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> You could still reason about it if you can determine what the initial
> value is going to be. But certainly that's not a guarantee, which
> is one of the reasons we're now calling this write/bind-once behavior
> "readonly" and moving true constan
On 8/17/05, Dave Rolsky <[EMAIL PROTECTED]> wrote:
> I'm going to go over the various features in P::V and see if there are
> equivalents in Perl6, and bring up any questions I have. I think this
> will be interesting for folks still new to P6 (like myself) and existing
> P::V users (I think there
Two years ago or so, I became very happy to learn that the left side
of binding works just like a routine signature. So what if binding
*were* just a routine signature. That is, could we make this:
sub foo () {
say "hello";
my $x := bar();
say "goodbye $x";
}
Equ
We've seen many problems come up with the current special treatment of
pairs. Here's what I can think of:
* Pairs are restricted to a particular position in the argument list, which
leads to confusion (why isn't this being passed named?) and poor
end-weight in something like this:
f
What is the resulting data structure in each of the following:
-<< [1, 2]
-<< [[1,2], [3,4]]
-<< [[1,2], 3]
[[1,2], 3] >>+<< [[4,5], 6]
[1, 2, [3]] >>+<< [[4,5], 6]
Luke
Here is an update to Synopsis 3 incorporating recent additions. If
any of this is wrong or disagreeable, this is the time to say so.
Luke
S03.pod.diff
Description: Binary data
Output?
sub foo (+$a, *%overflow) {
say "%overflow{}";
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b => 2 }); # b2
foo(:a(1), :overflow{ b => 2 }, :c(3)); # ???
Luke
On 8/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> I think the simplest thing is to say that you can't bind to the name
> of the slurpy hash. You give a name to it so that you can refer to it
> inside, but that name is not visible to binding.
Fixed in https://svn.perl.org/perl6/doc. Thanks.
Lu
On 8/22/05, Yiyi Hu <[EMAIL PROTECTED]> wrote:
> my( $s, $t ); $s = "value t is $t"; $t = "xyz"; print $s;
I have an answer for you that is much more detailed than what you want
to hear. The short answer is "yes".
This is possible to implement, provided you appropriately declare $t.
It all depe
On 8/23/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> (asking because a test testing for the converse was just checked in to
> the Pugs repository [1])
>
> sub foo ($n, *%rest) {...}
>
> foo 13;
> # $n receives 13, of course, %rest is ()
>
> foo 13, foo => "bar";
>
On 8/24/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > Plus I still think it's a really bad idea to allow intermixing of
> > positionals and named. We could allow named at the beginning or end
> > but still keep a constraint that all positionals must occur together
> > in one z
On 8/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus)
> wrote:
> > On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> >
> > [...]
> >
> > > perl6 creates a new instance of the perl compiler (presu
While nothingmuch and I are gutting junctions and trying to find the
right balance of useful/dangerous, I'm going to propose a new way to
do autothreading that doesn't use junctions at all.
First, let me show you why I think junctions aren't good enough:
I can't extract the information that the t
Let me just clarify something that my intuition led me to believe:
sub foo(&infix:<+>) { 1 + 2 }
sub bar($a, $b) { say "$a,$b" }
foo(&bar); # "1,2"
That is, operator names can be lexically bound just like any other
name. Also, this doesn't have any affect on implicit coercions, e
On 8/31/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 31, 2005 at 04:56:25 -0600, Luke Palmer wrote:
>
> > (That is, lexically binding &prefix:<+> does not change things in
> > numeric context; only when there's actually a + in front of
On 9/1/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 31, 2005 at 13:43:57 -0600, Luke Palmer wrote:
> > Uh yeah, I think that's what I was saying. To clarify:
> >
> > sub foo (&prefix:<+>) { 1 == 2 }# 1 and 2 in numeric cont
On 9/1/05, Juerd <[EMAIL PROTECTED]> wrote:
> Ingo Blechschmidt skribis 2005-09-01 20:29 (+0200):
> > for ($arrayref,) {...}; # loop body executed only one time
>
> Yes: scalar in list context.
>
> > for ($arrayref) {...}; # loop body executed one or three times?
>
> Same thing: scala
On 9/2/05, Juerd <[EMAIL PROTECTED]> wrote:
> Luke Palmer skribis 2005-09-01 23:43 (+):
> > I would probably say that scalars never automatically dereference.
> > It's lists and hashes that automatically dereference/enreference.
>
> arrays
Yes, arrays, righ
On 9/3/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 03/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > A multi sub is a collection of variants, so it doesn't have arity,
> > each variant has arity.
> >
> > I'd say it 'fail's.
>
> But if the reason you're calling `&foo.arity` is to answer the
Here's a good Perl 6 final exam question:
Spot the mistake (hint: it's not in the math):
module Complex;
sub i() is export {
Complex.new(0,1)
}
multi sub infix:<+> (Complex $left, Complex $right) is export {
Complex.new($left.real + $right.real, $left.imag + $rig
On 9/4/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I always saw scoping of multis as something that applies to the
> variants...
>
> multi sub foo {
>
> }
>
> {
> my multi sub foo {
>
> }
>
>
On 9/5/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> quick questions:
>
> constant pi = 3; # works
> # Is &pi package- or lexically-scoped?
>
> our constant pi = 3; # legal?
>
> my constant pi = 3; # legal?
Yep. Bare constant is packa
On 9/5/05, Juerd <[EMAIL PROTECTED]> wrote:
> Thomas Sandlass skribis 2005-09-05 14:38 (+0200):
> >b) if this is true, ?? evaluates its rhs such that it
> > can't be undef
>
> But
>
> $foo ?? undef // 1
>
> then is a problem.
Yeah. Hmm, but I kinda like the look of ?? //, and I d
On 9/6/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > Yeah. Hmm, but I kinda like the look of ?? //, and I don't like the
> > overloading of :: in that way anymore. So it's possible just to add
> > a ternary ?? // in addition to, and unrelated to (from the parser's
> > per
On 9/6/05, Thomas Sandlass <[EMAIL PROTECTED]> wrote:
> Right. To make :: indicate type or meta was my primary concern.
Okay, now why don't you tell us about this new binary :: you're proposing.
Luke
On 9/3/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> H. The arity of a given multi might be 3 or 4 or 5.
>
> If *only* there were a way to return a single value that was simultaneously
> any of 3 or 4 or 5.
>
> Oh, wait a minute...
Well, we'd better document that pretty damn well then, and
On 9/7/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > In that last case though, this is not equivalent to the above:
> >
> > given &code.arity {
> > when 2 { code(1,2) }
> > when 1 { code(1) }
> > }
> >
> > That may be a little... surprising. Still,
On 9/7/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Here's a Real Live Perl 6 module I wrote recently. I've omitted a few
> magic portions of the code for clarity.
Thanks for real live perl 6 code. It's always nice to have real examples.
However, I'm arguing for logical stability w
On 9/8/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > Okay, fair enough. The reason that I thought it was surprising is
> > because 1 and 2 are usually orthogonal patterns.
>
> It depends what they're doing. Matched against a regex like /[12]/ they're
> not orthogonal either.
On 9/8/05, Benjamin Smith <[EMAIL PROTECTED]> wrote:
> Pugs currently implements &infix: as an ugly version of the
> &infix: operator.
>
> Are these in the spec?
No they are not. Destroy!
Luke
I think we should generalize the hyper stuff a little bit more. I
want hyper operators serve as "fmap", or "functor map", rather than
just list. This is a popular concept, and a pretty obvious
generalization.
A functor is any object $x on which you can do "fmap" such that it
satisfies these laws
On 9/11/05, Stevan Little <[EMAIL PROTECTED]> wrote:
> Hello all.
>
> I have some questions about how Roles will behave in certain
> instances, and when/where/what $?ROLE should be bound too.
>
> 1) Given this example, where 'bar' is a method stub (no implementation)
>
> role Foo {
> method
On 9/12/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> Hi,
Hi. These are superficial thoughts, before I've had time to really
think about the Big Picture.
> 2. each block of code has a cryptographic digest, which is the hash
> of it's body with the digests of all the functions it cal
On 9/14/05, Juerd <[EMAIL PROTECTED]> wrote:
> Instead, if you don't want something to coerce, be explicit:
> $foo.does(Blah) or fail;, or even: $foo.isa(Blah) or fail;.)
We've been thinking of changing .isa to something longer, or a method
on .meta, because it's a notion that is often misused. U
Okay, due to some discussion on #perl6, I'll assume that the reason my
fmap proposal was Warnocked is because a fair number of people didn't
understand it. Also, for the people who did understand, this message
includes a complete proposal for the workings of Junctions that will
fluster Damian agai
On 9/19/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 19/09/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Part 1: fmap
> >
> > I have a plan for the $x »+« $y form (and also foo(»$x«, »$y«, »$z«)),
> > but I don't want to go into that right now. It b
On 9/19/05, Luke Palmer <[EMAIL PROTECTED]> wrote
> Well, I've written up the details in a 40 line Haskell program to make
> sure it worked. I think I deleted the program, though.
Nope. Here it is. And it was 22 lines. :-)
http://svn.luqui.org/svn/misc/luke/work/code/haskell/hyper.hs
Luke
On 9/22/05, Carl Mäsak <[EMAIL PROTECTED]> wrote:
> FWIW, to me it looks fairly intuitive. undef here means "don't alias
> the element, just throw it away"... gaal joked about using _ instead
> of undef. :)
Joked? Every other language that has pattern matching signatures that
I know of (that is,
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I propose a new model - each exception has a continuation that
> allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of "use fatal", it makes a lot more sense.
Something comes to mind:
On 9/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> We can do better than equivalence testing for colors. Instead, try to
> match. Surely a *smart* match operator really is smart?
>
> $color ~~ '#FF00FF'
>==
> $color ~~ 'magenta'
>==
> $color ~~ [ 255, 0, 255 ]
Hmm.
On 9/29/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
>for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
>}
This is an interesting idea. Perhaps "for" (and "map") shift the
minimum arity of the block from the given list and bind the maximum
a
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> >>This is an interesting idea. Perhaps "for" (and "map") shift the
> >>minimum arity of the block from the given list and bind the maximum
> >>arity. Of c
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> >
> >for (1, 2) -> ?$prev, $cur, ?$next {
> > say "$prev -> $cur" if $prev;
> > say $cur;
> > say "$cur -> $next" if $next;
> > say "next";
> >}
> >
> [...]
>
> I assume so because it's the only execution path th
On 9/30/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
Thanks. I missed that one.
However, I think your point is pretty much the sam
On 10/1/05, John Macdonald <[EMAIL PROTECTED]> wrote:
> I forget what the final choice was for syntax for the reduce
> operator (it was probably even a different name from reduce -
> that's the APL name), but it would be given a list and an
> operator and run as:
>
> my $running = op.identity;
On 10/1/05, David Storrs <[EMAIL PROTECTED]> wrote:
> All in all, I think that might just be the end of the tunnel up
> ahead. Go us for getting here, and loud applause to @Larry for
> guiding us so well!
Applause for p6l for hashing out the issues that we didn't think of.
I recently wrote a "Pe
On 10/4/05, Juerd <[EMAIL PROTECTED]> wrote:
> What should zip do given 1..3 and 1..6?
>
> (a) 1 1 2 2 3 3 4 5 6
> (b) 1 1 2 2 3 3 undef 4 undef 5 undef 6
> (c) 1 1 2 2 3 3
> (d) fail
>
> I'd want c, mostly because of code like
>
> for @foo Y 0... -> $foo, $i { ... }
>
> Pugs currently does b.
On 10/4/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> If that ends up being common, we could create a syntax for it, like
> postfix:<...>:
>
> @array... # same as (@array, undef xx Inf)
No, no, that's a bad idea, because:
@array...# same as @arr
On 10/4/05, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> Playing with pugs, I ran into this corner case:
>
> sub f($x) { say $x; }
> f {1}.(); # ok, outputs 1
>
> sub f([EMAIL PROTECTED]) { say @_; }
> f {1}.(); # outputs block, tries to call a method from the return of say,
> dies
>
> Whitespace
On 10/5/05, TSa <[EMAIL PROTECTED]> wrote:
> IIRC, this puts f into the named unary precedence level
> which is below method postfix.
We're trying to stop using the words "below" and "above" for
precedence. Use "looser" and "tighter" instead, as there is not
ambiguity with those.
>(f ({1}.()
On 10/5/05, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> However:
> f:{1}.()
>
> still parses as
>
> (&f(:{1})).()
>
> as the "adverbial block" form takes precedence. Is that also wrong?
No, that seems right to me, much in the same way that:
$x.{1}.{2}
Binds to the left.
Luke
On 10/5/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > > Whow, how does a higher level exception catcher *in general* know
> > > what type it should return and how to construct it? The
On 10/5/05, Ovid <[EMAIL PROTECTED]> wrote:
> sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
> ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> So I now propose that C works like this:
>
> C interleaves elements from each of its arguments until
> any argument is (a) exhausted of elements I (b) doesn't have
> a C property.
>
> Once C stops zipping, if any
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > I'm just wondering why you feel that we need to be so careful.
>
> Because I can think of at least three reasonable and useful default behaviours
> for zipping lists of differing lengths:
>
> # Minimal (stop at first exhau
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
>
> is something you will probably not see very often, it's still legal
> Perl, even though it looks asymmetric. This too makes finding the
> solution in arguments a non-solution.
Don't be silly. Th
On 10/6/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
> sub foo( $a, ?$b = rand but :is_default )
> {
> ...
> bar($a,$b);
> }
>
> sub bar( $a, ?$b = rand but :is_default )
> {
>warn "defaulting \$b = $b" if $b.is_default;
>...
> }
>
>
> It would be unfortunate if the "is_default" proper
On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> when i can't open a file and $! tells me why i couldn't open, i
> can resume with an alternative handle that is supposed to be the
> same
>
> when I can't reach a host I ask a user if they want to wait any
>
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> Luke Palmer skribis 2005-10-06 14:23 (-0600):
> > my role is_default {} # empty
> > sub foo($a, ?$b = 0 but is_default) {...}
>
> Would this work too?
>
> 0 but role {}
Most certainly, but you w
Autrijus convinced me that we have to really nail down the semantics
of type annotation without "use static". Let's first nail down what
I meant by "semantics" in that sentence. Basically, when do various
things get checked? Run time or compile time (not coercion; I have a
proposal for that com
On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:\
> If I added a multisub for Array assignment so that assigning an integer
> value set the length of the array, would 97 be compatible with Array?
You're not allowed to overload assignment.
But you are allowed to overload coersion. Essentially, ev
1 - 100 of 1064 matches
Mail list logo