The exception would be method calls.

$object->foo() # $-sigil, but does this return a scalar?
[download]

Obviously this is bracketed as:

($object)->foo()
[download]

... so the sigil does make sense: that particular subexpression returns a scalar. However, the expression as a whole could return a list.

Some people argue that method calls should always return a scalar; if you need to return more than one result, return an arrayref.

Some people argue that method calls should always return a scalar; if you need to return more than one result, return an arrayref.

Ironically, these are the people who would benefit the most from ->@*.

The result of the evaluation of an identifier with its sigil may be coerced to something diferent depending on the context in which that evaluation is effective

That's not how context works at all, but even if you only consider list context, you still have:

• @{ ... } evaluates to an array or a list.
• @{ ... }[1,2] evaluates to a list.
• %{ ... }[1,2] evaluates to a list.
• %{ ... } evaluates to a hash or a list.
• *{ ... } returns a scalar (glob).
• *{ ... }{ARRAY} returns a scalar (reference).
• &{ ... } can evaluate to a list or a scalar.
• ${ ... }->() can evaluate to a list or a scalar.

so in list context,

• @... can evaluate to an array or a list.
• %... can evaluate to an hash or a list.
• $... can evaluate to a list or a scalar.
• &... can evaluate to a list or a scalar.
• *... can evaluate to a glob or a reference.

Of course they do, at least since perl4 patchlevel 36 (or 19 on Atari).

I can't verify that claim, but I doubt it. At the very least, it hasn't been the case since 5.6 which was released 14 years ago. There is not a single sigil that indicates the type of the value returned.

the evaluation of an identifier bare of any context depends on its sigil.

Noone said otherwise. Of course it depends on the sigil. @a is not the same as $a.

The premise demerphq put forth is that the sigil is an indicator of the type of value to which the sigiled expression evaluates to. That's clearly not the case. You can't break a model that doesn't exist.

Anyone care to shed light on why ikegami's post received so many downvotes?

Is there a mistake in his overview of the return types of sigil'ed expressions, or in his general conception of Perl contexts and lists?
I'm asking because my own conception matches what he wrote, so if it's wrong I'd be interested in learning why.

Trying to split hairs is often unconvincing and then annoying to those who disagree.

- tye        

That's not how context works at all

I'm baffled. So you are telling me that I don't know about context in Perl?

• %{ ... } evaluates to a hash or a list.

And how, pray, is the "or" resolved? There.

Anyways, you are right. Im sick of tennis match like conversations. I'm not here to win.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

I'm baffled. So you are telling me that I don't know about context in Perl?

I can't comment on what you know, just on what you say.

Context doesn't cause values to be coerced. Operators return different values based on the context. That's why $x = (4,5,6); and @a = (4,5,6); $x = @a; result in different values in $x.

And how, pray, is the "or" resolved? There.

I'm not sure what the means. Are you asking how it's determined when %... evaluates to a hash and when %... evaluates to a list? It's based on the operator that parses it. e.g. keys(%foo) or \%foo vs print(%foo).

Anyways, you are right. Im sick of tennis match like conversations. I'm not here to win.

you'll never be pope with that attitude ;) :D