Jonathan Lang wrote:
I hope not. My understanding is that '{ ... }' is supposed to
represent the notion of abstract routines: if you compose a role that
has such routines into a class or package, I'd expect the package to
complain bitterly if any such routines are left with yada-yadas as
their
TSa wrote:
HaloO,
Miroslav Silovic wrote:
What bugs me is a possible duplication of functionality. I believe
that declarative requirements should go on roles. And then packages
could do them, like this:
package Foo does FooMultiPrototypes {
...
}
I like this idea because it makes roles
Jonathan Lang wrote:
Aaron Sherman wrote:
Jonathan Lang wrote:
Actually, it's a promise made by a package (not a class) to meet the
specification given by a role (which can, and in this case probably
does, reside in a separate file - quite likely one heavily laced with
POD).
That's a fine
Larry Wall wrote:
On Mon, Sep 25, 2006 at 09:02:56PM -0500, Mark Stosberg wrote:
:
: eval($yaml, :langyaml);
:
: Still, these options may not substitute for the kind of role-based
: solution you have mind.
I'm not sure it's wise to overload eval this way. Seems like a
great way to defeat
Executive summary:
I suggest a signature prototype that all multis defined in or exported
to the current namespace must match (they match if the proto would allow
the same argument list as the multi, though the multi may be more
specific). Prototypes are exportable. Documentation tie-ins are
Trey Harris wrote:
In a message dated Wed, 27 Sep 2006, Aaron Sherman writes:
Any thoughts?
I'm still thinking about the practical implications of this... but
what immediately occurs to me:
The point of multiple, as opposed to single, dispatch (well, one of
the points, and the only point
Carried over form IRC to placeholder the conversation as I saw it:
We define the following in S06 as immutable types:
ListLazy Perl list (composed of Seq and Range parts)
Seq Completely evaluated (hence immutable) sequence
Range Incrementally generated (hence
Jonathan Lang wrote:
Larry Wall wrote:
You don't need to use | to store a capture any more than you need @ to
store an array. Just as
$x = @b;
@$x;
gives you the original array,
Huh. I'm not used to this happening. So what would the following
code do, and why?
my @b = ('foo',
[EMAIL PROTECTED] wrote:
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 10 Aug 2004
- Last Modified: 18 Sept 2006
+ Last Modified: 20 Sept 2006
Number: 2
- Version: 69
+ Version: 70
+| capture/arguments/match
+|$args; # all of the above
I'll read that as
Mark J. Reed wrote:
Ok, I dkimmed through the synopses again and didn't see this offhand.
If I have two arrays @a and @b and I wish to create a two-element list
out of them - a la Perl5 ([EMAIL PROTECTED], [EMAIL PROTECTED]) - what's the
correct way to do
that in Perl6? If it's still ([EMAIL
All sounds good up to:
Larry Wall wrote:
The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.
Well, in that case, should
Damian Conway wrote:
In other words, classify() takes a list of values, examines each in
turn, and ascribes a label value to it. The call returns a list of
pairs, where each pair key is one of the label values and each pair
value is an array of all the list values that were ascribed that
[EMAIL PROTECTED] wrote:
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, keep implies throwing
the rest away,I.e., modifying the list. Select has the advantage of
lacking that connotation. To avoid dissonance with the two
Trey Harris wrote:
Might I propose the following normalization:
1. .call, method definition call(), and .wrap call all take captures.
2. .call() and both types of call() all pass on the arguments of the
current subroutine.
3. To call with no arguments, use .call(\()) and call(\()).
I
Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: Might I propose the following normalization:
:
: 1. .call, method definition call(), and .wrap call all take captures.
:
: 2. .call() and both types of call() all pass on the arguments
Larry Wall wrote:
Okay, I think this is worth bringing up to the top level.
Fact: Captures seem to be turning into a first-class data structure
that can represent:
argument lists
match results
XML nodes
anything that requires all of $, @, and % bits.
This is quite true, and
Larry Wall wrote:
On Wed, Sep 20, 2006 at 05:18:12PM -0400, Aaron Sherman wrote:
: For this reason, I'd suggest putting away the Latin-1 glyphset and
: instead focusing on developing operators to act on containers with
: multiple access methods and their expanded forms.
There's already
What happens to a program that creates a thread with a shared variable
between it and the parent, and then the parent modifies the class from
which the variable derives? Does the shared variable pick up the type
change? Does the thread see this change?
Smylers wrote:
Randal L. Schwartz writes:
Smylers == Smylers [EMAIL PROTECTED] writes:
Smylers No: no aliases. Perl does not have a tradition of these,
except for/foreach. :)
I don't reckon one instance is enough to be labelled a tradition!
(Um ... actually I forgot about that one. But
Mark J. Reed wrote:
(by the way, newbies don't use grep because list transforms confuse and
intimidate, not because of the name).
I dispute that. List transforms and grep are wholly separate beast,
This was a minor side-comment. Let's stay focused and not rat-hole on
our respective
Jonathan Lang wrote:
Larry Wall wrote:
Mark J. Reed wrote:
: I have no horse in this race. My personal preference would be to
: leave grep as grep. My second choice is select, which to me is
: more descriptive than filter; it also readily suggests an antonym of
: reject to do a grep -v (cf.
David Brunton wrote:
Aaron Sherman wrote: replies snipped /
IMHO, the golden rule of programming languages should be: if you
need a namespace, create one.
Is there any reason these meta methods could not be part of some
default function package like Math::Basic and Math::Trig? The
package
I didn't see this going back, sorry if I missed someone sending the mail.
There was a discussion on IRC on Sept 9th about the -X filetest
operators between at least audreyt, Juerd, myself and markstos. The
problem with these operators was that they conflicted in some cases with
the parsing of
I was looking over an example of named parameter passing:
foo(:a1, :b2)
And had the thought that we might be able to get away with treating
named parameters as lvalues, making the above:
foo(:a=1, :b=2)
Would this be unreasonable? Does it break anything else? I'm not sure
Jonathan Scott Duff wrote:
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote:
Larry Wall wrote:
.META is more correct at the moment.
Does making it all upper caps really help? It's still a pollution of the
method space, any way that you look at it...
Yeah but perl has already
, though.)
Both C$_ (the value) and C$x (the match specification) here are
potentially references to container objects.
And since lists promote to arrays in scalar context, there need be no
separate entries for lists.
(table goes here)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer
On Wed, 2006-07-12 at 17:52 -0700, Larry Wall wrote:
On Wed, Jul 12, 2006 at 12:51:57PM -0400, Aaron Sherman wrote:
: I would assume that all classes automatically define:
:
: multi submethod *infix:as ($self: $?CLASS) { $self }
Hmm, as is really only intended for explicit type mutation
programmers as a builtin, it will at least give Perl 5
programmers a sense of what happened to what they knew. The API
documents should probably be the more authoritative reference for
implementing P6 core libraries.
--
Aaron Sherman [EMAIL PROTECTED]
http://www.ajs.com/~ajs/
Mushroom Photography
to match against it
smartly, you can always request your poison:
$a ~~ ($b as Regex)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Smylers wrote:
[EMAIL PROTECTED] commits:
New Revision: 10077
Modified: doc/trunk/design/syn/S02.pod
==
-foo.bar # foo().bar -- postfix prevents args
+foo.bar# foo().bar -- illegal
trying to make
sure that the docs I write aren't utterly, worthlessly wrong. :-/
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
with polymorphically).
In fact, I would expect that this bit of behind-the-curtain magic is how
the MCP arranges for polymorphism when you:
sub foo(Object $x) {...}
my A $y;
foo($y);
Is all of that fair?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines
) {
return $a === $b;
}
our Bool multi infix:== ( Num $a, Num $b) {
return $a === $b;
}
our Bool multi infix:== ( Bool $a, Bool $b ) {
return $a === $b;
}
# ... complex, bit, etc.
--
Aaron Sherman
On Wed, 2006-07-12 at 15:32 -0500, Jonathan Scott Duff wrote:
On Wed, Jul 12, 2006 at 04:16:13PM -0400, Aaron Sherman wrote:
On Wed, 2006-07-12 at 19:25 +0300, Yuval Kogman wrote:
4. will we have a deep (possibly optimized[1]) equality operator, that
*will* return true for @foo = ( [ 1, 2
Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into ~~, but without invoking code when it
shouldn't.
But it should! It's the smart match! If the rhs
into the section for each type of container (too many
eaches...). I don't even have a section for things like Seq and Buf yet,
and I'd rather not if I don't have to.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more
On Tue, 2006-07-11 at 10:06 -0400, Aaron Sherman wrote:
For example:
our List multi Container::each(Container [EMAIL PROTECTED])
In thinking about each, I've come across an interesting need. I wrote
this example:
for each(=; 1..*) - ($line, $lineno) {
say $lineno: $line;
}
Which
really blows some assumptions that I'm willing to bet
many people will make.
--
Aaron Sherman [EMAIL PROTECTED]
On Tue, 2006-07-11 at 09:53 -0700, Trey Harris wrote:
In a message dated Tue, 11 Jul 2006, Aaron Sherman writes:
But would it be reasonable to also provide a named-only parameter to
each for that purpose?
It sounds reasonable to me, but :stop reads badly. Maybe C:strictly?
Maybe it's
to use that modifier.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
On Tue, 2006-07-11 at 16:22 -0400, Aaron Sherman wrote:
zip(:fewest, @a;@b;@c); # Until one runs out
Once again, I missed some Larry magic. He already selected :shortest
for this, so I guess on roundrobin, it's :longest... ignore my
choices.
I think just like Larry, but 1,000 times slower
the line between S29 and that document
are There's some overlap, but I want to keep it minimal.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Darren Duncan wrote:
At 8:32 PM -0400 7/8/06, Joe Gottman wrote:
I have one minor comment about join. You should specify its behavior
when
it is passed an empty list. Does it return undef or the empty string?
I think it makes the most sense for it to return an empty string,
which is a
I've gathered my ducks in a row, used the feedback that I've gotten so
far, and I think I'm ready to officially update S29. For that I need two
things:
1) I'd really like Larry to glance over the changes and $s29.bless but
all comments are welcome
2) I'll need commit rights to whatever
of the
difference in parameter passing conventions, but the example above
simulates its effect using C%C.
=cut
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
;
elispuse hanoi;
say %*ENV{PATH}
hanoi(13);
Inventing syntactic sugar for the back-end case probably doesn't buy you
anything special.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
We had some good machines, but they don't work no more. -Shriekback
Larry (bless his wire-photographing heart) took the time to re-vamp S29.
Of course, this threw off all of my collating of S29, but that's fine
since he's actually answered more of my questions than I could have
hoped.
The fourth of July weekend was fairly slow for me, so I started with
Larry's
On Wed, 2006-07-05 at 16:09 -0400, Aaron Sherman wrote:
The fourth of July weekend was fairly slow for me, so I started with
Larry's S29 and went forward.
My first pass at a revised S29 is attached.
I already see one problem. as slipped in, which is an operator, not a
function.
--
Aaron
, but I don't think those get to get called
until everything goes away (since there's a reference chain between
them).
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Tue, 2005-11-15 at 12:30, Luke Palmer wrote:
On 11/15/05, Aaron Sherman [EMAIL PROTECTED] wrote:
This question came out of a joking comment on IRC, but it's a serious
concern. Can chained buts be optimized, or must the compiler strictly
create intermediate metaclasses, classes
product, and replace the draft once it's actually in a consistent
state. Otherwise, I'd have to muck around with branching, and I'd rather
not.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Wed, 2005-10-19 at 16:07, Aaron Sherman wrote:
I thus propose 2005-03-16 (last Rod Adams update) - 2005-10-17
(yesterday, yes that's arbitrary) on the mailing list and pugs/ext from
svn as of revision 7682 as the inputs for the next revision of S29
s{pugs/ext}{pugs/t/builtins} for the most
On Wed, 2005-05-25 at 09:11, Piers Cawley wrote:
Aaron Sherman [EMAIL PROTECTED] writes:
There are many gotchas that fall out of that. For example, you might
have a special role that overrides .print to handle structured data, so
your code says:
my Foo $obj;
given $obj
to implement the dynamic functionality of Any, and
given the recent ponie/parrot discussions around flags, I think using
virtual methods as flags is probably the right way to go
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me
, and it overrode print. But, if it just inherited a
print(), then it works. In other words, this code will mysteriously fail
the second someone innocently adds a print method to Foo!
Action at a distance... my head hurts.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's
On Wed, 2005-05-18 at 14:57, TSa (Thomas Sandlaß) wrote:
Aaron Sherman wrote:
Ok, so log and log10:
multi sub Math::Basic::log (: Num ?$x = $CALLER::_, Num +$base);
log10 := log.assuming:base(10);
Sorry, I don't want to interfere but two nit-pickings from me:
1
to the above bit from S12, $a.x calls single dispatch first,
so it should call the anonymous role's method x, right?
If I wanted to call the multi, I could aways say: x($a), couldn't I?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me
, in which
case, how does log find the right $_?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
Now:
Declaration ExplicitImplicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \
Consistent:
has $.var \ $obj.var \
On Sun, 2005-05-15 at 13:33 -0500, Rod Adams wrote:
Aaron Sherman wrote:
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types.
My thoughts on writing it were:
The boxed version is the specification, in that the language must
support them
On Mon, 2005-05-16 at 04:02 -0600, Luke Palmer wrote:
I am currently failing to see the need for a distinction between $.
and $: . The only difference is in whether accessors are *generated*;
Not at all! There are numerous differences as described in A12:
* The attribute gets a private
On Mon, 2005-05-16 at 12:23 +0200, Juerd wrote:
Aaron Sherman skribis 2005-05-16 5:54 (-0400):
I'm not sure I see that you changed anything
[...]
Okay, let's try it differently, then:
[...something that looks like braille...]
And now, you've s/[\$\w]+//g; what point are you making, Juerd
On Mon, 2005-05-16 at 07:21, Aaron Sherman wrote:
* %$obj notation includes private attributes when inside, but not
when outside the class
This bit was new to me this morning, when I looked it up, and I'd like
to delve into a bit more.
If the idea is to provide a hash-like thing
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types. This seems like potentially spurious
overhead in some situations, while essential in others, so I wanted to
work out a set of rules for when boxed vs. unboxed types would be used
in core routines
On Sun, 2005-05-15 at 18:34 +0200, Juerd wrote:
I've been looking for a good moment to come with this, but there is
none, making this as good a point as any: I don't like the dot in
attributes, and the colon that replaces it.
If we have .method and .:method, then we should have $.attr and
On Sat, 2005-05-14 at 16:22 +0200, Eirik Berg Hanssen wrote:
I suppose the first must just make sure not to flatten the %hash:
$leaf_value = [.{}] \%hash, @keys; # %hash .{$key1} . {$key2} ...
Side point on the whole topic: I just LOVE \ as an explosive list-
context flattening preventer.
On Sat, 2005-05-14 at 22:06 +1000, Damian Conway wrote:
Luke wrote:
If the alternatives are:
* declare $self, use $self.method, and .method for calling on $_
* use .method, and use $_.method for calling on $_
I'd say the former has no case.
I, for one, am not nearly
, and while ::... has a meaning in S05, :... does not, so
as long as we never allow a modifier called ::, this would work.
In fact, Larry, I think it's safe to say that is actually more
sought-after than that : everyone wants ;-)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
solution
seems fine to me.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
, split(' ') can be used to emulate awk's default
behavior, whereas split(/ /) will give you as many null
initial fields as there are leading spaces [...]
And there you have it.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying
On Thu, 2005-05-12 at 13:44, Patrick R. Michaud wrote:
On Thu, May 12, 2005 at 12:53:46PM -0400, Aaron Sherman wrote:
In other words, it acts as though one had written
$rule = rx :w / plane ::: (\d+) | train ::: (\w+) | auto ::: (\S+) / ;
and not
$rule = rx :w
On Thu, 2005-05-12 at 15:41, Patrick R. Michaud wrote:
$rule = rx :w / plane ::: (\d+) | train ::: (\w+) | auto ::: (\S+) / ;
$rule = rx :w /[ plane :: (\d+) | train :: (\w+) | auto :: (\S+) ]/ ;
On Thu, May 12, 2005 at 02:29:24PM -0400, Aaron Sherman wrote:
On Thu, 2005-05-12 at 13
On Fri, 2005-05-13 at 12:07 +1200, Sam Vilain wrote:
Rod Adams wrote:
It looks like I'm going to have to punt on finishing S29.
On behalf of pugs committers, we will gladly adopt this task, which is in
the pugs repository already at docs/S29draft.pod, as well as having a set
of foundation
On Wed, 2005-05-11 at 17:48 +1000, Damian Conway wrote:
But it does raise an important point: the discrepancy between $42 and $/[41]
*is* a great opportunity for off-by-on errors. Previously, however, @Larry
have tossed back and forth the possibility of using $0 as the first capture
modules.
That seems like a reasonable thing to want, but I'm not sure how it
could be controlled correctly.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
), you would expect to have something like
(arm-waving some naming specifics):
given $program.(@args) {
when Exception { $*ERR.print $_.err; exit 1 }
default { exit +$_ }
}
Am I getting it now?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer
direct your attention to:
http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/24ef8f421548b806/f119fc38427f9f3b?q=comma+one+elementrnum=2#f119fc38427f9f3b
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me
a little more?
I'm confused as well. How does that play with Larry's comment:
http://groups-beta.google.com/group/perl.perl6.language/browse_frm/thread/54a1135c012b97bf/d17b4bc5ae7db058?q=list+commarnum=5hl=en#d17b4bc5ae7db058
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer
I'm working on an annotated version of the mailing list so that old
postings can be more easily researched. My very primitive implementation
is:
http://www.ajs.com/~ajs/cgi-bin/p6l-index.cgi
The input datafile is:
http://www.ajs.com/~ajs/p6l.dat
I'm using Google Groups as a
do think
that we can safely expect Perl 6 to have to deal with these concepts and
would be well served by building in a standard way to add your More Than
One Way later on through CPAN.
On Fri, 2005-05-06 at 15:10, Larry Wall wrote:
On Fri, May 06, 2005 at 08:19:05AM -0400, Aaron Sherman wrote
On Thu, 2005-05-05 at 15:15, Aaron Sherman wrote:
Dash this all on the rocks if you want, but understand that this is not
an off-the-cuff reply, but something that I've spent a lot of time
mulling over
[...]
First off, IMHO, open should be an alias for a closure-wrapped
constructor, like so
how to re-write the string
registration so that it behaves itself (that is, unregisters when the
use goes out of scope), I think it would be perfect.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
::Socket.new takes parameters that are built out of its
entire inheritance tree, so a change to IO::Handle might radically
modify the signature of the constructor.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
; # Get IO::Pipe
my IO $sock_fh = 'http://www.perl.org/' = $IO::URI; # Get IO::Socket
would just DWIM. But, perhaps I'm expecting too much...
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
to
special-case those?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Wed, 2005-05-04 at 09:06, Larry Wall wrote:
On Wed, May 04, 2005 at 09:00:46AM -0400, Aaron Sherman wrote:
: That said, let me try to be helpful, and not just complain:
:
: $sum = (+) @array;
It's certainly one of the ones I considered, along with all the other
brackets
?!)
So I guess he's befunging you!
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Wed, 2005-05-04 at 09:45, Larry Wall wrote:
On Wed, May 04, 2005 at 09:34:28AM -0400, Aaron Sherman wrote:
: Hmmm...
:
: $sum = [+] @array
:
: Nice.
I just thought that'd be visually confusing in a subscript:
@foo[0..9; [;[EMAIL PROTECTED]; 0..9]
Now, why did I think you
, a coroutine would be
defined by the use of a variant of return, such as:
sub generate_this() {
for 1..10 - $_ {
coreturn $_;
}
}
Of course, I'm pulling that out of my @ss, so YMMV. ;-)
--
Aaron Sherman [EMAIL PROTECTED]
Senior
On Wed, 2005-05-04 at 10:07, Aaron Sherman wrote:
On Wed, 2005-05-04 at 09:47, Joshua Gatcomb wrote:
So without asking for S17 in its entirety to be written, is it
possible to get a synopsis of how p6 will do coroutines?
A coroutine is just a functional unit that can be re-started after
.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
a
method was created in the metaclass, but I don't think that's too hard.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: On a side note about auto-accessors, if I say:
:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens
On Sat, 2005-04-30 at 16:55 -0700, Brent 'Dax' Royal-Gordon wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
That would be absolutely horrible.
Str|Int is simply the type of Yes|1, isn't it? That would certainly
make signature
On Tue, 2005-04-26 at 09:37 -0600, Luke Palmer wrote:
We're thinking at the moment that `while` will probably look like this:
sub statement:while (cond is lazy, block) {
[...]
Just curious, why a sub and not a macro?
That does pose a problem with:
given $foo {
until
On Sat, 2005-04-30 at 22:24 +0800, Autrijus Tang wrote:
On Sat, Apr 30, 2005 at 09:13:26AM -0500, Abhijit Mahabal wrote:
I do not see how any auto-threading occurs in that code. It is completely
innocuous in that sense, and I don't think that is what horrified David.
What was troublesome
,
z g3 do
action x, y, z
end
This would execute all permutations of x, y and z in parallel (or as
close to parallel as the execution environment allowed for).
Kind of neat.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound
? ;-)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
On Fri, 2005-04-29 at 08:54, Autrijus Tang wrote:
On Fri, Apr 29, 2005 at 08:33:56AM -0400, Aaron Sherman wrote:
Currently per S09, Perl 6 collection types all have uniform types,
so one has to use the `List of Any` or `Array of Any` return type
instead. That seriously hinders inference
variable.
Well, more to the point, autothreading of junctions will hit the wall of
Parrot duping the interpreter. That's probably not something you want to
suffer just to resolve a junction, is it?
I suppose it depends on how snarled the junction is
--
Aaron Sherman [EMAIL PROTECTED]
Senior
101 - 200 of 537 matches
Mail list logo
