On Wed, Jun 26, 2013 at 9:59 PM, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: > If we want the two forms to be really of equivalent value, we'll also need to > be concerned with: > > print "Things: $aref_of_things->@*" > > ...which gets into less clearly-introduceable behavior. Quoting has so many special rules anyway that I see no reason to insist that postfix dereferencing work in quotes. I'd leave it as is. > Finally, do we need to enable postfix slices? I think that if we can, we > should. Agree. > I think we have a few options for the specific tokens to put after that last > arrow. Do you want that bikeshed argument now or later? What are you looking for? General reaction? Edge cases? Volunteers? Your OP reads a bit more like a "meditation" with only an implicit "What do you think?" ## Re other replies: > [prototypes] Grudgingly, I agree: \@ should accept a postfix dereference. I'm not sure how ugly that is to implement. Presumably, if we check after parsing and just make sure the next op is a deref of the appropriate type, that might work. (It might shift when a prototype error is thrown, though.) > [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. > [do we need it or not & use of temporary variables] I think creating temporary variables ( @$array vs @{ ... long thing ... } ) as a workaround for visual simplicity is at least arguably undesirable. (Cue aliasing feature argument...). This means it will come down to a matter of style and personal preference. As long as "enough" people think postfix dereference is visually cleaner to read, then I think it adds value to *them* and is worth adding to the language. ## More considerations (1) Code references? Do we want consistency and allow $coderef->&*? Would it have semantics like $coderef->() or &$coderef (passing through @_)? (2) Glob references? For consistency only, since I think it would be rarely used. Personally, I'd say "no", but you should be explicit in the design decision about it. (4) Comparison to existing code deref syntax? The subroutine postfix deref "looks" like a subroutine call. The proposed "@*" or whatever looks like a variable. Would it be clearer if it looked more like existing dereference? $coderef->() $array->@* vs something like $array->[] or $array->@[] This gets confusing with postfix slices since these wouldn't be equivalent: deref: $array->@[] slice: $array->@[ @empty_list ] (4) Comparison with slice syntax? $array->@* $array->@[ 1..3 ] Leaving aside #3, do we want "all" vs "slice" to have some visual affordance? Splat sort of does that, but other syntax (e.g. colon) might not. (5) Will chaining work? ( ...expression... )->$*->$*; # ${ ${ ... expression ... } } Should it have a more compact syntax? I cringe to put this forward, but for example: ( ...expression...)->$** # deref twice? (6) Versus more of an autobox approach Does it have to be punctuation? $array->flatten This could get tricky just like auto-deref if objects with overloading are also to be supported (which I would just say "no" to). But I do wonder how much circumfix deref would go away in practice with autoboxing-style methods: $array->push( $other_array->flatten ); $array->map( sub { ... } ); $hash->keys; David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdgThread Previous | Thread Next