Dan Sugalski wrote:
I dunno. One of the things I've seen with coroutines is that as long as
you call them with no arguments, you get another iteration of the
coroutine--you actually had to call it with new arguments to reset the
thing.
The formulation of coroutines I favour doesn't work like
Acadi asked:
is it possible to extend the perl sigil behaviour .
Yes.
that is , one day somebody decides it needs ¢ as sigil for certain
class of variables . will it be possible to do . ( without rewriting
the whole perl )
Yes. Just inherit the standard Perl grammar, extend the C rule and
Austin Hastings pondered:
my $outfh = all(@input_handles);
while (<$outfh>) print;
No. Apart from the bug (leaving off the braces around the C...spot
the C hacker! ;-), this reads from each of the @input_handles and returns
a conjunction of the values that were read. The print then serializes t
Acadi asked:
> Just ( my ) terminology clean-up : in this example sub{ } is implicit
> topicalizer
No. It isn't a topicalizer at all.
> ( it does not set $_ explicitly )
Or implicitly.
> and you are setting $_ for perl .
Yes.
> that's why you can use "when" .
Yes.
is this valid ?
(mor
Dan Sugalski pondered:
What does:
>
$foo = any(Bar::new, Baz::new, Xyzzy::new);
$foo.run;
do?
Creates a disjunction of three classnames, then calls the C<.run> method on
each, in parallel, and returns a disjunction of the results of the calls
(which, in the void context is ignored, o
Scott Duff essayed:
So, I was all set to show how this could work with junctions, but then
I realized that I don't understand them well enough, so here's what I
came up with:
$j0 = $that_happens | $that_doesnt_happen;
$j1 = !$that_happens | !$that_doesnt_happen;
given ($this) {
when $j0 ~
On Saturday, November 16, 2002, at 04:52 PM, Damian Conway wrote:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$
Brent Dax wrote:
More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).
Correct. Junctive algebra and logic is slightly different. yet another
reason not to allow junctions to seep into subroutines by default.
Actually, this suggests to me a flaw in the != operator, not a flaw
Luke Palmer wrote:
sub foo($x) {
if ($x != 4) {
print "Not four\n";
}
if ($x == 4) {
print "Four\n";
}
}
sub oof($x) {
if ($x != 4) {
print "Not four\n";
}
else {
print "Four\n";
}
At 8:31 AM +1100 11/17/02, Damian Conway wrote:
Peter Haworth asked:
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap
Andrew Wilson wrote:
It's the difference between this:
print;
and this:
print $_;
It is as far as I'm concerned exactly what topic is all about.
Exactly.
It let's you write subroutines that behave like builtins with respect
> to $_. I think it's generally intended to be used like so:
Deborah Ariel Pickett wrote:
Luke wrote:
$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction
Just a sanity check, but is this kind of behaviour something we still
want from junctions?
Perhaps the above should just print JUNCTION(0x1234) or something
Luke Palmer wrote:
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
I think that today that would be written more like this:
sub bar(;$foo) is given($def_foo) {
$foo = $def_foo unless exists $foo;
...
}
Though we might get away with:
sub bar(;$foo = $def_foo) is given($
Timothy S. Nelson asked:
Question: are there any plans to have user-defined meta-operators in perl6?
Explanation: By meta-operators, I mean operators which operate on other
operators (much as APL operators do to APL functions).
Yes. The vectorizing notation (»OP«) is an example.
Larry has
Piers Cawley wrote:
[Speculations elided]
Which is somewhat dependent on being able to do C.
Which you can't do, since C is compile-time.
Damian
Peter Haworth asked:
So to get the same yield context, each call to the coroutine has to be from
the same calling frame. If you want to get several values from the same
coroutine, but from different calling contexts, can you avoid the need to
wrap it in a closure?
I don't think so.
Damian
> From: david nicol <[EMAIL PROTECTED]>
> Date: 15 Nov 2002 18:56:35 -0600
>
I don't know if you haven't been paying attention, or you're
summarizing what's happened. I'll assume the former. Forgive me if
I've misunderstood you.
>
> 1: string cat is an old and reliable horsehide drum. I've be
1: string cat is an old and reliable horsehide drum. I've been
doing C programming recently, where you can concat two literal
strings by having no other language tokens between them. Really.
That's the real basis for repeating the suggestion of juxtaposition
as a string joining operator. Syntac
18 matches
Mail list logo
