[Rd] Another wish (?) for R 4.0.0: print(*, width = <n>)

Martin Maechler m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Wed Jan 8 09:42:34 CET 2020


>>>>> Henrik Bengtsson 
>>>>>     on Tue, 7 Jan 2020 13:31:18 -0800 writes:

    > On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
    > <r-devel using r-project.org> wrote:
    >> 
    >> For whatever my 2c are worth I think this would be nice.  I'm still uncomfortable at having to call `options` in my package `diffobj` to set output width.

    > Adding a few more cents: It might be worth considering "who" should be
    > allow to control the 'width' argument.  

Well, I tend to disagree; this is not about control (and playing
police .. ;-).
Everbody can set  options() even now and that is a pretty bad
thing unless they are properly localized
{with which I mean: It's +- okay, if you use

- in a function

   op <- options(..) ; on.exit(options(op))

- in a script

   op <- options(..)

   ................
   ................

   options(op)

}
and yes I know people even invented  withOptions(...) etc.

Good programmring style for *functions* according to my book is
to have them depend only on their arguments, and if a global
option really (reall? think twice!) should influence behavior,
there should be arguments of the function which have a default
determined by the global option. 

{ And then in my personal style book, global options should never
  influence anything but "output" {print, plot, ..} and so the
  stringsAsFactors global option is an atrocity and horror ......}


    > In an interactive session,
    > it's neat for the user to quickly be able to adjust 'width'.  But in
    > what cases should this be controlled by a (package) developer?  

packages can set global options now which is much worse than
using it explicitly in some function calls.

Making 'width' an explicit argument {only in some cases, you
cannot do it for auto-printing of course!}

    > What assumptions can the developer safely make about the 'width' of the end
    > user?  I don't know the answer to this and I'm sure one can find valid
    > cases where it makes sense to set the 'width' in a package - maybe
    > like width = 0.90 * getOption("width", 80)?

Indeed.
I also would want to set width in  tests/*.R where I use *.Rout.save
or even more often in \examples{..} in help pages
when printing things that look best, say with  width=111
rather than the default 80.


    > Could it be that print() ignoring 'width' has protected us from
    > packages producing output with a fixed, hardcoded width that is set by
    > the developer?  If print() us updated to acknowledge 'width', will we
    > start seeing print(..., width = 120) and so on in package code?  Is
    > this good or bad?  This might be a complementary problem to what we
    > have with 'stringsAsFactors' where the user's settings can override
    > the intention of the developer.

    > /Henrik

A good package developer will think many times before doing that
(but maybe do it in examples, as I mentioned); careless package
developers do all kind of things anyway.
R (and free software in general) is also about giving freedom to
useRs ..  .. and some of us old folks know that with freedom
comes responsibility .. 

Thank you, Henrik, for your valuable thoughts!


[Brodie G.:]
    >> And since the topic is here, what about `show`?  Feels like it should accept `...` so that it too could be given some set of standard or non standard parameters, including `width`.

I'm not proposing to touch show().
Very often when working with S4 objects, I devise a
sophisticated print() method, with defaults, (often times "smart",
i.e. depending on other arguments) for all but the first
argument and then the show() method just calls that print method.

Best, Martin


    >> Happy new decade.
    >> B.
    >> 
    >> On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler <maechler using stat.math.ethz.ch> wrote:
    >> 
    >> One of the things I often wish R would work with:
    >> 
    >> When calling print() explicitly --- as I do not so rarely, e.g.,
    >> specifying  digits = <nd> ---
    >> it sometimes seems awkward that from the printing options() ,
    >> one can specify 'digits' and it has default  digits = NULL which is
    >> documented to be equivalent to  digits = getOption("digits"),
    >> but one cannot specify 'width'
    >> ... well "even worse": one *can* specify 'width = .' but it is
    >> silently ignored - as well documented  on  ?print.default
    >> 
    >> Before considering to add this for R 4.0.0, doing the work
    >> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
    >> 
    >> wishing you all a  Happy New Year,
    >> Martin
    >> 
    >> Martin Maechler
    >> ETH Zurich and R Core Team



More information about the R-devel mailing list