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

Re: postfix dereference syntax

Thread Previous | Thread Next
Ricardo Signes
July 3, 2013 21:08
Re: postfix dereference syntax
Message ID:

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

> 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?


>     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:


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

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


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