4 ms·

> built-in functions that change behaviour depending on whether or not you're assigning them to something. Are you suggesting that's a bad thing? If so, consi

by raiph 13y ago

> built-in functions that change behaviour depending on whether or not you're assigning them to something. Are you suggesting that's a bad thing? If so, consider this code: a[2] = a[2] (where a is an "array", [n] an "array index", = "assignment") The behavior of the code 'a[2]' changes entirely depending on whether it's on the LHS or the RHS. Languages and their compilers can easily support this, without a notable downside (short of religious arguments) and most ordinary folk consider it a good thing that it writes to the array when on the left, and reads from the array when on the right. The same argument applies to functions used in a similar fashion (and, in P6, code such as a[1] etc. is in fact a function call).

EdwardDiego 13y ago
> Are you suggesting that's a bad thing? Yes. Your example doesn't apply. In both instances a[2] is a reference to a position in an array. I was referring specifically to context-aware functions in Perl, for example, keys called in a list context returns the keys, in a scalar context, the number of keys, in a void context, it resets an internal iterator. This is terrible, it's like Perl decided that the principle of least surprise was too boring.
- draegtun 13y ago
  It's only a surprise if you don't understand it. Every Perl programmer needs to fully grok and embrace it because it's a core language feature. For others, this is what EdwardDiego is referring to: my %hash = (a => 1, b => 2, c => 3, d => 4); # list context (plural) my @keys = keys %hash; my ($key1, $key2, @rest_of_keys) = keys %hash; # scalar context (singular) my $number_of_keys = keys %hash; say scalar keys %hash; # An example of iterator usage my ($first_key, $first_value) = each %hash; my ($second_key, $second_value) = each %hash; # void context keys %hash; # resets iterator
- raiph 13y ago
  > In both instances a[2] is a reference to a position in an array. Sure, but the reference invokes function calls (semantically; the compiler usually optimizes them away) that depend on context: when 'a[2]' is on the left of an '=' the function calls result in assigning the value to the right of the '='; when 'a[2]' is on the right, it results in just reading 'a[2]'. Imo this as an intuitive and appropriate context aware variation in behavior based on whether or not the 'a[2]' is an "lvalue" (value on the left of an assignment), which is the contextual variation in behavior you first called out as problematic and which I'm suggesting is not. In your latest comment you switched the focus to Perl's distinction of singular vs plural ($ vs @) as seen in the following Perl code: @people = keys payroll # @ means list context (many) $count = keys payroll # $ means item context (one) Given the above code @people would end up with a list (of zero or more items), presumably of objects or somesuch representing people, and $count would end up with a singular value, presumably the number of people. Aiui you think at least one of those lines ought to be invalid, and there should be multiple functions or constructs to replace 'keys': 'keys' and 'count_of_keys', or 'keys.list' and 'keys.count', or somesuch, rather than Perl's singular/plural polymorphic approach. If so, we disagree.

by raiph 13y ago

EdwardDiego 13y ago

> Are you suggesting that's a bad thing? Yes. Your example doesn't apply. In both instances a[2] is a reference to a position in an array. I was referring specifically to context-aware functions in Perl, for example, keys called in a list context returns the keys, in a scalar context, the number of keys, in a void context, it resets an internal iterator. This is terrible, it's like Perl decided that the principle of least surprise was too boring.

draegtun 13y ago
It's only a surprise if you don't understand it. Every Perl programmer needs to fully grok and embrace it because it's a core language feature. For others, this is what EdwardDiego is referring to: my %hash = (a => 1, b => 2, c => 3, d => 4); # list context (plural) my @keys = keys %hash; my ($key1, $key2, @rest_of_keys) = keys %hash; # scalar context (singular) my $number_of_keys = keys %hash; say scalar keys %hash; # An example of iterator usage my ($first_key, $first_value) = each %hash; my ($second_key, $second_value) = each %hash; # void context keys %hash; # resets iterator
raiph 13y ago
> In both instances a[2] is a reference to a position in an array. Sure, but the reference invokes function calls (semantically; the compiler usually optimizes them away) that depend on context: when 'a[2]' is on the left of an '=' the function calls result in assigning the value to the right of the '='; when 'a[2]' is on the right, it results in just reading 'a[2]'. Imo this as an intuitive and appropriate context aware variation in behavior based on whether or not the 'a[2]' is an "lvalue" (value on the left of an assignment), which is the contextual variation in behavior you first called out as problematic and which I'm suggesting is not. In your latest comment you switched the focus to Perl's distinction of singular vs plural ($ vs @) as seen in the following Perl code: @people = keys payroll # @ means list context (many) $count = keys payroll # $ means item context (one) Given the above code @people would end up with a list (of zero or more items), presumably of objects or somesuch representing people, and $count would end up with a singular value, presumably the number of people. Aiui you think at least one of those lines ought to be invalid, and there should be multiple functions or constructs to replace 'keys': 'keys' and 'count_of_keys', or 'keys.list' and 'keys.count', or somesuch, rather than Perl's singular/plural polymorphic approach. If so, we disagree.