[Rd] as.vector() broken on a matrix or array of type "list"

[Martin Maechler]

>>>>> Hervé Pagès 
>>>>>     on Tue, 25 Sep 2018 23:27:19 -0700 writes:

    > Hi, Unlike on an atomic matrix, as.vector() doesn't drop
    > the "dim" attribute of matrix or array of type "list":


>    m <- matrix(list(), nrow=2, ncol=3)
>    m
>    #      [,1] [,2] [,3]
>    # [1,] NULL NULL NULL
>    # [2,] NULL NULL NULL

> 
>    as.vector(m)
>    #      [,1] [,2] [,3]
>    # [1,] NULL NULL NULL
>    # [2,] NULL NULL NULL

as documented and as always, including (probably all) versions of S and S-plus.

>    is.vector(as.vector(m))
>    # [1] FALSE

as bad is that looks, that's also "known" and has been the case
forever as well... 

I agree that the semantics of as.vector(.)  are not what you
would expect, and probably neither what we would do when
creating R today. *)
The help page {the same for as.vector() and is.vector()}
mentions that as.vector() behavior more than once, notably at
the end of 'Details' and its 'Note's....
... with one exception where you have a strong point, and the documenation
is incomplete at least -- under the heading

 Methods for 'as.vector()':

   ....... follow the conventions of the default method.  In particular

   ... 
   ... 
   ... 

   • ‘is.vector(as.vector(x, m), m)’ should be true for any mode ‘m’, 
      including the default ‘"any"’.

and you are right that this is not fulfilled in the case the
list has a 'dim' attribute.  

But I don't think we "can" change as.vector(.) for that case
(where it is a no-op).
Rather  possibly is.vector(.) should not return FALSE but TRUE -- with
the reasoning (I think most experienced R programmers would
agree) that the foremost property of 'm' is to be
 - a list() {with a dim attribute and matrix-like indexing possibility}
   rather than
 - a 'matrix' {where every matrix entry is a list()}.

At the moment my gut feeling would propose to only update the
documentation, adding that one case as "an exception for historic reasons".

Martin

-----
*) {Possibly such an R we would create today would be much closer to
    julia, where every function is generic / a multi-dispach method
    "a la S4" .... and still be blazingly fast, thanks to JIT
    compilation, method caching and more smart things.}
But as you know one of the strength of (base) R is its stability
and reliability.  You can only use something as a "the language
of applied statistics and data science" and rely that published
code still works 10 years later if the language is not
changed/redesigned from scratch every few years ((as some ... are)).