Hi,
On Mon, Apr 13, 2009 at 11:56 PM, Patrick R. Michaud wrote:
> As some of you are aware, this week is the Nordic Perl Workshop [1],
> and in the days immediately following the workshop we will have
> the Oslo Perl 6 Hackathon [2]. During the first day of the hackathon
> Gabor Szabo will be do
As some of you are aware, this week is the Nordic Perl Workshop [1],
and in the days immediately following the workshop we will have
the Oslo Perl 6 Hackathon [2]. During the first day of the hackathon
Gabor Szabo will be doing a "Hands-on Perl 6 training" course [3],
the other two days will be fo
On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
: * A closure form of `but` is desugared into a `do given` block that
: eliminates the need of returning $_ explicitly. So those two forms
: are equivalent:
:
: my $foo = Cls.new but {
: .attr = 1;
: };
:
: my
Larry wrote:
> I would like to point out that for mere mortals, *any* MMD is already too
> complex to be predictable.
This is the relevant observation here.
This particular mortal's experience is that more than four variants, involving
parameters from more than two hierarchies makes it nearly
On Fri, Jul 08, 2005 at 19:19:34 -0500, Rod Adams wrote:
> Then all we need is a DWIMish sort function.
Think of parameter list shape (slurpiness, arity) as a mold you can
fit stuff into.
Then it becomes a simple matter of reducing the match list to your
compatible subs.
Then see
http://svn.ope
David Storrs wrote:
On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote:
Rod Adams wrote:
multi method foo#bar (Num x) {...}
multi method foo#fiz (String x) {...}
$y = 42;
$obj.foo#fiz($y); # even though $y looks like a Num
$obj.foo($z); # let MMD sort it out.
Instead of ch
On Fri, Jul 08, 2005 at 16:45:09 -0400, David Storrs wrote:
> Could we break them out into separate threads so that our poor summarizer
> doesn't go
> bonkers?
See? That's what specialization/particulation is good for. Thanks
for strengthening my point!
--
() Yuval Kogman <[EMAIL PROTECTE
First off, it seems like there are at least 3 topics being discussed
under the "Re: Hackathon notes" subject line. Could we break them
out into separate threads so that our poor summarizer doesn't go
bonkers?
On Jul 8, 2005, at 4:25 PM, Dave Whipp wrote:
Rod Adams wro
On Fri, Jul 08, 2005 at 13:25:14 -0700, Dave Whipp wrote:
> Rod Adams wrote:
>
> > multi method foo#bar (Num x) {...}
> > multi method foo#fiz (String x) {...}
> > $y = 42;
> > $obj.foo#fiz($y); # even though $y looks like a Num
> > $obj.foo($z); # let MMD sort it out.
>
> Having ad
On Fri, Jul 08, 2005 at 15:19:13 -0500, Rod Adams wrote:
> $obj.foo($y);
Intuitively I'd say $obj.foo(String<$y>) or something like that...
$obj.foo reads like MMD on the return value to me, and in
that case I'd prefer
String<$obj.foo($y)>
or maybe a type is a part of the context? T
Rod Adams wrote:
multi method foo#bar (Num x) {...}
multi method foo#fiz (String x) {...}
$y = 42;
$obj.foo#fiz($y); # even though $y looks like a Num
$obj.foo($z); # let MMD sort it out.
Having additional tags might also give us something to hang priority
traits off: "fo
Yuval Kogman wrote:
Rob Kinyon had a strong argument (in #perl6) that anything that
depends on load order is bound to make someone's head hurt.
He has a point.
Especially if one in working in something like mod_perl, and the order
various modules were actually loaded in can vary greatly f
On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
: * Non-source-filter-ish macros work on the PIL(AST) level, not on parse tree
: level. The AST should preserve enough information to derive the original
: parse tree and source code back, for the compiler to use.
It's not clear t
On Fri, Jul 08, 2005 at 11:57:04 -0700, Larry Wall wrote:
> On Fri, Jul 08, 2005 at 02:14:27PM +, Luke Palmer wrote:
> : Anyway, I think that once we start diving inside expressions to
> : measure their specificity, we've gotten too complex to be predictable.
>
> I would like to point out that
On Fri, Jul 08, 2005 at 02:14:27PM +, Luke Palmer wrote:
: Anyway, I think that once we start diving inside expressions to
: measure their specificity, we've gotten too complex to be predictable.
I would like to point out that for mere mortals, *any* MMD is already too
complex to be predictabl
On Thu, Jul 07, 2005 at 06:37:58PM +0800, Autrijus Tang wrote:
> During the Pugs Hackathon at YAPC::NA 2005, I managed to get various
> unspecced tests and features reviewed by Larry, and posted them in my
> journal. The original notes is attached; I'd be very grateful if you or
> other p6l people
On Fri, Jul 08, 2005 at 17:23:26 +0200, "TSa (Thomas Sandla)" wrote:
> http://www.cs.washington.edu/research/projects/cecil/www/Papers/predicate-classes.html
Regardless of MMD, I think this is an interesting concept on it's
own.
classe Moosish does pred:where {
... # a wh
On Fri, Jul 08, 2005 at 17:23:26 +0200, "TSa (Thomas Sandla)" wrote:
> Luke Palmer wrote:
> >Anyway, I think that once we start diving inside expressions to
> >measure their specificity, we've gotten too complex to be predictable.
>
> Well, we don't have where clauses, but where closures! The form
On Fri, Jul 08, 2005 at 14:14:27 +, Luke Palmer wrote:
> I suppose I was mostly commenting on the junctions part. I'm
> proposing that All Junctions Are Created Equal. That is, there is no
> specificity measuring on junctions. I also didn't really understand
> your right-angle-tree-ratio mea
Luke Palmer wrote:
Anyway, I think that once we start diving inside expressions to
measure their specificity, we've gotten too complex to be predictable.
Well, we don't have where clauses, but where closures! The former
should be a declarative sublanguge like regexps. They are evaluated
at comp
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 Fri, Jul 08, 2005 at 14:26:20 +0300, Yuval Kogman wrote:
http://svn.openfoundry.org/pugs/docs/notes/mmd_match_order.txt now
contains a proposal fofr some clear semantics on parameter coercion
and MMD, if anyone cares.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ ku
On Fri, Jul 08, 2005 at 07:09:31 -0600, Luke Palmer wrote:
> > the one defined LATER in the file wins
That should read
"the one defined in the LATER file wins"
=)
> If we're going to make a choice for the user (something we usually
> avoid), we might as well go with the one
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:
> 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
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
Values may be compiled into where clauses which are eventually just
a big given/when behind the scenes, but the order in which they are
checked must b
On Fri, Jul 08, 2005 at 08:50:49 +, Luke Palmer wrote:
> Not unless you want to write the Halting engine that determines that 3
> is in fact more specific that 2..10. It's based on definition order,
> so that if you have dependencies in you condition (which you
> oughtn't), you'd better defin
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
Autrijus Tang wrote:
* deref is now 0-level; $x = 3; $y = \$x; $y++. # now an exception
That is because &postfix<++>:(Ref) doesn't exist, right?
* sub foo (?$x, ?$Inf) {}
my $y = (x => 3); foo($y); # binds $x
my $z = (+Inf => 3); foo($z); # binds $Inf
Isn't the lhs of => autoquoted? Wh
During the Pugs Hackathon at YAPC::NA 2005, I managed to get various
unspecced tests and features reviewed by Larry, and posted them in my
journal. The original notes is attached; I'd be very grateful if you or
other p6l people can find tuits to work them back into the relevant
Synopses. :-)
Than
30 matches
Mail list logo
