Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^10: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (hare/2)

by ikegami (Pope)
on Dec 11, 2013 at 20:25 UTC ( #1066710=note: print w/ replies, xml ) Need Help??


in reply to Re^9: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (hare/2)
in thread use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20

I don't call @... return a scalar or an array an exceedingly small difference from @... returning a list. I'm not even sure how the difference could be greater.


Comment on Re^10: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (hare/2)
Select or Download Code
Re^11: use feature 'postderef'; # Postfix Dereference Syntax is coming in 5.20 (context)
by tye (Cardinal) on Dec 11, 2013 at 20:55 UTC

    I'm really not sure what you are talking about. But I even find this reply to be splitting hairs to declare "returning an array" substantially different from "returning a list". I have little clue what you even see as the distinction between those two.

    But I'll give you a hint: You may have interpreted the word "context" in a rather strict fashion, significantly changing the context in which these things had been being discussed (you also seem to be leaning heavily on some rather strict definition of "list" that you have failed to qualify, that I have seen). This appears to me to have dragged the conversational context from the realm of semantic hair splitting into technical detail hair splitting. And some might view that as trivializing things (even further than the trivial point they were at).

    I was already rather at a loss for how the semantic wrangling could be applied with much significance to the arguments for or against post-fix dereferencing syntax. I found myself quite at a loss for how to apply your response to those semantic wranglings and thus even more at a loss for how to find relevance in them it to what appears to me to be the thread topic.

    The closest I have come to understanding your response is to see it as (only implicitly, which makes it worse) splitting hairs on the definition of "the context in which that evaluation is effective" and also fairly tangential to the preceding discussion.

    I provide this much detail in my explanation in the hope that some of it will end up being enlightening to you, and not in an attempt to criticize.

    - tye        

      (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.


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

        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        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1066710]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2014-11-26 03:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (160 votes), past polls