-setting-library/Containers.pod
Log Message:
---
sets and bags don't flatten in list context
On Tue, Sep 29, 2009 at 03:49:31PM +0200, Christoph Bussenius wrote:
: Hi,
:
: I read is S03,
:
: The && and || operators are smarter about list context and return ()
: on failure in list context rather than Bool::False. The operators
: still short-circuit, but if either
Hi,
I read is S03,
The && and || operators are smarter about list context and return ()
on failure in list context rather than Bool::False. The operators
still short-circuit, but if either operator would return a false
value, it is converted to the null list in list co
HaloO Ingo,
you wrote:
according to Damian [1]...:
my %hash = (a => 1, b => 2);
my @array = %hash;
say @array[0].isa(Pair); # true
How can I override this behaviour?
class MyHash is Hash {
# Please fill in here
# my idea is to overload &*infix:<=>
Hi,
according to Damian [1]...:
my %hash = (a => 1, b => 2);
my @array = %hash;
say @array[0].isa(Pair); # true
How can I override this behaviour?
class MyHash is Hash {
# Please fill in here
}
my %hash is MyHash = (a => 1, b => 2);
my @array = %h
On 6/3/05, Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> What I would like to be able to do is:
>
> my $str = 'hello';
> my @chars = $str.chars; #
I can't see this being a problem at all. For starters, the whole "what
is a character" issue is just as relevant to +($foo.chars) as it is to
list($foo
All:
I would like to revisit the following question as there was no
decision reached AFAICT.
http://groups.google.ca/group/perl.perl6.language/browse_thread/thread/766c1b32c57a56f6/3296f0d6cad75548?q=list+context+.chars&rnum=1&hl=en#3296f0d6cad75548
What I would like to be able to do is:
my $str
r as the perl5 s/// return value. (Actually s///
returns "" on no matches now, whereas $0 would evaluate to false or 0
depending on context, but I doubt that would be a serious compatibility
issue.)
And getting the matching values before substition was done is a bonus in
list context.
~ John Williams
I realise that it's almost 2 years since the RFC deadline, plus we're
several apocolypses past the appropriate Camel chapters.
IIRC there are 5 different variants of m//
normal /g
scalar context: match from startcontinue progressive match
Chaim Frenkel writes:
> The other magic variables would simply end up as some funny 8-bit
> characters floating around. With one's handy (several thousand page)
> translation table one can then interpret the meaning.
That's insane. We're trying to get rid of special variables named
after obscure
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> [use wacky Unicode characters for new operators]
>> I can see that this would give problems for current editors and displays,
>> but by the time perl6 comes out, perhaps the situation would be better.
NT> No
Peter Scott writes:
> >You're right. If RFC 45 is implemented they would however be inconsistent.
>
> No, || is half-consistent at the moment: the left hand side is forced into
> scalar context but the result context propagates down the right hand
> side. I challenge anyone to come up with a r
Chaim Frenkel writes:
> [use wacky Unicode characters for new operators]
> I can see that this would give problems for current editors and displays,
> but by the time perl6 comes out, perhaps the situation would be better.
No. Never ever gamble on the future being better than the present.
Don't
Chaim Frenkel wrote:
> Would Unicode reduce the problem? Take some operators from the math symbols
> and make them the matrix op versions?
>
> (Now, if we add all that APL symbols ...)
Chaim, I think you are on to something here. But before jumping to Unicode or APL
to get more line noise, let'
(Not feasible yet, but...)
Would Unicode reduce the problem? Take some operators from the math symbols
and make them the matrix op versions?
Then the 'ascii' versions would remain the scalar ops.
I can see that this would give problems for current editors and displays,
but by the time perl6 com
On Tue, Aug 15, 2000 at 11:15:03PM -0700, Peter Scott wrote:
> No, || is half-consistent at the moment: the left hand side is forced into
> scalar context but the result context propagates down the right hand
> side. I challenge anyone to come up with a rationalization for this that
> does not
At 04:02 PM 8/16/00 +1000, Jeremy Howard wrote:
>Nathan Torkington wrote:
> > Your [Jeremy's] RFC says:
> > > Currently, operators applied to lists in a list context behave
> > > counter-intuitively:
> >
> > Counter-intuitively is different from consistently. Your title is
> > misleading. Perl's
Nathan Torkington wrote:
> Your [Jeremy's] RFC says:
> > Currently, operators applied to lists in a list context behave
> > counter-intuitively:
>
> Counter-intuitively is different from consistently. Your title is
> misleading. Perl's ops *are* applied consistently: they consistently
> give the
lem. This code would result in func1 and
func2 being called in list context. You've got an addition in list
context (thanks to the assignment), and that would put func1() and
func2() into list context.
+ wouldn't look to its arguments to decide what to do. + would look
at its contex
same language? Both are useful, but in different situations.
How about:
use matrix_ops;
to enable this 'consistent' behaviour of the binary ops in list
context?
Nat
20 matches
Mail list logo
