Re^12: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (context)

(you also seem to be leaning heavily on some rather strict definition of "list" that you have failed to qualify, that I have seen).

The model supposedly broken by the change is that $ returns a scalar and @ returns a list^[1]. I understood this to mean "a variable number of scalars". Is there another possibility?

You may have interpreted the word "context" in a rather strict fashion

My posts abolish the claim that introducing $a->@* "breaks the original model of sigils completely"^[2], that model supposedly being that the sigil is an indicator of the the type of the value returned. It's not.

To determine whether an expression starting with $ returns, one must also examine the rest of the expression and/or the context (in the larger sense). ($x vs @a = $x->(); vs $a = $x->();)

To determine whether an expression starting with @ returns, one must also examine the context (in the larger sense). (@a = @x; vs $a = @x;)

If I hadn't interpreted "context" narrowly, shmem would have been arguing against himself.^[3]. Any splitting of hairs is in trying to understand his disagreement, for he has yet to mention which of my premises he disagrees with, and he has yet to point out a logic error.

"I want the type of return (scalar or list) to be as close to the assignment operator as possible"
"Except demerphq is mistaken. Perl5 sigils don't denote the type of result that will be returned."
"I am with demerphq on that: It breaks the original model of sigils completely"

Comment on Re^12: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (context) Select or Download Code

Replies are listed 'Best First'.
Re^13: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (thanks) by tye (Sage) on Dec 20, 2013 at 23:17 UTC
Thanks! That is a much clearer explanation (to me, anyway). shmem already dismissed my method-call counter example. I suspect your de-ref'ing a CODE ref counter example would be similarly dismissed. I still think that they both weaken the argument, though. I was thinking I could channel shmem's point of view and prop up his argument. But when I tried to, I failed. I tend to think that seeing @{...} tells me that I'm getting an array to operate on. Whether I'm in a scalar or list context impacts what value(s) that array provides. But that falls apart for `@{...}[...]` and `@{...}{...}`, as neither of them give me an array to operate on. They all three give me a list (of scalar values)... but only if used in a list context. So there is some commonality there, but it is hard to even articulate a single technical thing that is true of all three cases (unless you ignore context or decide to be sloppy in other ways). You can certainly argue that `${...}` always meant that you got a scalar (if you ignore using that scalar to invoke code), and the `${...}->@` now violates that old pattern. But I just don't see a big problem with making the rather weak rule of "I have a guarantee for 1 of 3 (or maybe 2 or 4) sigils (if I ignore at least two whole types of dereferencing), and a similar thing that falls apart unless I'm sloppy for one more of the sigils" have yet another class of exceptions. To me, the `->` operator is what takes the scalar. There are lots of things `->` can do with the scalar. The fact that the only two available data* deref'ing things that can come after `->` also returned scalars is not what I consider a huge precedent that should be preserved for all future data deref'ing things that can come after `->`. - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^13: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (thanks)
by tye (Sage) on Dec 20, 2013 at 23:17 UTC

Thanks! That is a much clearer explanation (to me, anyway).

shmem already dismissed my method-call counter example. I suspect your de-ref'ing a CODE ref counter example would be similarly dismissed. I still think that they both weaken the argument, though.

I was thinking I could channel shmem's point of view and prop up his argument. But when I tried to, I failed.

I tend to think that seeing @{...} tells me that I'm getting an array to operate on. Whether I'm in a scalar or list context impacts what value(s) that array provides. But that falls apart for @{...}[...] and @{...}{...}, as neither of them give me an array to operate on. They all three give me a list (of scalar values)... but only if used in a list context. So there is some commonality there, but it is hard to even articulate a single technical thing that is true of all three cases (unless you ignore context or decide to be sloppy in other ways).

You can certainly argue that ${...} always meant that you got a scalar (if you ignore using that scalar to invoke code), and the ${...}->@* now violates that old pattern.

But I just don't see a big problem with making the rather weak rule of "I have a guarantee for 1 of 3 (or maybe 2 or 4) sigils (if I ignore at least two whole types of dereferencing), and a similar thing that falls apart unless I'm sloppy for one more of the sigils" have yet another class of exceptions.

To me, the -> operator is what takes the scalar. There are lots of things -> can do with the scalar. The fact that the only two available data deref'ing things that can come after -> also returned scalars is not what I consider a huge precedent that should be preserved for all future data deref'ing things that can come after ->.

- tye

[reply]
[d/l]
[select]