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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel