[Rd] Unexpected argument-matching when some are missing

[Martin Maechler]

>>>>> 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