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 wrote:
multi m
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 Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
None
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
> And what will be the default syntax to call
> a method on self? If everyone has completly other
> preferences about this, for example this horrible ./method()
> syntax, which completly wont fit into the language,
What a way to win f
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
Larry Wall <[EMAIL PROTECTED]> writes:
> On Wed, Jul 06, 2005 at 11:47:47PM +0100, Piers Cawley wrote:
> : Or you could use a global, but globals are bad...
>
> Globals are bad only if you use them to hold non-global values.
> In this case it seems as though you're just going through contortions
>
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 Thu, Jul 07, 2005 at 08:12:17PM -0700, Larry Wall wrote:
> The basic problem is that I always hated looking at C++ and not knowing
> whether I was looking at a function or a method, so I'm not going to
> make standard Perl work like that. On the other hand, there's always
>
> use self "";
I use a (Perl) password server for this.
Passwords are stored encrypted in a configuration file.
Clients authenticate with the server, and receive a requested
password (encrypted) across the network, if the client is
entitled.
The user authentication is rudimentary, but it works.
SSH certificate
I don't mind if you implement this ".dbi" feature though, I just want it
to be invisible :) i.e. don't check this file, if I explicitly supply
username and password (this is obvious, right?) and show some warnings
if don't. Say, make a connect parameter "use_dot_dbi", which is zero by
default.
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
31 matches
Mail list logo
