If any of you are willing, I would appreciate any general feedback on
my first complete module port to Perl 6, including test suite,
particularly if any parts don't look like proper Perl 6.
I haven't tried executing it yet, since Pugs lacks some features.
But it will be easier on them if what
[EMAIL PROTECTED] wrote:
It would behave like a tied sub (or method), with a .dispatch method
to decide which of the contained routines should be called this
particular time. Manhattan would be the default. However, one can
override the dispatch logic; implementing Luke's Patterns idea, for
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short name.
Discussion seems
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
There lingers the case of:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume Random, since
Larry Wall wrote:
That's...sick... I love it. *Please* don't tell Damian.
whisper
Well there are some people who consider it quite sane :)
http://www.cduce.org/papers/icalp04.pdf
Abstract:
This paper studies the problem of matching sequences against
regular expressions in order to produce
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently being used? E.g.:
[EMAIL PROTECTED] wrote:
What about multi subs? They can be defined everywhere. Given:
multi sub *foo(A $a, B $b) {...}
Is this something like:
%globals{foo} -- MultiSub{foo_A_B = Sub, ...}
What about a not so global multi:
multi sub foo(A $a, B $b) {...}
Thanks for clarifying,
leo
Uh, the
HaloO Luke,
you wrote:
The words 'covariant' and 'contravariant' in this context seem like
voodoo math. Please explain what you mean.
'Co' means together like in coproduction. And 'contra' is the opposite
as in counterproductive. With instanciating parametric types the question
arises how a
On Thu, 10 Mar 2005, [UTF-8] Thomas Sandla~_ wrote:
'Co' means together like in coproduction. And 'contra' is the opposite
'Streaming of digestive byproducts'? ;-)
Sorry for the OT - couldn't resist! This pun
At 17:53 +0100 3/10/05, Thomas Sandlaß wrote:
'Co' means together like in coproduction. And 'contra' is the opposite
as in counterproductive. With instanciating parametric types the question
arises how a subtype relation between instanciating types propagates
to the template. E.g with Int : Num,
At 17:53 +0100 3/10/05, Thomas Sandlaß wrote:
[request for clarification of 'covariant' and 'contravariant' usage]
'Co' means together like in coproduction. And 'contra' is the opposite
as in counterproductive. With instanciating parametric types the question
arises how a subtype relation
Terrence Brannon wrote:
I gave a talk on Perl 6 Junctions at the Thousand Oaks Perl Mongers
meeting last night
http://www.hcoop.net/~terry/perl/talks/p6-junctions/index.html
and two questions/desires came out of it:
1: will it be possible to know which element of a junction is
currently
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
There lingers the case of:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be Manhattan? Or does it assume
Given:
class Foo {
method Bar () {...};
}
sub Bar (Any $x) {...};
my Foo $f;
Bar $f;
Is that last line the same as:
Bar.($f);
or
$f.Bar;
Does it matter if we change C sub Bar to C multi sub Bar ?
Is there some form of implicit multi sub that gets created to make C
Bar
Leopold Toetsch wrote:
Rod Adams [EMAIL PROTECTED] wrote:
It seems to me that there are several advantages to making a group of
multi with the same short name a single object, of type
MultiSub|MultiMethod, which internally holds references to the all the
various routines that share that short
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider this to be a core
Rod Adams wrote:
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian to
come back unless someone else knows for certain.
My understanding is that all lists are conceptually lazy. any(2..Inf)
is perfectly valid.
Sam Vilain wrote:
Rod Adams wrote:
I do not believe that is possible.
This is the filtering or unification behavior that people keep
wanting junctions to have, which they do not.
Aww! But what about all the great problems that could be expressed
with them? I know of two languages that consider
Dave Whipp wrote:
Rod Adams wrote:
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian
to come back unless someone else knows for certain.
My understanding is that all lists are conceptually lazy.
any(2..Inf)
RA == Rod Adams [EMAIL PROTECTED] writes:
My understanding is that all lists are conceptually
lazy. any(2..Inf) is perfectly valid.
RA The list being fed into the junction can be lazy. But I believe that
RA the list gets iterated over completely in the creation of the
RA
On Thu, Mar 10, 2005 at 02:22:20PM -0600, Rod Adams wrote:
David Storrs wrote:
On Wed, Mar 09, 2005 at 03:38:52PM -0600, Rod Adams wrote:
use Foo; # from above, exports bar is MMD::Random
multi sub bar {...}
Does this generate an error, since one could expect this particular bar
to be
On Thu, Mar 10, 2005 at 03:27:23PM -0600, Rod Adams wrote:
Given:
class Foo {
method Bar () {...};
}
sub Bar (Any $x) {...};
my Foo $f;
Bar $f;
Is that last line the same as:
Bar.($f);
or
$f.Bar;
I don't see how it can be anything but the former.
Rod Adams writes:
Dave Whipp wrote:
Rod Adams wrote:
I do not believe that you can create a 'lazy junction'. But I don't
recall the topic coming up before, so we'll have to wait for Damian
to come back unless someone else knows for certain.
My understanding is that all lists are
Rod Adams wrote:
And as one who recently proposed a way of getting Prolog like features
in Perl (through Rules, not Junctions), I understand the appeal
completely. Junctions are not the way to that goal. They are something
different.
Taking multiple values at once is what junctions are all
24 matches
Mail list logo
