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 at 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 ******************************************************************* This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmaster at lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
Michael Lawrence
2018-Nov-30 16:24 UTC
[Rd] Unexpected argument-matching when some are missing
Argument matching is by name first, then the still missing arguments are filled positionally. Unnamed missing arguments are thus left missing. Does that help? Michael On Fri, Nov 30, 2018 at 8:18 AM Emil Bode <emil.bode at 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 at 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 > > > > ******************************************************************* > This email and any attachments are confidential. Any use, copying or > disclosure other than by the intended recipient is unauthorised. If > you have received this message in error, please notify the sender > immediately via +44(0)20 8943 7000 or notify postmaster at lgcgroup.com > and delete this message and any copies from your computer and network. > LGC Limited. Registered in England 2991879. > Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
Martin Maechler
2018-Dec-03 09:55 UTC
[Rd] Unexpected argument-matching when some are missing
>>>>> 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 at 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 at 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