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? Why
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 foo (3) { ...
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 define
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 ;
to
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
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
to
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 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 that
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
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?
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
/\ kung
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
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
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 former
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
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 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
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 for
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
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
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:
On Fri, Jul 08, 2005 at 15:19:13 -0500, Rod Adams wrote:
$obj.fooString($y);
Intuitively I'd say $obj.foo(String$y) or something like that...
$obj.fooString 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
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 additional tags
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
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 PROTECTED]
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
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
28 matches
Mail list logo
