develooper Front page | perl.perl5.porters | Postings from July 2013

Re: postfix dereference syntax

Thread Previous | Thread Next
D Perrett
July 3, 2013 21:51
Re: postfix dereference syntax
Message ID:
perldoc perlvar says "$* was a variable that you could use to enable
multiline matching.", removed in 5.10.0.

Is it ok to remove a punctuation variable in and then use the ASCII
space for something else?

"Does it have to be punctuation?  $array->flatten"

I was already wondering about this: It seems we increasingly want to
treat variables or references as objects and do method calls on them
but have no way of doing so without polluting the 'namespace' of
object methods. Would we be better with a syntax for builtin methods?


And why stop there...

  $couldBeUndef->>isa('IO::File'); # so we don't have to check if it's
an object first!

The question is then whether we open the gates to metaobject stuff in
there so that when use /Mo.*/; adds ->>around and frees up ->around.


On 3 July 2013 22:08, Ricardo Signes <> wrote:
> This is sort of a general reply to the whole set of replies.  I just picked
> David's post to reply to because it seemed like I might quote it the most.
> I was going to apologize for the long dely in replying, but these posts were
> just yesterday?  Boy, time drags on when you're debugging SSL.
> Some of the replies that already happened recreated some of the trains of
> thought I'd explored, and reasons to reject them, and seeing them happen
> outside my head was good, because I got to reflect on them some more.  Then
> again, I don't think it changed what I'm thinking too much.
>> Do you want that bikeshed argument now or later?
> I want us to discuss the design only as much as is required to prove that it
> can be done well.  If it's "->@:" versus "->@*" because one looks prettier, I
> will tell people to go away.  If it's that "->@*" can't possibly fit the
> grammar but "->:@" can, I think it's important to figure out.
>> What are you looking for?  General reaction?  Edge cases?  Volunteers?
> Edge cases so that we can confidently turn it over to a volunteer (or
> conscript).
>> Your OP reads a bit more like a "meditation" with only an implicit
>> "What do you think?"
> Man, if I ever thought an *explicit* request for opinions was needed on p5p,
> I'd check my prescription. ;)
>> > [prototypes]
>> Grudgingly, I agree:  \@ should accept a postfix dereference.
> Agreed, except not grudgingly.  Postfix dereference needs to be a first class
> dereference.  Every exception we have to document is another sign of failure.
> That's why I agree so much with:
>> > [failure modes and conditional deref]
>> I agree with your later statement that they are nice to have together
>> but not required to have together.  On conditional arrow itself, I
>> must have missed the restarted discussion.  Frankly, I think the way
>> out of the edge cases is to define it as syntactically equivalent to
>> something else that has known properties (much as you're doing for
>> postfix deref being equivalent to circumfix deref) and reason from
>> there.
>> (1) Code references?  Do we want consistency and allow $coderef->&*?
>> Would it have semantics like $coderef->() or &$coderef (passing
>> through @_)?
> Yes, and like the ampersand form.
>> (2) Glob references?
> Yes.
>>     deref: $array->@[]
>>     slice: $array->@[ @empty_list ]
> I don't know whether I can cope with that, which is why I didn't suggest it to
> begin with.  If we do that, do %h{} and @a[] become equivalent to %h and @a?
> ("No" is fine, but the question seems worth raising.)
> In the past, I also suggested:
>   $aref->@{}
>   $href->%{}
>   $cref->&{}
>   $gref->*{}
>   $sref->${}
> ...because these mirror the names of the overloads for these derefs.
> So far, I continue to feel most comfortable with ->@[1,3,5] and ->@* and so on.
> The ->@* is like ->@[*] if we had a p6 "whatever."
> As was suggested elsewhere (by Aristotle?) a whatever star would allow us to
> just say ->@[*], but I don't want to talk about introducing such a thing that's
> useful in so few contexts.  Also, ->${*}?  ->&{*}?  No, I don't think it holds
> together.
>> (5) Will chaining work?
> Yes, absolutely, it must.
>   $sref->$*->@*    # the array referenced by the scalar referenced by $sref
>> Should it have a more compact syntax?  I cringe to put this forward,
>> but for example:
>>     ( ...expression...)->$** # deref twice?
> I think the long form is fine.  It's not that long, either! :)
>> (6) Versus more of an autobox approach
> No, I think this needs to be distinct from any future autoboxing proposal.
> I think I've replied to everything I needed to, but may reply more later.  Time
> to go stock up before the holiday.
> --
> rjbs

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About