[Rd] [R] Semantics of sequences in R

[Wacek Kusnierczyk]

Stavros Macrakis wrote:
>
>>> ...sort(list(...))), I'd hope that wouldn't break existing code. [...]
>>>       
>
>   
>> ...sort is a generic function, and for sort(list(...)) to work, it would
>> have to dispatch to a function called sort.list;... such a function exists
>> already and it is not for sorting list.
>>     
>
> Omigod.  There is a function called 'sort' which doesn't sort, and
> which follows the S3 conventions for sorting lists, but doesn't allow
> lists as an argument type.  That *is* a mess!
>
> Well, if it's OK for sort.list to violate S3 naming conventions
> (presumably because it was defined before S3 was), then I suppose it
> would be OK for sort to violate S3 coding conventions in return, and
> dispatch in a non-standard way, e.g.
>
>       if (is.list(x)) sort.S3.list(...) else UseMethod("sort")
>
> Ugly, but then so is sort.list....
>   

according to svn, sort.list was introduced in late 1999 by Prof Brian
Ripley (revision 6598, 'add sort.list for S compatibility').

however, the fancy 'have you called sort on a list' error message was
added by Prof Brian Ripley in 2006, replacing the less confusing but
still odd (to a naive user) message 'x must be atomic' produced when you
call sort.list on a list.

btw. it's interesting that in revision 38438 (2006) Prof Brian Ripley
introduced (or so does the commit message say) sorting complex numbers,
and now you have things like:

    1i > 0i
    # Error in 0+0i > 0+1i : invalid comparison with complex values

    sort(c(1i, 0i))
    # 0i 1i

vQ