On 10/28/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> One thing I would like to be able to do is this:
>
>@baz = cross([1,2],[3,4]); # yields ([1,3],[1,4],[2,3],[2,4])
>
> And alternately, this:
>
>for cross([1,2],[3,4]) -> $foo,$bar { ... } # loop has 4 iterations
I already proposed thi
On Thursday 27 October 2005 09:37 pm, Joshua Hoblitt wrote:
> On Thu, Oct 27, 2005 at 11:22:40PM +0200, Leopold Toetsch wrote:
> > On Oct 27, 2005, at 22:31, Nick Glencross wrote:
> > >There are a few cases of -1 being assigned to unsigneds. Anyone know
> > >if that's deliberate?
> >
> > Yup. Some
On Thu, 27 Oct 2005, Darren Duncan wrote:
Not sure if this matter was resolved on a previous discussion, but here goes
Definitely is has been discussed at least once, that I know, for I asked
this myself, but from a somewhat more mathematical pov. You can find a
copy of my mail here:
http:
On Tue, Oct 25, 2005 at 04:56:57PM +0200, Leopold Toetsch wrote:
> >How do I get an anonymous coroutine into a register?
>
> As these 2 .subs are generated in one bunch and compiled ...
>
> >.sub _pge_rule
> >.param pmc mob
>
> ... drop the var decl:
>
> >.local pmc corou
>
Hi,
This patch fixes 'make clean' for me.
Stig
--- config/gen/makefiles/languages.in (revision 9610)
+++ config/gen/makefiles/languages.in (patch - level 1)
@@ -4,7 +4,9 @@
${make_set_make}
PERL = ${perl}
MAKE_C= ${make_c}
+RM_F = ${rm_f}
+
# add new languages here
# remove o
On 10/27/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-10-27 at 10:26 -0700, jerry gay wrote:
>
> > we're missing some parts of a testing framework. we don't have the
> > ability to write test files in PIR, so we're dependent on a perl
> > install for testing. perl's a great language for
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
> Hello all,
>
> I have a question about method conflict resolution works for roles, and I
> cannot seem to find this in any
> of the Apoc/Syn documents.
>
> Here is the basic issue:
>
> role Foo {
> method foo { ... }
> m
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
> I have a question about method conflict resolution works for roles,
> and I cannot seem to find this in any of the Apoc/Syn documents.
>
> Here is the basic issue:
>
> role Foo {
> method foo { ... }
> method bar { ... }
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
> If, OTOH we have a diamond inheritence:
You mean composition. There is no "role inheritance" :)
>
> role A { method foo { ... } }
> role B does A {};
> role C does A {};
> class D does A does B { };
I'm as
On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
> You mean composition. There is no "role inheritance" :)
Oops ;-)
> I'm assuming you meant
>
> class D does B does C { ... }
I always do that crap... =(
> > I'm not sure we need to resolve the conflict.
>
> It depend
On Tue, 25 Oct 2005, Juerd wrote:
> For comparison, here is the same code snippet again. First with, and
> then without explicit $_.
>
> With:
>
> given ($subject) -> $_ {
> $_ ~~ s/foo/bar/;
> $_++;
> $_ x= 2;
> $_ ~= "!";
> }
>
> Without:
>
> given ($su
> But IMHO the reduction in typing for this relatively minor issue is not
> really worth the surprise to newbies at seeing operandless operators.
AMEN!
Rob
John Williams:
> ($x *=2) += 1;
Or ($x *= 2) ++;
Maybe the comma should be taught a new trick:
$x *= 2, ++, /= 3;
meaning
$x = (($x * 2) + 1) / 3;
Or RPN-like:
$x #= 2* 1+ 3/;
--
Grtz, Ruud
Yuval,
On Oct 28, 2005, at 10:59 AM, Yuval Kogman wrote:
On Thu, Oct 27, 2005 at 22:19:16 -0400, Stevan Little wrote:
Now, at this point we have a method conflict in suspension since
(according to A/S-12) method conflicts do
not throw an error until a role is composed into a class. This
me
On Oct 28, 2005, at 11:17 AM, Jonathan Scott Duff wrote:
On Thu, Oct 27, 2005 at 10:19:16PM -0400, Stevan Little wrote:
I have a question about method conflict resolution works for roles,
and I cannot seem to find this in any of the Apoc/Syn documents.
Here is the basic issue:
role Foo {
On Oct 28, 2005, at 11:38 AM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 04:59:18PM +0200, Yuval Kogman wrote:
If, OTOH we have a diamond inheritence:
You mean composition. There is no "role inheritance" :)
role A { method foo { ... } }
role B does A {};
role C does A
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
> I should be allowed to create a role with all sorts of conflicts which
> I leave for the classes to deal with.
Er, why? I've read this sentence several times and I'm really having
trouble grasping why anyone would deliberately create
On Fri, Oct 28, 2005 at 06:23:28PM +0200, Yuval Kogman wrote:
> On Fri, Oct 28, 2005 at 10:38:31 -0500, Jonathan Scott Duff wrote:
> > Er, there is only one $:foo. X doesn't have any private members, nor
> > does Y (because they're roles). Only C has private members. So,
> > modulo the multiple
On 10/28/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Roles can hold instance data that will be composed into a class. What
> I'm saying is that if you have two roles:
>
> role X { has $:foo; }
> role Y { has $:foo; }
>
> And a class that's composed of them:
>
> class Xy does X does Y { ..
On Oct 28, 2005, at 2:54 PM, Jonathan Scott Duff wrote:
On Fri, Oct 28, 2005 at 02:29:36PM -0400, Stevan Little wrote:
I should be allowed to create a role with all sorts of conflicts
which
I leave for the classes to deal with.
Er, why? I've read this sentence several times and I'm really h
On Oct 28, 2005, at 3:04 PM, Jonathan Scott Duff wrote:
But, I'm probably wrong about this as the X role may have methods that
use $:foo in one way and the Y role may have methods that use $:foo in
some other, incompatible way, so perhaps there will be a conflict just
as when there are 2 methods
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a way
of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I actually really like the current NCI implementation, although it
suffers from a large nci.c file and all the usable prototypes need
Ovid wrote:
> The code is designed well enough that adding new features is quick and
> easy. Unfortunately, whenever I need to change my code I fire up a Web
> server and view the results in the browser and then write the tests
> after I've written the code (this is closely related to When
> test-d
Hi all,
I suspect that most of us who do test-driven development will probably
argue that tests do not slow down our development or, better still,
will speed up our development. Usually I find this is true for myself,
but not now. I could really use feedback on
http://perlmonks.org/index.pl?node
On Oct 28, 2005, at 3:45 PM, Rob Kinyon wrote:
Doing it any other way leads to the following: if A does rA and B isa
A and B defines an attribute that conflicts with the one provided by
rA, how on earth is that supposed to be detected? Especially given
that the inheritance tree of a class can be
--- "Christopher H. Laco" <[EMAIL PROTECTED]> wrote:
> I feel your pain. The test suite for Handel has xml/tt output tests
> for
> its AxKit and Template Toolkit plugins. I've got oodles of template
> pages using the components whos output I compare to static .out
> files
> that contain the expec
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Friday 28 October 2005 22:34, Christopher H. Laco wrote:
> Ovid wrote:
> > The code is designed well enough that adding new features is quick
> > and easy. Unfortunately, whenever I need to change my code I fire up
> > a Web server and view the results
On 10/28/05, Ruud H.G. van Tol <[EMAIL PROTECTED]> wrote:
> John Williams:
>
> > ($x *=2) += 1;
>
> Or ($x *= 2) ++;
>
> Maybe the comma should be taught a new trick:
>
> $x *= 2, ++, /= 3;
>
> meaning
>
> $x = (($x * 2) + 1) / 3;
>
> Or RPN-like:
>
> $x #= 2* 1+ 3/;
Oh, gee, why don't
On Oct 28, 2005, at 22:22, Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I've downloaded it and had a short look into sources. The list of
supported plat
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a misunderstanding
on my part.
I've pinched the GET_NCI_x(n) macros and accompanying get_nci_x
functio
Nick Glencross wrote:
Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
I seem to be seeing rather strange, and it's probably a
misunderstanding on my part.
Ok, I see what the problem is. PMC_data(x) is a
Leopold Toetsch wrote:
On Oct 28, 2005, at 22:22, Nick Glencross wrote:
Guys,
As mentioned on the list yesterday I started evaluating ffcall as a
way of providing NCI functionality.
http://www.haible.de/bruno/packages-ffcall.html
I've downloaded it and had a short look into sources. T
To me, the distinguishing feature between the role and class concepts
has always been that roles lack internal structure: you don't have to
worry about any hierarchies of what went into creating the role; you
just have to pay attention to what attributes and methods it will add
to whatever class yo
Here's how I see roles. This is just an attempt to formalize our
concepts so that the answer becomes an obvious truth rather than a
decision.
A role is an interface with some default implementations. Here's an example:
role Foo {
# anything that conforms to Foo must provide a foo()
On 29/10/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Moving on.
>
> role Baz {
> does Bar;
> }
>
> By my free-derivation (or composition in this case, I guess)
> principle, Baz is now equivalent to Foo. If you think of them as
> interfaces, it makes perfect sense. Baz provides no
On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Here's how I see roles. This is just an attempt to formalize our
> concepts so that the answer becomes an obvious truth rather than a
> decision.
>
> A role is an interface with some default implementations.
-snip-
> Now we ignore the inner w
On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
[snip]
> It was the fact that at each stage of the game, we summarized the
> defaults and requirements for each role, ignoring the internal makeup
> (i.e., what roles were composed into it, etc.).
So, in theory, one should be able to ask any give
On 10/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> Now, it's obvious why a class would have to resolve that conflict. I
> would say that a role would have to resolve the conflict is that a
> role should present a consistent API to the rest of the world. In
> other words, I want to be able to depe
Rob Kinyon wrote:
> Now, it's obvious why a class would have to resolve that conflict. I
> would say that a role would have to resolve the conflict is that a
> role should present a consistent API to the rest of the world. In
> other words, I want to be able to depend on the fact that classA does
>
Luke,
On Oct 28, 2005, at 9:44 PM, Luke Palmer wrote:
It was the fact that at each stage of the game, we summarized the
defaults and requirements for each role, ignoring the internal makeup
(i.e., what roles were composed into it, etc.).
This then imposes somewhat of an ordering with role comp
On Oct 28, 2005, at 11:13 PM, Luke Palmer wrote:
Most certainly. Implicit in a role or a theory is its algebra (though
we've talked about QuickCheckish ways to make it explicit). For
instance, technically the VectorSpace theory only requires you to
define identity, addition, and scalar multi
41 matches
Mail list logo
