[Rd] Unexpected argument-matching when some are missing

[Emil Bode]

Thanks as well!
I'm now getting how it's exactly matched, but it still "feels wrong".
Martins rewording is exactly what I meant/was concerned about.
My intuition would say that anyone using ff(x=, ...) would not intent x to be matched to something else, but maybe I'm overlooking certain cases.
Anyway, I agree that throwing a warning would probably be the best solution.
I don't exactly know how to test for compatibility for such changes (never really worked with CRAN/extensive testing), but if I can do something to help I'd be glad to.
And if it turns out to be too disruptive, maybe we can write Patrick Burns (the R-inferno) ; - )

Best regards, 
Emil Bode
 
On 03/12/2018, 10:57, "Martin Maechler" <maechler using stat.math.ethz.ch> wrote:

    >>>>> Michael Lawrence 
    >>>>>     on Fri, 30 Nov 2018 08:24:31 -0800 writes:
    
        > Argument matching is by name first, then the still missing
        > arguments are filled positionally. Unnamed missing
        > arguments are thus left missing. Does that help?
    
    Thank you, Michael!
    Unfortunately, it may not help sufficiently notably once this
    thread will be forgotten, even though I had thought so exactly
    as well.  Of course we two may find R's matching algorithm
    entirely intuitive, but e.g., Ista expected R even "to throw an
    error" in this case, and there are about 99% of R users less savvy than
    him, so let me think loudly a bit further ...
    IIUC, Emil's case is mostly about this
    
      > ff <- function(x,y,z,...) list(sysC=sys.call(), match=match.call())
      > str( ff(x=, z=pi, "foo") )
      List of 2
       $ sysC : language ff(x = , z = pi, "foo")
       $ match: language ff(x = "foo", z = pi)
      > 
    
    where the argument matching rule above would have suggested to him that the
    matched call should have become
      ff(y = "foo", z = pi)  rather than
      ff(x = "foo", z = pi)
    
    because he'd expected the empty 'x =' to be matched by name and
    hence *not* be matched again later when all the missing
    arguments are matched positionally in the end.
    NB because of the rule Michael cited above *of course*,
    ", ," (in your example below) is not equivalent to
    "y = ," because the former leads to positional matching at position 2.
    
    Now R's matching argument algorithm has therefore been consistent with
    the above simple matching rule ((which did not include the exact vs
    partial matching but that was not the topic here anyway))
    that had been documented as that forever and AFAIK the same as S had.
    
    What may be possible (and suggested in this thread ?) would be
    to start signalling a warning when named empty arguments (the
    " y = , "  in the example) are matched(*), i.e., it would give a
    warning in match.call() but not sys.call(), and hence utilities
    such as  alist()  would continue to work unchanged.
    
    I have no idea (and no time currently to investigate) if such
    warnings would be too disruptive for the current R code base or not.
    
    Martin
    
    ----
    *) "matched" in that case effectively means "dropped" as we have
        seen in the examples.
        
    
        > On Fri, Nov 30, 2018 at 8:18 AM Emil Bode <emil.bode using dans.knaw.nl> wrote:
        >> 
        >> But the main point is where arguments are mixed together:
        >> 
        >> > debugonce(plot.default)
        >> > plot(x=1:10, y=, 'l')
        >> ...
        >> Browse[2]> missing(y)
        >> [1] FALSE
        >> Browse[2]> y
        >> [1] "l"
        >> Browse[2]> type
        >> [1] "p"
        >> 
        >> I think that's what I fall over mostly: that named, empty arguments behave entirely different from omitting them (", ,")
        >> 
        >> And I definitely agree we need a guru to explain it all to us (
        >> 
        >> Cheers, Emil Bode
        >> 
        >> 
        >> On 30/11/2018, 15:35, "S Ellison" <S.Ellison using LGCGroup.com> wrote:
        >> 
        >> > Yes, I think all of that is correct. But y _is_ missing in this sense:
        >> > > plot(1:10, y=)
        >> > > ...
        >> > Browse[2]> missing(y)
        >> 
        >> Although I said what I meant by 'missing' vs 'not present', it wasn't exactly what missing() means. My bad.
        >> missing() returns TRUE if an argument is not specified in the call _whether or not_ it has a default, hence the behaviour of missing(y) in debug(plot).
        >> 
        >> But we can easily find out whether a default has been assigned:
        >> plot(1:10, y=, type=)
        >> Browse[2]> y
        >> NULL
        >> Browse[2]> type
        >> "p"
        >> 
        >> ... which is consistent with silent omission of 'y=' and 'type='
        >> 
        >> 
        >> Still waiting for a guru...
        >> 
        >> Steve E