Willem said:
Rainer Weikusat wrote:
)> Rainer Weikusat wrote:
)> I claimed that the sort routine *conceptually* is a function from arrays
)> to arrays. This is correct.
)
) The perl sort is defined based on lists.
Yes, so you reiterated several times.
What does that have to do with conceptual interpretations ?
It means that you 'conceptual interpretation' is not correct:
'Conceptually', sort is an operation which takes an ordered set as
input and produces a permuted ordered set as output. One example of an
implementation of 'an ordered set' is the Perl datatype array. Another
example is what is called 'a list' in Perl -- some number of items
returned individually on the call/ return stack of a subroutine (or
passed to it in this way, although 'an array' is automatically created
for such an input list insofar the subroutine processing it has been
written in Perl) without a 'Perl array' being involved here. Another
example for an type of ordered set Perl doesn't support directly would
be a linked list (easily implementable in various ways). Another
ordered set supported by Perl would be an array slice.
In line with the style of argumentation you have used so far, your
statement is not only wrong but also, irrelevant: The perl sort
operation is defined in some specific way and this definition governs
its behaviour, not some theoretical generalization of 'sort operations
as such'.
[...]
) List value constructors
) List values are denoted by separating individual values by
) commas (and enclosing the list in parentheses where precedence
) requires it):
)
) (LIST)
)
) In a context not requiring a list value, the value of what
) appears to be a list literal is simply the value of the final
) element, as with the C comma operator. For example,
)
) @foo = ('cc', '-E', $bar);
)
) assigns the entire list value to array @foo, but
)
) $foo = ('cc', '-E', $bar);
)
) assigns the value of variable $bar to the scalar variable $foo.
) [perldata(1)]
I'm not seeing "a list evaluated in scalar context returns the last
element". What you quoted above supports my intepretation, that
'what appears to be a list' (i.e. values separated by commas), when
in scalar context, is *not* a list, but the last value.
[...]
So, as it appears, the documentation does not back up your claim
that 'evaluating a list in scalar context returns the last element'.
Instead, 'the operator that creates a list in list context, returns
the last element in scalar context'. Which is a special case to
accomodate the expectations of C programmers about the comma
operator.
'The operator that creates a list in list context' does not exist in
the text above, not even 'in scalar context'. What the text actually
says is that a 'list value constructor' (parenthesized expression with
indivual elements separated by commas) behaves as if it was a 'C comma
operator' in scalar context. Also, 'Perl list' can be created without
resorting to 'Perl list value constructors' meaning, your attempt at
defining the Perl concept 'list value constructor' away doesn't help:
A subroutine returning a list still effectively returns the last
element of that list when being called in scalar context (and no other
behaviour was implemented).
)> As you argue below, this is irrelevant because functions are aware
)> of the context they are in. Several functions that return lists
)> will return the list count in scalar context.
)
) Several functions which *happen* to generate an output list from an
) input list where the number of elements on the output list cannot be
) predicted without performing the operation on the input list return
) this number when used in scalar context. The sort operation does not
) have this property: Since it permutes the elements from the input
) list, the number of elements of the output list is identical to the
) number of elements on the input list.
Why did you snip the part where I said that *no* function that returns
a list returns the last item in scalar context ?
For the usual reasons, wrong and irrelevant: You don't know 'any function
which returns a list with these property' because you have
'cleverly' defined all subroutines written in Perl which return lists
via list value constructors as 'not really returning lists' and no
builtin function with said property exists. But
sub xyz { return ($_[0], $_[1]); }
is nevertheless such a subroutine. It is also possible to define the
'return a list composed of the arguments to the subroutine' subroutine
in Perl:
sub nop { return @_[0 .. $#_]; }
No list value constructor here (I haven't used slices for anything so
far, that's why I didn't think of this).
It is irrelevant because "I haven't observed X" is a statement about
the speaker and not about X.
[...]
)> I am trying to argue that sort *should* behave as if it was
)> context-agnostic, because that is the most sensible option.
)
) That's the most sensible option FOR YOU because you happen to have
) written some code based on the assumption that sort would behave in
) this way despite it actually doesn't.
Yes. That's what I just said. Does it not occur to you that when somebody
expects something to happen a certain way, they have good reasons for that?
And in case you had missed it, this whole thread I have been presenting the
very reasons I have for these expectations.
The reason for this expection appears to be that you wrongly assumed
that 'sort' and the 'other operations returning a count in scalar
context' would belong to the same class because your were solely
looking at the input and output types in list context (takes a list,
returns a list) and were incorrectly assuming that 'list evaluated in
scalar context' would return the number of elements on the list: The
latter isn't true, the former misses an important difference between
'sort' and these 'other operations': The number of elements on the
output list is among the output information generated by these other
operations but it is not 'output information determined by sort'.
ptimize: | tr -d "'"`