Front page | perl.perl5.porters |
Postings from July 2013
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: @xdg
Thread Previous
|
Thread Next