[Rd] [R] Semantics of sequences in R

[Wacek Kusnierczyk]

Berwin A Turlach wrote:
> On Mon, 23 Feb 2009 08:52:05 +0100
> Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
>  
>   
>> Berwin A Turlach wrote:
>>     
>>> G'day Stavros,
>>>       
>> <snip>
>>     
>>>> In many cases, the orthogonal design is pretty straightforward.
>>>> And in the cases where the operation is currently an error (e.g.
>>>> sort(list(...))), I'd hope that wouldn't break existing code. [...]
>>>>     
>>>>         
>>> This could actually be an example that would break a lot of existing
>>> code.
>>>
>>> sort is a generic function, and for sort(list(...)) to work, it
>>> would have to dispatch to a function called sort.list; and as
>>> Patrick Burns' "The R Inferno" points out, such a function exists
>>> already and it is not for sorting list.  
>>>   
>>>       
>> and you mean that sort.list not being applicable to lists is a) good
>> design, and b) something that by noe means should be fixed, right?
>>     
>
> I neither said nor meant this and I do not see how what I said could be
> interpreted in such a way.  I was just commenting to Stavros that the
> example he picked, hoping that it would not break existing code, was
> actually a bad one which potentially will break a lot (?) of existing
> code.
>   

would it, really?  if sort.list were, in addition to sorting atomic
vectors (can-be-considered-lists), able to sort lists, how likely would
this be to break old code?  can you give one concrete example, and
suggest how to estimate how much old code would involve the same issue?

sort.list, to be applied to an atomic vector, must be called explicitly
on the vector, because calling sort will not automatically dispatch to
sort.list (right?).   so allowing sort.list to sort lists does not
change anything in this respect -- except for that, as i suggested, if
sort.list were requiring an explicit comparator, you'd have to add one
wherever sort.list is called, but to accomodate for old code sort.list
could actually check whether the argument is not an atomic vector.

how much old code could be relying on the fact that sort.list raises an
error when given a list?  i suspect it's fairly unlikely that any single
piece of code does;  and if so, allowing sort.list to sort lists would
not change anything here either.




> Also, until reading Patrick Burns' "The R Inferno" I was not aware of
> sort.list.  That function had not registered with me since I hardly
> used it.  

which hints that "potentially will break a lot (?) of existing code" is
a rather unlikely event.

> And I also have no need of calling sort() on lists.  For em a
> lists is a flexible enough data structure such that defining a sort()
> command for them makes no sense; it could only work in very specific
> circumstances.
>   

i don't understand the first part:  "flexible enough data structure such
that defining a sort() command for them makes no sense" makes no sense.

as to "it could only work in very specific circumstances" -- no, it
would work for any list whatsoever, provided the user has a correctly
implemented comparator.  for example, i'd like to sort a list of vectors
by the vectors' length -- is this a very exotic idea?


>   
>>> In fact, currently you get:
>>>
>>> R> cc <- list(a=runif(4), b=rnorm(6))
>>> R> sort(cc)
>>> Error in sort.list(cc) : 'x' must be atomic for 'sort.list'
>>> Have you called 'sort' on a list?
>>>   
>>>       
>> one of the most funny error messages you get in r.  note also that,
>> following rolf turner's lists and vectors unproven theorem, a vector
>> can be considered a list 
>>     
>
> I do not remember the exact context of Rolf's comments, but I believe
> he was talking in a more general sense and not in technical terms. 

indeed, he was blurring the concepts instead of referring to concrete
documentation with clear specified meaning of the terms he used.


>  I
> find it perfectly valid, even when talking about R, to say something
> like "vectors are stored as a list of numbers in consecutive memory
> locations in memory".  

yes;  and you can always say that 'vectors can be considered electrical
charges', or better, 'vectors can be considered electrical charges, in
some sense'.

what sense of 'list' are you using here?  i'd rather use the term
'array', unless confusing the user is the real purpose.  (and to be
really picky, you do not store numbers.)


> Clearly, in a phrase like this, we are not
> talking about "vectors" and "list" as defined by the "R Language
> Definition" or "R Internals", or what functions like is.vector(),
> is.list() &c return for various R objects.
>   

clearly, you can say anything you like, and then add 'i was not talking
about x as defined by y'.  the art  is to talk about x as defined by y.

> BTW, as I mentioned once before, you might want to consider to lose
> these chips on your shoulders.
>   

berwin, it's been a tradition on this list to discourage people from
commenting on the design and implementation of r whenever they think
it's wrong.  you really should be doing the opposite.  as a chinese
proverb says, a gem cannot be polished without friction.  friction seems
to be what you fear a lot.


>   
>> -- hence sort.list should raise the error on any vector input, no?
>>     
>
> You will have to take that up with the designers of sort.list.
>   
>   
>>> Thus, to make sort(list()) work, you would have to rename the
>>> existing sort.list and then change every call to that function to
>>> the new name. I guess this might break quite a few packages on CRAN.
>>>   
>>>       
>> scary!  it's much preferred to confuse new users.
>>     
>
> I usually learn a lot when I get confused about some issues/concept.
> Confusion forces one to sit down, think deeply and, thus, gain some
> understanding.  So I am not so much concerned with new users being
> confused.  It is, of course, a problem if the new user never comes out
> of his or her confusion.
>   

the problem, is, r users have to learn lots and lots of *bad* and
*messy* design to get up and running without devils catching them behind
every corner.  in principle, you're absolutely right;  the problem lies
in the amount of effort a user has to make to avoid confusion while
using r  (where 'using' means a bit more than simply fitting and
plotting a model).

cheers,
vQ